> (This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.
Networks are fast. Machines are crazy fast. Almost 30 years ago I was doing on-line adaptation of Postscript print files. So some form input and re-rendering the Postscript with the updates from the form values. Basically instantaneous.
Check out google maps there’s more to the world than your open office.
2. The Javascript bloat hurts those devices immensely. See "Performance Inequality Gap 2024" https://infrequently.org/2024/01/performance-inequality-gap-...
https://infrequently.org/2024/01/performance-inequality-gap-...
I did it the simple way and bought a first item in "sort by cheapest" smartphone list. That's Alcatel 1, and it's extremely underpowered. It's maybe a bit overkill, but if something runs on that device, it will run amazing on anything else.
"The A51 featured eight slow cores (4x2.3 GHz Cortex-A73 and 4x1.7 GHz Cortex-A53) on a 10nm process"
Looking at Wikipedia, it also has at least 4 GB of RAM and comes with 4G Internet.
The Alcatel 1 also seems to have at least a 1 GHz CPU and at least a gigabyte of RAM.
I also had a look at the Samsung Galaxy Watch. Lowest spec I could find was 1 GHz dual core + 768MB RAM (bluetooth), 1.5 GB (LTE).
The machine I was doing the web-based Postscript rendering on was a PowerMac G3. Single core 32 bit processor running at 266 MHz and and with 192MB of RAM. Connection was early DSL, 768 KB down, I think 128 KB up.
I did not do any heroic optimizations, it was fast "as-is".
So I think my point stands that modern computers, including low end Smartphones and watches are incredibly powerful and fast, including the networks.
If your tech stack manages to bring that hardware to its knees for basic UI rendering, and requires a lot of optimization effort to run barely reasonably, then there is something fundamentally wrong with your tech stack.
Yea, I think this is the problem, but the hard part is that it's largely outside of your control on the web. Alcatel 1 is technically a super computer, but it can't even run its own UI properly. I optimize my websites on it and while laggy, they sometimes run faster than Chrome's UI that displays them, it's crazy.
Running the system + the browser is already way too much and there's almost no perf budget left for the website - and it doesn't help that web tech is inherently sub-optimal in many ways, so you're already pessimized on all fronts. Even a baseline a simple page with almost no content is laggy on this device.
On the web or in the JS ecosystem?
While I agree that even just the browsers are monster applications, usually duplicating (at least) the entire OS they are running on, just usually worse.
However, most browsers are perfectly capable of extremely snappy rendering and interactions, even on low-powered devices.
Let's remember that WWW.app was developed on a NeXT Cube, 25 MHz 68040, probably in the 16-64 MB RAM range (min was 8, but I am assuming it was more than the min), and that was plenty snappy.
> On the web or in the JS ecosystem?
I meant outside of your control on that device.
Are you claiming that even plain/styled HTML is too slow on these kinds of devices?
Sites like Hacker News and textual blogs work pretty fine if you get lucky and nothing is running in the background, but you have to wait for a while for the phone to stop crunching stuff. The scrolling has noticable latency and random hiccups. If you scroll too fast, the content will show up delayed.
Once you add some images or a bit of javascript, you start to feel a lot more jank. You often get a perf hit when you recieve push notifications or when you re-connect to wifi, or open a native keyboard accidentaly, same with triggering browser UI or tapping the back button. Also, the browser sometimes just crashes (I guess out of memory?).
It certainly is usable, but the latency variance of various actions is wild. Sometimes it feels ok to use, but other times the whole session is like 1 fps for 5 minutes.
Isn't the runtime state optimization the only responsibility of React. It's a library. The rest goes for Vite, Deno et al.
Well, it depends on what you mean by “fast”: bandwidth or latency? While the bandwidth has improved enormously over the years, latency… not so much. And it never will due to the simple fact that the speed of light is limited.
Most of the slowness seems to come about by treating latency as something that doesn’t matter (because the testing is done on a local, low-latency network) or will improve radically over time because bandwidth did (which it will not).
Unfortunately, React wants to be both a rendering library and also manage state by tying it to the component lifetime, which encourages cascaded fetching - exactly the kind of workload that is sensitive to latency.
Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control.
Characterising it as "if the developer cares" puts the blame in entirely the wrong place.
I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.
Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.
Because they are what we called script kiddies back then, copy-pasting from SO and now LLMs.
I do not even know if they would classify as "junior" devs.
This does not apply to ALL web developers, but many.
proceeds to shame and suggests changing to the new paragdigm of the year.
> For a framework meant for serious adults
And the sentence you quoted is a dig at React and the React ecosystem, not individual developers.
Nice try, though!
If I were making a component rendering type library before React I would probably end up making some fake attributes on HTML elements the way Angular and a lot of other people do. It's a pretty simple idea. Pretty much everybody was doing it about the time of Backbone and Angular etc. etc. I'm sure you can think of other examples.
But whoever first came up with JSX said hey, if we're already making non standard HTML why not go all the way, allow you make your own semantic tree that we "render down" to HTML.
This of course allows you in fact separate out the media target - HTML, Native App, PDF, graphics from your renderable representation of that in code, and thus have different renderers for the same declarative way of structuring content.
https://github.com/chentsulin/awesome-react-renderer
So to me JSX is actually a sensible step up in abstraction layer, although not all the way yet, because you still need to have lots of specific knowledge of your particular media rendering target.
This is perhaps of particular interest to me as in about 2004 I was working on a media management system where the idea was you would feed in multiple markup formats, and a configuration for the media, and then use an in house declarative language to dynamically do things in each media, without having to have much understanding of how the media worked internally because our rendering pipeline took care of that - generated pdf, DHTML website (fancy menus), HTML help, and emails - with of course possibility of saving data for reuse in different media and cross media styling (use same company logos, color schemes, email addresses without having to write code for them in each media etc.)
sorry about last part, old programmer wandering.
I'd also say React's one way data binding was a big step forward when it was released. Where it (and TBH, many other SPA frameworks at the time) missed the boat was form handling, which it turns out is like 90% of the Internet and internal applications.
I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so.
However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.
React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks.
Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc.
PM: Looks great! Okay, the next thing is...
Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off.
PM: This looks fine. Let's move on to the next thing..
Are your designs huge ?
Like a super low budget Balsamiq
But the system persists because both people are complicit.
Why don't those developers that care put important things the AC/DoD?
The blame for not caring enough about performance and UX is on the whole industry. That does include developers, but not just them.
It has nothing to do with the frameworks. Except maybe that they empowered developers, including the ones cranking out bad code
I built much more performant apps without lazy loading or caching when using html and a sprinkle of JS.
Key: when user clicks on something, this causes 0 to 1 HTTP requests.
We didn’t do lazy loading or caching either.
Let's say tracking for revenue is required and not an argument to be made. The question I never quite understand is why cant we have ONE scripts to rule them all? I remember there was a company / services that may be called Segment? And quick google search doesn't have anything familiar, that offers something like that.
Because those tracking scripts are provided by competing advertising platforms and they want to own the data.
Only if you show the ads. Many companies do not, but still use lots of trackers. Why? Because their performance marketing team is trying to find the right mix of advertisement channels, so they go for paid search and clicks to Google, Meta and lots of other AdTech. In that case trackers are needed to optimize spending by analyzing user behavior. If certain cohort spends more time on the site, they will get more ads of it. If another cohort leaves the site quickly, they will see less ads. The promise of AdTech in general is that they personalize ads as much as possible to reduce your customer acquisition costs (CACs) - you won't waste money on showing ads to people who won't buy your product. So they need the data and they have to own it, because personalization is their competitive advantage.
So they make it harder or more limited to integrate with tools like Segment.
Just the other day I was appalled by a new record, 1604.
I'm increasingly of the opinion this stuff needs to just be banned outright by law. None of the businesses I've talked to seem to be aware of how dishonest it looks to say "we value your privacy" while trying to get users to agree to get more companies than there were pupils in my secondary school to analyse them.
I didn’t even know there were 1600 different distinct trackers around.
But for this to be effective, the browser should be cooperating and working on the user’s behalf to limit tracking. (You know, the whole reason why WWW calls it “user agent” — it should be on the user’s side.)
Unfortunately >90% of browsers use an engine made by the greatest beneficiary of user tracking. Hundreds of billions in future profits might be endangered by giving users actual control. The proverbial fox guarding the hen house.
I hear Microsoft is working on a new browser that gives the user more control over cookies:
1. It shows a confirmation dialog before setting a cookie
2. The site can declare a machine readable policy (P3P) specifying what the cookie will be used for, which the browser uses to automatically decide if the cookie should be permitted.
They plan to call it "Internet Explorer" or something.
1. React is bigger and slower than it needs to be. There are likely better choices today. 2. Most websites will be bigger and slower than they need to be due to the endless September of new devs, and the rarity of being given space to focus on size/performance. As React is popular, it means even if React was tiny and fast, these websites would still be slow.
These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.
The fact is that plenty of teams are mature and professional and yet most software still suffers from bloat, slowness, bugs.
Preact is only 5kb or so, and has almost 1:1 feature parity. It's not fully drop-in without the compat, and even experienced React devs can nitpick about it, but that's not the point: the mere fact that it exists and gets the job done is enough to raise doubts about the need for React to be quite big.
Does React need to lose weight? Maybe, maybe not. But I don't think it's good to shut down those discussions.
When the complexity is low, projects are easy to learn, maintain and handle. That really makes them seem better and have advantages – advantages like a much reduced bundle size. But these new setups just don't do the same thing. It's a shell of what the old project did, as it's missing solutions for hundreds of edge-cases and other requirements that were tackled by the mature many-year old project that is maintained by some of the best developers. I'm sure React has a bit of bloat, but I'm willing to trust the React team that the vast majority of it is there for a reason. It might also be the cost of building on top of a very mature solution.
Would you not shut such a discussion down when someone new in the team proposes a complete rewrite?
Preact does not have 1:1 feature parity, if it had it would have been much more widely used (who wouldn't want a free filesize reduction?). Preact has plenty of issues, which is why it isn't as widely used.
> Preact does not have 1:1 feature parity, if it had it would have been much more widely used
Like another poster said, this is a logical error. Preact is fully featured.
I use Preact often and very, very rarely run into an issue that justifies React being almost 20x the size.
That's a false logical conclusion.
Preact (and others, like Svelte and Solid) are not only "as feature complete as React", they don't need some of the features of React (hooks are unnecessary when you have proper reactivity) and they are better at certain features (like SSR).
People using or not using them has nothing to do with feature completeness.
E.g. you don't need React hooks because Preact has signals: https://preactjs.com/guide/v10/signals/
Does this mean that Preact doesn't have feature parity? For a very strict definition, no it doesn't. Does it mean you need to sacrifice anything? No.
Same goes for many other frameworks. In modern landscape when it comes to features and abilities React is actually quite a poor offering.
I think this is an overly dramatic take. Of course react has a fixed overhead. If all you're deploying is the single button, then that overhead is for no benefit. But the overhead gets amortized over your entire app, which most likely has thousands of components. This is like a microbenchmark which only measures the static overhead. Not indicative of a real app.
There's an entire cottage industry of "react" but smaller frameworks out there. Somehow, none of them have caught on.
Preact is the one I'd go for if I wanted a smaller react because it's quite mature and it provides the same API.
It just doesn't to me, understanding that in react-land, a single component and an entire app will have roughly equivalent size, if you're not pulling in any other dependencies.
No one (I hope) would ever use react for a single button, so it feels like an unhelpful comparison.
If you tried to use photolitography (the technology used to print the circuits in microprocessors) to do tattoos... well it could probably work, but it would be highly inefficient and expensive and bad.
React is for complex web applications, and it I don't think it's a very valid criticism to say that it is bad for a different use case. To some extent, the React community may have over-promoted React as the final web-dev framework, but that's also a mistake.
In any case, kudos on creating Nue, looks really cool, I'll keep an eye on it ;)
> The issue is that these huge frameworks have made the web a horrible slow mess.
I don't think this is accurate. Most bloat in the web is caused by:
a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
(This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
(I remember being shocked, some years ago, when I saw a site with 50 trackers. May be it was The Verge? Or some newspaper? Now I don't even bat an eye when the number is in the hundreds.)
React sites can be extremely fast if the developer cares, and the bloat it introduces is rarely relevant. The OP article describes a button as 78K, but that's because it's loading the whole of react for just a button.
If your page has hundreds of buttons, you don't bring 78K hundreds of times, and so complex sites built with React are not that inefficient.
As a Devops engineer, do you have stats on how much of that slowness is the framework or the actual app code?