In the coding realm, I think we'll be seeing 35, 70, and 150B models sold where you pay a few hundred to a few thousand dollars up front and get a year of monthly/bi-monthly updates where they've trained it on new coding documentation and repos.
Humans have good spatial memory and having a handful of statically-positioned desktops in a 2D plane makes navigation intuitive and consistent.
The real issue is how the ORDER of the desktops changes all the time which messes with that spatial memory and kills a lot of the productivity improvements. A consistent straight line would still be worse than a grid, but still MUCH better than the current situation.
If AI could outperform humans, Anthropic would NEVER release that model. Instead, they'd use it to create a new google, photoshop, office, windows, etc for cheap then undercut all those companies and taking over the entire software industry.
It can outperform humans, just unevenly. You’ll see a lot of the same dynamics as you see with Mythos which, tbh is kind of refreshing. I get the sense that Dario while of course forced to ruthlessly run a company is genuinely interested in figuring out how to roll this out as ethically as he can.
I remember when React's vdom renderer was faster than anyone and it wasn't even close. InfernoJS uses a vdom and is still one of the fastest JS frameworks out there, so I don't know that diffing is always inherently slower.
They no longer accept world records for not sleeping because the record breakers have universally suffered lifelong cognitive damage.
We know more generally that people who get decreased amount of sleep suffer increased rates of physical and mental health issues.
It is not a very big leap from "causes permanent damage" to "enough permanent damage can cause death" and of course, keeping someone awake until they are hurt or killed is deeply unethical, so even if it could be proven in other species, you'd still be here arguing that 'they aren't humans".
We'll set aside performance because that could be fixed with a renderer rewrite.
The biggest issue when I worked with it was weaving a spiderweb of bindings that eventually trap you. At some point, you wind up spending most of your time fighting weird bugs that show up in places very far removed from the bindings that actually caused the bug.
There are four culprits here and neither is due to JS.
First is the pursuit of polish. Each extra 1% in polish adds tons and tons of lines of code. If you want that level of polish on a non-SPA, you'll still have to add all that code then reload it one page at a time. I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
Second is bloated do-everything libraries. Ant, MUI, Mantine, or whatever else is aimed to be a superset of all possible website needs which means that the components you adopt have tons of features and bloat you don't need that slow down loading, parsing, and execution. Simply replacing that <Paper> component with a <div> and a few lines of CSS will get you the same thing you want, but will save you layers of unnecessary React components and sometimes a layer or two of unneeded DOM nodes as well that were added because the <Paper> component had weird interactions with some other component.
Third is manpower/experience. Many/most JS devs today (sad to say) don't actually know how to make that simple <Paper> component on their own. Those that do often skip it because they've got too much to do already. I've lost count of the number of teams I've seen where a bog-standard backend has 25 people working on stuff while the frontend team has 3x as many total lines of code (which are often times handling human-computer interaction issues the backend couldn't even imagin), but only 3-4 people to maintain it all.
Fourth is of course management. Designs on the backend change at a trickle while changes to the frontend arrive in a torrent. Understaffed frontend teams can't keep up with all the things shoved on their plate, so they usually can't optimize things even if they know how (eg, only a small percentage of SPA actually know/take the time to lazy load various parts of their apps to improve load time).
Fix these things and the SPA performance will improve drastically and almost certainly exceed BE templates with some jQuery spaghetti.
>I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up.
having lots of JavaScript tends to make more WCAG problems, because you do interactive stuff that needs to be described. Having bare HTML and the accessibility that is required for that is not tending to bloat in my experience.
Users need interactive stuff. If your site isn't interactive and your competitor's site IS interactive, customers almost certainly will prefer your competitor.
When you try to chain that stuff across multiple backend-rendered pages, you get a whole other list of problems. If you need to track all the otherwise transient UI stuff on the BE, you have now created a whole mess of stateful APIs and turned horizontal scaling into a much bigger issue than it needed to be.
Users wants something that will help with whatever they want done. And the quicker, the better. Interactivity is nice, but I never seen anyone complains about multipages applications.
> If you need to track all the otherwise transient UI stuff on the BE
So don’t add transient stuff? You send a page or a form according to the URL, the user does whatever it wants and either request a new page or submit the form. Each page is standalone like activities in an Android app. Anything transient is taken care of on the client side.
so you argued that the need for internationalization and Accessibility was such that if you tried to add that in to bare html - css solution that you would end up getting bloated, I argued (based on my experience) that accessibility bloat actually comes from the need to support various JavaScript bits of accessibility.
To which you then argue that the JavaScript parts are needed.
If so it is the JavaSript that adds the bloat, because the accessibility bloats to support the JavaSript.
I mean I'm not against JavaSript but I have seen many sites that didn't need it; and I've been forced by work requirements to add in too much of it on sites that needed very little or even none at all.
Vue doesn't solve problems better than React (and solves them worse if you have to learn all their proprietary files and DSLs instead of JSX), so there's not much of a reason to switch.
The real discussion would be between React's vdom and something like Solid's signals.
It does, if you care about ergonomics. The reactivity model is simpler and arguably less error prone.
It does have its own templating syntax, which is trivial to learn. No more cumbersome to learn than JSX, which is a templating language designed by the React team. Not sure why you chose to make the distinction between JSX and Vue’s DSL as if JSX wasn’t developed for the sole purpose of facilitating React’s virtual DOM.
JSX is <div>abc</div> turns into createElement('div', null, 'abc') and you can use that instead of JSX if you like or you can use something like hyperscript. Everything else like mapping or if statements is pure JS and works just like JS anywhere else in your app.
Vue templates mean learning Vue's custom syntax for if statements, loops, dynamic attribute syntax (with its own gotcha), binding dot modifiers, data binding, and whatever else. It requires learning its entire custom directive system. It uses custom syntax for stuff like events too.
I don't see this as remotely comparable with Vue being much closer to something like my time working with Angular 1 (a time I'd rather not repeat).
It is a massive difference. I do not like magic compilers. The JSX transform is trivial and not even necessary, just create a factory function and React.createElement becomes arguably more readable, just not HTML like.
Is it a massive difference, or is it a small difference? At the end of the day 99% of React projects have a transpilation step and utilize some form of “magic compiler” somewhere along the line.
The simplicity of JSX is overvalued. It just means more code, and typically uglier code, to achieve the same behaviour as Vue. Which is basically the theme of React when you compare the two libraries.
It is more explicit code. Something only changes when I tell it to rather than being magical like in Vue, not to again mention its proprietary DSL and API.
JSX is a very thin layer of templating logic inside JS. Meaning you have all the language features available while templating. Some arbitrary JS can result in templating.
Vue's DSL is whatever language the developer implemented. Which is probably not enough, depends how much effort they put into it and how good they are in language design. Given that they cargo cult HTML tags to organize components in a pseudo-familiar but not-valid-HTML way, I don't have much confidence in their language design skills.
While I understand the advantage of using the built-in language features (and I know why it is required to be done that way), I still think using
{enable && <Form />}
for conditional rendering, or
{collection.map(x => <Item x={x} /> }
for looping are not the most obvious choices. If you ask people how conditionals and loops are written in JS, you will get 'if' and 'for' or variants of 'while'. So I get where the v-if and v-for are coming from.
Me personally, I prefer these more functional (and more succinct) expressions. For loops are overly verbose, and not as composable. But then again, I'm a Lisp programmer.
Let's say you to render conditionally when `x` is present. You do `v-if="x"`. Now you want to refer to `x.y.z` in the body, while `y` is optional.
Can you be sure that the value is present? How do you check for it? What does Vue need to do to enable this functionality with static type checking with TypeScript?
With `{x && <>{x.y.z}</>}`, it's almost vanilla TS, it's the same as `x && x.y.z` in normal TS. Type narrowings that work in TS are guaranteed to work in React, without the framework having to do anything.
Less framework/library code required to make the same thing work. To me, that's the sign of a better abstraction and implementation.
Sorry but JS is, and always has been, a crap language many are trying to escape. So saying react has the full power of JavaScript is an antipatten as far as I am concerned. Vue is better designed.
Vue solve single source of truth much better than react though. The shape of derived data and source data (or even external data) are the same and interchangeable. So you can write an api that works with both without handling implementation quirks at all.
Money and monetary systems aren't compassionate -- people are.
Historically (in the USA), capitalism was paired with charity and supporting those around you (primarily for religious reasons).
One of the greatest downsides of the welfare system is that people don't give the money to others themselves (it's instead stripped from them and doled out without their input). They don't get to experience the good feelings that come from helping another person (only negative feelings about the government taking their money).
This removes the habits of practicing selflessness and it's positive feedback loop. As a result, we get all the downsides of capitalism with a trained selfish cohort who have no charitable feelings to counterbalance things.
There's also the other side. The beneficiaries of the system never feel the need to be grateful, as the money is legally theirs. So you end up with selfish/uncharitable on one side and ungrateful/envious on the other.
reply