It comes down the web browser being used for two different use cases and two camps arguing past one another.
Documents vs Programs
The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser.
Where I imagine you lose some people is that comboboxes can be done natively with the datalist attribute.
> The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity.
Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.
Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once.
But even given your position you see no difference between shipping the user a binary and shipping source code plus a compiler in terms of the user's experience? Surely the existence of server side react points to the server doing the initial lift being an improvement.
> Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites.
I don't think you understood my question. I stressed the fact that complaining about the complexity of a page implemented with a JavaScript framework is a red herring, because said complexity doesn't go away by moving it to a server.
And the old "dynamic HTML" approach is not easier to maintain and developm. By far.
In the meantime, what goes away is performance and perceived performance. Your dynamic HTML pages need to travel all around the world until clients see an update, and a page reload is far heavier and time consuming than doing a fetch to get data.
Try to ask yourself this simple question: why do software engineers bother with JavaScript frameworks? Do you think everyone has absolutely no idea about what they are doing?
Surely you mean the "time spent," not the "speed" - as an interpreter would have an overhead, not magically speed up WASM execution. Somewhat related note, we need better tools for PGO within native compiled programs.
My main point was that they recycle lazily, producing slop before the name even existed. Not every adaptation is lazy, I'd say that Odyssey is quite good, even though the original work is 100 generations old.
- Opus 4.6 was the last Opus generation that got a lot of use by Anthropic's own employees
- After that they primarily used Mythos internally
- 4.7, 4.8 and 5 were RLAIFd by Mythos "teachers"
- Hence why 4.6 is the last Opus gen who doesn't report back like a robot wanting to cover every potential hole another AI system would've spotted and criticized
- Hence why coding style in Opus 5 also gets criticized, not only behavior in CC
Commented elsewhere, I still use Opus 4.6 because it is the only model that feels decent to interact with. 4.8 is decent and some times smarter but you can see it trending towards Opus 5 levels of nonsense. I use Opus 5 when I don't need to interact. Fable or Opus 4.6 are the only Anthropic models I like interacting with ATM.
Need to have a 4th string backup (Gemini).
reply