541–550 of 756 posts
I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.
Earlier quoted context omitted.
> Nothing that is visible "below the fold" should ever run or load until the page is scrolled down by the site visitor. I really hope nobody takes this "advice". What are you trying to save me from?
I'm not trying to save you from anything. Stop being dramatic. I honestly don't care what you do or what advice you take.
Earlier quoted context omitted.
> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on l…
I worked at New Relic and focused specifically on improving page load performance for one of the products using our RUM data. Even after combining/parallelizing API calls then embedding the data into the page, I found there was still an average 3-6 second average page load cost using React vs an already rendered HTML page which was nearly instant. Not huge but frustrating to discover the constraint when it was my tas…
I would think that using React as an SPA application makes sense, but not if you want to sprinkle some interactivity inside some html pages.
Totally agree. React and Vue are overkill and bloated, and actually lead to a worse experience a lot of the time e.g. users starting at spinning loaders with broken browser functionality (like back buton) A hybrid approach of server-side views with a simple lib like AlpineJS or HTMX for dynamic bits is far better in most cases. The initial page load is blazing fast because the server does the work. Then, for things l…
Fortunately there has been some change in this area. FastHTML is a batteries-included library for Python and there are numerous standalone HTML generation libraries that can be used with other frameworks like Django, e.g. htpy, htmy etc.
I've been using alpine on a static site and it's really quite impressive just how much of "the stuff you probably want js for" it covers. So much so that you can pretty much say "if you can't do it in alpine, maybe we shouldn't do it at all".
Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…
> React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve pa…
And I have been saying this for well over a decade. Hopefully it catches on.
I have always asked for example of sites done in React where I couldn't tell it is done in React or other JS Front End. The "at worst, hundreds of milliseconds" is precisely why Web Apps never felt as good as native apps. And if we collectively cant make web apps good, why not go back to Interactive Web Pages that is mostly Jank Free. I say mostly because it is still not Native Apps level.
Recently submitted, [1] why does liking a tweet re-render the entire screen? done using [2] React-scan.
Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…
There really are only a handful of things you could do that should passably take "hundreds of milliseconds" and loading a web page is not among them. Neither is displaying a few hundred thousand things on a screen, least of all what are essentially rects in 2D. The only reason any of the above sounds fine to take this long is because the standards of web development are so incredibly low.
The only reason that 100s of milliseconds might sound fine is because there are multiple layers of abstraction between levels, but as you can see from all the other responses here the 100s of milliseconds evidently does not sound fine.
The fundamental problem with React and the like, is that it forced developers to unlearn the anchor tag. If you can change the url via js why use an actual hyperlink tag? Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.
The entire disappearance of semantic HTML tags has been sad to see. It's just all inside of inside of these days.
Totally agree. React and Vue are overkill and bloated, and actually lead to a worse experience a lot of the time e.g. users starting at spinning loaders with broken browser functionality (like back buton) A hybrid approach of server-side views with a simple lib like AlpineJS or HTMX for dynamic bits is far better in most cases. The initial page load is blazing fast because the server does the work. Then, for things l…
I've generally agreed with this but found the UI (ie. HTML) story on the backend is utter shite. Namely it's usually been handled by templates which inevitably lead to ridiculously inconsistent UIs with so much redundancy. In contrast something like JSX is really good and makes building small components for reuse natural. Fortunately there has been some change in this area. FastHTML is a batteries-included library fo…
Then you can just add Alpine as necessary.
React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have.
It means downloading MBs of javascript just to render a simple page.
It encourages multiple loads of massive json payloads for bits of the page which are then translated into html; this is a huge complexity and network tax for no gain.
It encourages constant re-rendering of page components.
It encourages mixing code and layout, making it incredibly easy for junior developers to make a terrible mess.
It encourages splitting web pages into thousands of components with poorly defined boundaries and putting lots of logic on the front end - this is disastrous for productivity and clarity when the project is of any size.
It has a bunch of legacy bits (double rendering, useEffect, useMemo, shadow dom etc) which just aren’t required and are often solutions to problems react itself created.
As to a prescription for what to use instead of react - anything else which is not ‘modern javascript’ would be a good place to start. Start with server side rendering and stateless web pages, add interactivity and dynamic loading as required.
Earlier quoted context omitted.
> I'm familiar with React. And no, links in React often don't work without extra attention. ^ These two statements are at odds with each other. React will return a pure browser link that behaves exactly as a browser link: function Comp() { return text ; } > The widgets have a click handler that opens the widget details. > > Now you right click on it. If you're lucky, it opens the widget details in a separate tab. How…
> React will return a pure browser link that behaves exactly as a browser link No it doesn't (in practice). React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself, and this can lead to the state leaking through. Yes, you don't _have_ to do it this way.
Yes , yes it does, in practice.
> React is typically used with something like React Router that takes over the whole sub-tree of paths. So links are handled by the single-page app itself,
"Taken over by Router", "handled by SPA itself" .... "React is to blame"
> Yes, you don't _have_ to do it this way.
Yes, you don't have to it this way, and this isn't React-specific. See Google's web.dev site built with web components