My company didn't took away any expensive model, but it did imposed a tight budget and gave my team hardware to run local models. The budget works mainly as an influence on the decision process of which model to run. We can still run expensive budget-burning models if we really want to, but there is a clear incentive to use options that allow us to save our token budget for a rainy prompt.

Surprisingly, I feel this had a positive impact on results. Instead of succumbing to extremely expensive one-shot prompts with the most expensive model in the news, chaining agents running cheap models equiped with context and specialized skills and scripts ends up having a better and more reliable output. And faster too.

I think there is a lot of propaganda, perhaps even astroturfing, on how only the most expensive models churned out by US companies are worth using. Nowadays the cheapest models get the job done, and local models can already handle most tasks as well specially as part of orchestration chains.

Is security no longer a concern?

When you are using a third party model, you are literally feeding it not only your current software but also all the context and work fronts under development.

This is way more than granting a third party access to your internals. This is feeding it in advance updates on all their operations in real time.

I don't think any vague claim of "speed" has anything to do with fatigue.

I do think the parallel world monitoring and validating N work fronts, followed by rounds of fixes where you lay there waiting for the agents to converge, is the defining factor.

Instead of you hunkering down and hammering out a single task where your full attention can be focused 100% on a problem, your mindset is a kin to juggling N balls and hoping to not let any of which to fall.

So it's not really about speed but throughput, and keeping up with the throughout rate is mentally taxing.

Microsoft's MAI-Code-1.1-Flash is on par with OpenAI's Luna line of models. If not for OpenAI's recent radical change of heart on Luna's pricing to hastily slap a 50% discount, MAI-Code-1.1-Flash could very well be the dominant cheap model.

Chinese companies also managed to put together their models with relatively small clusters.

Perhaps US companies are desperately trying to brute force their way into workable models?

Mistral is also an European company. As we live in a time where the US regime is engaged in pyrrhic geopolitical tactics, it's good to know that it can't threaten to cut access to models during s period where everyone is rushing to incorporate them more and more in our life.

Any open weights model that Chinese companies are releasing for free are allowing everyone in the world to have access to high quality realizations of these tools without the risk of the US regime arbitrarily cutting you off.

Also, it's funny how all the neoliberal mantras of how free market drives progress through competition stops when it's a US company that's being challenged.

US companies are burning colossal piles of cash in ways that makes it unclear if it qualifies as dumping, not to mention their deep ties with the country's regime.

Claiming that companies from a country have ties to the regime and burn through cash is a very miopic accusation.

"Why does the page fail to work with this browser?"

That's rather obvious, isn't it?

> Again, this is only subjective reasoning without evidence.

It really isn't. While systems are designed around this problem. Even UI test matrices. How come are you spending so much time discussing an issue you're not aware?

I think people care about the problems they have to handle. Not having to deal with a problem eliminates the incentive of training to fix the problem, because you don't waste time on problems that don't happen.

People also stopped caring about what machine code was generated by compilers. In the past people had to roll out asm to get things to work. Not anymore. With llms it's the same way.

It is pretty obvious that platform-only approaches are riddled with problems that are unacceptable in professional environments that develop production-graded software. Polyfills and caniuse show one part of the problem, "your browser is not supported" and "designed for chrome" is another, etc. Only someone who is completely detached from professional settings would argue otherwise.

> If you know what you are doing it is far less effort.

Those who know what they are doing are knowledgeable enough to simply avoid the problems caused by platform fundamentalism. Not knowing this is a skill issue.

The point is that the "platform" way of doing things is lagging behind virtually all JavaScript frameworks particularly in developer experience, and even when the platform tries to catch up with JavaScript frameworks such as web components... The results are between underwhelming and unusable.

> The components are free to be built with whatever lightweight lib they need (Lit, UI5 Core, etc.).

You're still resorting to using JavaScript frameworks. The problems created by the platform are still there if you replace framework foo with framework bar. In fact, it seems React 19 rolled out full support for web components.

This is self-evident, isn't it?

Other than the buzzword factor, why do you think name-dropping AI makes a difference?

I think this point is what the anti-framework does not get when discussing the topic. They fail to see how hard and unpleasant it is to handle all the real-world problems that hits any production environment with a "platform" approach, and at the same time they fail to see how javascript-based een frameworks not only solve them by making them implementation details but also go through great lengths to improve the developer experience.

Just take a look at JSX. It's where a great deal of the complexity of the framework lies, but simplifies everything so much. It's the exact opposite of platform features.

For starters, you can start by checking https://caniuse.com .

Then, dive down into the concept of polyfills to understand what extra work everyone must go through to normalize the platform.

And then look at the features themselves. Web components is a good example. Theywere developed as a hack to extend toe current platform to catch up with basic features provided by JavaScript web frameworks. Except they are virtually unusable, unless they are made palatable with... JavaScript frameworks.

And lastly, compare that with the experience of just using a mainstream JavaScript framework. Any of them. It's world's of difference. JavaScript frameworks prioritize developer experience to the point they even went through great pains to have a xml-like DSL to make their javascript be seamless. Whereas things like web components go the opposite direction and make their platform's first class feature feel like vanilla javascript.

Pointing out the absurdity of someone like you throwing blanket accusations of incompetence is something that's very specific and verifiable. If you have strong feelings about making broad accusations about whole communities, you should pause and pay attention to what you are saying.

> If you want to make any technical arguments in support of react, I’m all ears.

Would you listen? I mean, the main issue with your post is the way you throw absurd blanket statements about a technology, on how either everyone using it is incompetent or the framework is somehow broken.

I mean, does it even dawn upon you that maybe perhaps throughout the past decade there might be people using the dominant framework well, and happen to know what they are doing?

It seems not, by the way you opt to disregard it and tell yourself no, everyone is either incompetent or the tool is broken.

Do you understand the absurdity of this sort of claim? Because it isn't even about React, but the way you feel it's reasonable to throw such blanket accusations.

> But that doesn’t mean react can’t be improved upon.

But that's not the claim you made, was it? Do you need me to quote you back at you?

Comments URL: https://news.ycombinator.com/item?id=49955223

Points: 2

# Comments: 0

You're asserting that everyone is using it wrong. It's your personal opinion, and a baseless one at that which is based on a personal belief that everyone around you is incompetent and incapable of critical reasoning. It's silly posturing.

In the meantime, React is by far the most popular web framework in production. Some surveys list React with a market share of between 60-75% of all web frontend projects. It's so popular that it even leaked into GUI programming with native GUI toolkits.

It's rather obvious that assertions such as yours are detached from reality. Naturally the dominant framework will also dominate the number of newbies taking their first steps as well as drive-bys. It's also natural that the dominant framework will be targeted by the "aktually" crowd, invested in contrarian self-promotioj comments instead of doing anything constructive.

But to assume everyone is incapable of using something... That takes a lot of self delusion.

It seems you tried to reinvent instruction files. What do you think is the difference between your approach and standard tools such as instruction files, AGENTS.md, and even skills?

You haven't been paying attention then. I routinely see Claude and GPT models churning out python code to do stupid things like linting. Last week I even had a TypeScript project with prettier configured all over the place, including in a custom agent skill I added with the express purpose of getting the damned model to lint the code, being constantly prompted to run ad-hoc python code supposedly to format whitespaces. I even explicitly prompted one session to just use npm run lint, where I pointed out the exact line of code where prettier was invoked, and the session still churned python code to hande whitespaces.