391–400 of 866 posts
>> virtual DOM was a clever solution for 2013’s problems I'm not a front end expert but, I'm wondering, did anything really change since 2013 that renders the virtual DOM unnecessary? Or was it always unnecessary and people just eventually figured that out?
Earlier quoted context omitted.
And the moment you need to increase complexity in your app, you need to add back react.
I'm a counter example of your claim. Migrating away from React did made the complexity of my app a lot more manageable and unlocked new business opportunities that would have been impossible with React without following the JIRA route of making the software worse for 99% of users because 1% of those needed something. The project in question is Filestash ( https://github.com/mickael-kerjean/filestash ), what made me s…
All using plain strings, what happens when you do a typo? Will your app will silently break or you’ll have a compile time error? that’s a huge draw back - in react I can get a compile time error for a typo most of the time
I thought I'd always like the express oriented style but every single time I go back to a project I didn't entirely write it's like going to a roadside picnic of absolute gibberish that would be better off done more dumbly.
The javascript people should stop innovating for a couple of years. To much innovation that lead nowhere. How many ways can one build a web javascript project? Browser people should pick up slack and start developing sane components for the web. How about a backend-supporting combobox, or a standardized date picker across browsers? Then we wouldn't need to constantly innovate how we manage the state of those fundamen…
I think part of the problem is that browsers don't really serve their original purpose anymore. Google functionally controls just enough of a monopoly via chrome that they can generally do whatever they want (and not do whatever they don't want to do). So that standards still mostly can't do anything google isn't enthusiastic about dumping dev time into. And they're just barely not enough of a monopoly that they can'…
In the last 10 years, 3D NAND memory has scaled 10x (in bits per unit area). So… maybe not the best analogy?
React isn't winning by default. It's been so effective, so well designed that it's lived long enough to become the defacto standard... and the villian. Claiming React is slowing innovation is an absolutely bonkers take when React is essentially the only sane stable choice in a sea of "me too" frameworks and libraries with conflicting and confusing design choices.
I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password…
Earlier quoted context omitted.
I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password…
Innovation is not really measured in terms of how well something "scales down".
With the process improvements of 2025, if it doesn't take you an innovation pool of at least 16 petaquacks to display a webpage, are you even trying?
Anyone else up downscaling their innovation?
React isn't winning by default. It's been so effective, so well designed that it's lived long enough to become the defacto standard... and the villian. Claiming React is slowing innovation is an absolutely bonkers take when React is essentially the only sane stable choice in a sea of "me too" frameworks and libraries with conflicting and confusing design choices.
I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password…
Earlier quoted context omitted.
> the fact that you can only pass strings as attributes This isn't true at all though. It's a lie started in the early days by React engineers that just won't die, unfortunately. Web components are objects and they can have properties and accessors like any object. The vast majority of declarative template systems like React, Lit, Vue, Angular, Svelte, Solid, etc., will declaratively set properties - which can carry…
It is true that web components can have properties and accessors like any object. But what you cant do is pass anything other than a string to a web component's attributes in the markup. I wrote a short article about this when I was investigating web components with JsPlumb a while ago: https://jsplumbtoolkit.com/blog/2024/07/18/wrapping-data-in-... TL;DR I ended up creating a context object and a BaseComponent that…
Also, I tend to think of HTML not as my application view, but as a document that represents a serialization of your view. The actual, live view itself is the DOM. Once that document is parsed and rendered, the HTML source from whence it came doesn't matter anymore. Stringly attributes should no longer be a concern.
Though, admittedly, the HTMLTimeElement's dateTime property is still a string value. I imagine that is more of a legacy issue. The Date class in JavaScript is a mess as well.
I’ve never hit a React bug but we’ve hit like 2, maybe 3 little Svelte bugs this year. All to do with hydration though.
Earlier quoted context omitted.
I think (at least part of) the reason why React has been so successful is that is scales so well: it's actually a relatively simple tool that works well for small problems. Pair it with a Vite template or something and you can be up-and-running in minutes. But it continues working pretty well as your app gets bigger, too. But where React fails is actually in more complex scenarios. Prop drilling becomes tedious or in…
I think React can be approached a little like JavaScript at this point: just use the good parts! In my case that means using it as a rendering library and component composer, but not for managing state or side-effects.