I've gravitated away from React towards Vue v3. Templates are working fine, well even. You still use similar amount of Javascript (probably less).

> It's just the useEffect hook. Unfortunately that's a big problem. That hook should never have existed.

Weird. useEffect is like the archetypal hook. The problem it purportedly solves was one of the main arguments they made for hooks existing in the first place -- https://reactjs.org/docs/hooks-intro.html#motivation. They just implemented it in a clunky way, and actually the problem could have been solved in an OO fashion with going to hooks at all, but now everything is a fucking hook.

There was (and still is) a real problem in react with composability. Which they tried to solve with mixins, then HOC and then hooks.

The three main hooks are useState, useContext and useEffect . useState and useContext are very straightforward and an overall improvement on their previous counterparts. useEffect was an improvement over mixins, but it was a worse solution for class component lifecycle methods.

It was fairly obvious that useEffect had a lot of problems from the get go, but it was deemed worthwhile to add so that functional programming proponents could have state without classes and to finally have a way to use composability without the horribleness of mixins and hocs (which were worse then useEffect).

The real problem is that useEffect has it's own problems, and while we no longer have the old problems, the new problems might be worse.

So instead of "do something when this action/event happens" we get "do something when this data changes". Which ends up being abused a lot, as developers who aren't familiar with this mental model (which is most of them), tend to lump up every action into a data change.

So instead of something like (contrived example):

  openAlert() {
    alert("I'm an alert");
  }
  return <button onClick={openAlert()} />

  const [alertOpen,setAlertOpen] = useState(false);
  useEffect(()=>{
    if (alertOpen){
      alert("I'm an alert");
    }
    return ()=>setAlertOpen(false); //if they even remember to unregister
  },[alertOpen])

  return <button onClick={()=setAlertOpen(true)} />

- the fact that useEffect (and hooks in general) is order dependent and can't be put inside branching (so I can't start an affect after an event happens).

- the fact that inside useEffect you read the data of the previous render is very unintuitive (I.E. your data is stale).

- the need to always put all your dependencies that are used inside useEffect in the dependency array explicitly - which can be even harder when dependencies are dynamic - is also a problem for many.

There's probably a few more, but that off the top of my mind.

The fact that there needs to be several eslint rules in order for people to not footgun themselves constantly is quite a red flag on it's own.

And are you sure the data in useEffect is stale? I don't think it is, the documentation[0] seems to suggest that it uses the current closure.

The rest I agree with.

[0] https://reactjs.org/docs/hooks-effect.html#example-using-hoo...

See "You don’t need Effects to handle user events".

React is very sluggish when updating many elements at once, for not very large values of "many". With some regularity, I've debugged React+MobX jank issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine.

None of this is perceptible on our beefy dev boxes, which is why I think people disregard it, and why the modern webapp experience is so miserable for the average person.

I see this claim a lot and I'm curious what this is based on, can somebody drop some links to further reading?

90% of the users use shitty hardware. Everything is sorta sluggish on their computers - they boot up slowly, the bunch of crapware in autorun take their sweet time to load & phone home, their wifi us overburdened with devices. Most of the software experience is sluggish for them. They don't care if their web app is sluggish too.

Anecdotally, those 90% of users are not happy about their experience, they just tolerate it.

If you are forced to use an app with bad performance (say Teams) you cope. Humans are great at coping. Maybe you turn it off and back on again periodically, or alt tab to something else while it's showing a spinner.

It's true performance isn't a major selling point but IMO that's because most software products are not sold to users. They are packaged with other products, part of monopolies and imposed to users by others.

I buy video games where performance undoubtedly matters. Apart from that, most software I use, I didn't choose, and I'm pleasantly happy when it's not garbage (Outlook, IDEA) and annoyed when it is (Teams, Facebook). In either case, performance wasn't a contributor to my choice: I didn't have a choice.

All the sluggish steps led them to the usage of the web app they need to use, and they need it to be fast. At least, faster than rest of the crap so far. Heck, they may spend rest of the day with this app..

I'm averaging a 15-30 second TTI on the most js-heavy sites.

N.B. No one is using the app from their mobiles. iPad and computers only.

Our reasons for choosing React when there are so many alternatives: prior knowledge, ergonomics, easy onboarding, ecosystem.

Actually, why aren’t web-components a thing, that’s another story. But componentization is why React creates clean code.

The reasoning I get all the time is "Why would you want to do that? That's stupid".

It's just so much nicer honestly. I'm not a react fan at all but that's one thing I miss about it.

Honestly, if anything I find react's modularity story much weaker than the competition. In react there's no page-wide state and the story around styling components with CSS is a huge mess.

In comparison, Svelte components feel much more modular & self contained because the styles are embedded with the component in a standard way.

$250 in an Android phone can get you a SD 695 5g these days. IT's not fast per say but it absolutely doesn't suck.

Most users have no idea how to remove any of it. Or, worse, they'll enable all of the preinstalled antivirus programs because they want their computer to be safe. And it gets worse. I visited my parents once and noticed something weird on my dad's macbook air. Turned out he'd gone out and bought Norton antivirus to install on it (!?). Norton installed a chrome extension which replaced the banner ads on every website he visited with their own ads. I manually deleted the extension from chrome, but norton put it right back again after chrome restarted.

If you don't believe me, use performance counters and measure it. Your website runs way slower on your users' computer than you think it does.

But the point I was making was that the average computer has actually gotten pretty good. Most users use near-latest chrome, most laptops have gotten much quicker.

And that’s before noting that the average cell phone in the US has BETTER js performance than the average computer. Most US mobile users have a modern iPhone that is faster in single core performance than some 10th gen laptops.

We still get <100ms page delivery with server side rendering and lightweight JavaScript DOM overlays. Our React infested competitors, not so much to the point their clients have been shitposting on twitter about it.

And we actually can debug our product!

React is like nearly any other tool, use it well, and it's great. Well optimized React is lightweight to the client and a joy to test and debug. That said, Web Components are even better, but I'm guessing that's science fiction to you.

Most React applications do not end up like that in the real world. They turn into poorly architected over complicated nightmares, particularly on sprawling apps which is the reality in the corporate space. Not everyone is building hyper-focused single function tools which can be crammed in an SPA type framework. And the users suffer for this.

One of the finest turds I've seen recently is my electricity company's meter reading facility which is an over-engineered react interface for a single web form with two fields and a confirmation box. The whole thing pulls 590k down to do that and takes 5 seconds for the initial page load on an M1 MacBook Pro. That's the real end game for most people. The only reason it's like that is because the people who built it don't know how to do it any other way.

And lets be honest about Microsoft: they do everything from a front end or user interface perspective and randomly discontinue bad ideas about 5 years down the line. Like Silverlight, most of WPF, bits of ATL and MFC, an entire mobile phone platform that got rewritten. And their competing framework WinUI 3 doesn't even work properly. Their own O365 web platform is a fine example of where this turns into a buggy mess. I bet react is dead to them within 2 years on one of their schizophrenic switcharoos. The only reason they're into it now is to capture some market from Electron.

1) MSFT has already used React for far longer than 2 years.

2) They have basically never used the technologies you mentioned (WPF, Silverlight, WinUI). They offer them as UI toolkits that run in their Windows environment and that’s it. Their failure to market and support these technologies is independent of what they do for their own development strategy.

3) They bought GitHub and effectively own electron now. Many of their biggest apps are on electron (Teams, VS Code, Azure Data Studio).

2. Yes they have. Half their developer tools were rewritten in WPF, they offered huge stacks including CRM on top of Silverlight and a huge chunk of windows 11 front end is WinUI.

3. Teams fucking sucks. VS Code is heading in the same direction. I've never used Azure Data Studio.

Huh? Those are Microsoft's biggest apps? Not, MS Word, the NT Kernel or ... windows 11? The XBox operating system project? Outlook express? Visual Studio? ... Github?

I'll grant that Electron is used by a few teams at microsoft. But I'd be surprised if even 1% of microsoft's engineers worked on products built with electron.

I don't love Microsoft, but it's for the best they adopt a well known and rounded framework like React, rather than try to invent yet another of their own frameworks, like the ones you mentioned. I don't know why this has anything to do with Electron, since their React push is for their front end frameworks for their main corporate product, Office365 (or whatever it's called today).

Both are not exactly light tho

I don’t have any numbers, just some anecdotal experience like the above.

It is not just speed. The UI of many sites suck too. Amazon, GoDaddy, for example.

Then there are ads. We don’t see ads in between content anymore. It is content within ads these days.

I am thankful that we can do so much online these days. But the experience could be better

But JIRA main performance issues in my experience are caused by badly sized servers for the level of use.

Jira is a 20 years old piece of software. I'm sure today's engineers do their best with the constraints they have. And I'm sure the 2002 engineers did their best with this period's assumptions and solutions.

I hate Jira as a product, but please don't attack people like that, have you never had to work on a product you're not 100% satisfied with? :/

I stand by what I said.

>I’m sure todays engineers do their best with the constraints they have.

There are two real constraints in the software engineering world: time and money (especially when we’re talking about an issue tracker, a wiki and a repo + CI\CD pipeline).

That Jira and confluences performance remains … not very good, suggests that the engineers are unwilling to, or unable to advocate for, spending the time and money to address this.

I find performance suffers mostly when media assets, advertisments, marketing and tracking scripts etc. come into play. The frontend rendering rarely makes a dent at that point.

But in most cases, front-end technology isn't the limiting factor.

No really. It is a B2B company that sells an idea to large orgs. "Know what is happening for everything and where you will be in a month.

It is not "Enable your workers to work more efficiently".

Jira simply doesn't really care about the average dev or such. In fact, most orgs use such a wildly configured version that it is pretty absurd.

Let me give you an example: Most companies have a workflow: To Do > In Progress > Testing > Done.

Foundationally, Testing and In Progress are tasks done by different operators. Jira doesn't, out of the box, conceptualize who tested a ticket and who developed it. It is all one field. You don't have seperate pointing for testing and development so you can't track QA capacity (Which is helpful to a team but not to overall planning as it just causes rushed QA). You don't have historical views of prior sprints "What was that Ticket I worked on last sprint?" (because that means nothing for forward velocity other than the final number) I could go on..but it all leads back to an absurd UI focused purely on projects and velocity above helpfulness. (And don't get me started on Jira's absurd take on SCRUM) Honestly, I'm kinda shocked no major software company has not just built their own and knocked Atlassian out of the park. I'm sure tracking velocity of other companies would be highly...helpful for Google/MS.

It's more or less one of those enterprise software packages that will be depended upon in larger orgs, because "nobody ever got fired for choosing $VENDOR". That sort of software tries to do a bit of everything, provide lots of features and customizability, sometimes at the expense of being more complex, bloated and slow.

Most people working on their own projects, when fully in control of the decision of what software they want to pick to best suit their own direct needs, might settle on something like Trello or even Kanboard instead. Personally, I self-host OpenProject because its features are a nice fit for my needs, even if it's still a bit sluggish (Rails app, limited hardware resources). Honestly, the performance of Kanboard was blazing fast when compared to anything out there - which is in no small part thanks to how focused and minimalist it is, which in some cases will be exactly what you'll want.

As another good example, I'd also put something like the Oracle database in same category: there will be many projects out there developed around it, as well as lots of knowledge, training, as well as entire professions built around it. But most people won't necessarily reach for something like Oracle XE for their own personal projects, they'll instead pick something like PostgreSQL or MySQL/MariaDB, because both of those are a little bit simpler to get started with and keep running, while still provide sufficient functionality.

This is an anecdote, but recently I launched all of the mentioned database options one after another in containers, for some testing. Oracle took around 10-20 minutes to start up an de usable. MySQL took about 5-10 minutes to become available for connections. PostgreSQL needed just 2 minutes. That's even before I get into how much data Oracle created in a container volume meant for data persistence (an order of magnitude more than MySQL or PostgreSQL).

Then i noticed a stark differences in attitude in the 2 studies I did at uni. One was more plain compsci. The other more web/mobile design and development. The later paid absolutely 0 attention to optimisation. Whether it was speed, download size or anything of the sort. The former treated an inneficient slution as invalid or at least graded lower. (Note this was in Beligum)

First time I started paying more attention to this where it wasn't when it wasn't in the context of being a budget constraint student was when I did a temporary IT support stint at a gigantic international pharma company and the software was so sluggish it was....insane. Dozens of people at our facility staring at a slugish webinterface waiting at every action and doing loads of those for every ticket. It was so infuriating I tried to make a browser plugin to prefill stuff with comon defaults the moment they were available knowing I'd never use it beyond those 3 months. Years of time must've been wasted staring at little loading circles because management did not use the software.

Then when I made native software for a manufacturing industry niche where i was told some suggested db retrieval and prerendering optimisations and such weren't worth the time....And sure. These were lowwage foreign workers using it, it didn't hamper much at all and our time was expensive. Maybe the business wouldn't get the money out of it....but then i ventured to production and notice more than a hundred people pulling the same actions many times a day thousands of times a year ....and see them waiting split seconds or multiple seconds depending on the actions that counted up to combined wasted minutes, hours, days, weeks and I realised what a load of bollocks it was.

Additionally when I helped extend various ERP's I realised the old ones were faaar from great but the move to web based interfaces really didn't do us much favours.

Then I come home and try to help my various layman family members on their comparatively slower windows and android devices and it becomes veeery apparent that this is not just a professional software issue. Slugish UI libraries on slugish frameworks on a slugish OS with various other slugish apps.

Coming home to a fast pc running Linux and using stuff i write in my free time using C++ or rust or even just various native apps on windows feels like such a extremely stark contrast.

My conclusion is that users won't care enough up to a certain point as studies show However I do believe that what those studies don't show is that for a good part this is because it's the default for many of them. They think this is just what tech is and all those countless small waittimes behind actions is normal.

Nngroup used to publish analyses of the state of usability, but I don’t think they have done one recently.

The old ones always showed progress, and that’s also what I would expect talking about the average situation.

Average progress doesn’t mean there are no shitty situations and we should always strive to improve, I just think claims like this are not helpful as they are used to make blanket statements about nuanced situations.

Unless you can back them up of course, and I would still love to see the data if anyone can find it.

I think it almost always comes down to one thing: Can people achieve the thing they want to achieve in a somewhat efficient way?

If the answer is yes there is lots of tolerance for all sorts of crap before people experience it in a negative way.

That means managing the experience. As example a multi minute upload process can be totally fine if handled properly, a .5s delay on an input can make it unusable. My point being; reality is a lot more nuanced than the blanket "it all sucks, and performance is everything" statement, and personally I don't think it's helpful. Unless we can actually look at metrics and assess their importance and how we can address them.

Don't get me wrong; we should absolutely keep trying to improve, especially crafting well made usable interfaces that are a delight to use. Performance is certainly very important, but it's not the be all end all of user experience and atm wrongly used to justify silly points why [my fav framework] is so much better than React.

The day they disable it, I’m not using it anymore.

https://infrequently.org/2022/12/performance-baseline-2023/

1. Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose).

2. Rendering/client computation speed is rarely a contributor to real and perceived performance. It's almost always the async calls - how many you have, and how long they take. It's almost always a waste of effort to try and make your framework render at half the time when 99% of your lag is a database call.

3. Framework performance is rarely a contributor to the speed of your rendering. It's most often a problem with how you structured your app. You can structure your app poorly in any framework. (I would hazard a guess that in your panel switch example a differently structured React+MobX solution would not have the problem you described)

4. There are only very few scenarios where the rendering speed between frameworks makes a perceptible difference (usually when talking about large tables or similar scenarios), in all other cases it's a difference of a few milliseconds.

2. True, it depends on the type of app. For anything that is a type of "editor" - website builder, word processor-like thing, kanban board - you operate on a data model that you save in the background. Async calls are fairly unimportant for the overall feel there.

3. To me it's hard to untangle. The reigning paradigm is declarative UI, for great reason. It's so much saner than any manual updates. But this encourages a design where you don't think about what DOM updates will really happen after an action, and this is where the problem lies. A big part of it is also the DOM model and layout. In the extreme, you have a declarative UI library like ImGui which doesn't have any VDOM, it just rerenders every frame, and it's insane how quick it does it. I haven't been able to bring it to its knees, it just maintains 60FPS constantly, with a lot of frame time to spare.

4. It's not hard for me to believe this. I didn't say other frameworks are better. Could be that the whole DOM diff approach is the culprit, or the slowness of DOM updates and relayouts.

Most of my successful work has been specifically outperforming the competition in a way that makes users choose our product. Performance is an orthogonal feature that improves all other features, and even changes what your clients can do with your system, as in making new workflows viable.

> A 2017 Akamai study shows that every 100-millisecond delay in website load time can hurt conversion rates by 7%

> 10 years ago, Amazon found that every 100ms of latency cost them 1% in sales

Also misleading to imply a linear relationship. There will be a marginal cost, but no reason to assume constant.

You're not amazon

That said, having a performant website is nice, both for developer experience and for users.

I have to say I pick solid because it's so damn fast (okok, and because it has an API which is React-like but without the crap doesn't make sense or an extra custom runtime just because)

I close sites all the time when they fail to work quickly. I have aborted orders on sites midway through when the interaction became sluggish enough that I wasn't confident in the value of the product anymore.

This statement reminds me of those Gordon Ramsay shows where a restaurant owner says "the customers like my food!" when it's obviously subpar. The fact is that the customers that didn't like the food politely go away and don't come back.

Your other points get more directly at framework performance versus other performance concerns. I have fewer opinions about those.

Products almost never compete on performance, and the biggest, most popular ones are almost always the slower ones.

Regardless of your anecdotal evidence, there is a reason why this sentiment is prevalent in the industry - because PMs and devs who thought otherwise were quickly outcompeted by those that moved faster and released more features.

Both Google and Amazon have researched this topic and the results are readily available. First link I found: https://www.thinkwithgoogle.com/marketing-strategies/app-and...

Why do you think there some much time and effort going into improving performance of computing in general. Facebook Lite, android go, GPU's, cpu improvements, 5g, etc.

The important caveat is that once it's fast enough the gains are marginal.

But if you are still at the stage in product development where adding features will increase your addressable market by tens or hundreds of percents (which doing things like ‘supporting multiple European languages’ or ‘adding google login’ can do) then those performance gains are not where engineering investment needs to go.

I use Vim and I use VSCode. There is little debate about which has better performance and which has more features. It's also easy to see which has more users.

Based off how slow every SaaS service is in the B2B space, performance isn't important in all scenarios.

Site performance is much more API based, and that’s the same regardless of frontend. React has more library solutions to optimize the UX though, as it’s the most mature and popular.

Exactly. And those API calls are going out over the network. The caller has to serialize the request into text, the API implementation has to deserialize the text into values that can be passed to a local implementation function and then the API implementation has to take the result and serialize it into the return. Finally the caller has to process the result.

That's the simple case. Things get even more involved when you start using HTTPS to secure the data in transit on the channel and using OAuth to secure the access to the API. What appears to be a simple API call turns into a lot of back-and-forths with multiple servers - with all the network latency that entails. Then developers complain their website is slow. Gee, I wonder why!

And this isn’t just about 100 ms here or there. The frequency with which clicking a button takes seconds to have any observable effect is quite high. Coupled with modern UI trends where interactive elements aren’t clearly distinguished, sometimes users can’t tell a laggy button from a not-a-button.

I suspect a massive UX study bias here. Are people looking at telemetry to try to see whether users who completed some flow are happy? Those users (a) completed the flow, so they didn’t give up and (b) are likely enriched in those users who would use your site no matter what. The marginal users of poorly-functioning websites aren’t in the data set!

You might as well say, having users is very very rarely a contributor to a product success. We're over two+ decades into the 21st Century and we're still pushing a 20th Century mindset?

Why Lord? Why?

These two things are not even remotely the same thing.

Having users is a path to monetisation but having a high performant app no one uses is not.

In fact, if you have users despite performance, it suggests you have a home run product that can be optimised for performance.

Again, you can’t optimise your way to user growth.

These two things are also not the same. You start with "having users" and assume they're willing to pay and will stick around. You compare that to "having a high performance app no one uses" - explicitly limiting the scenario with an unrelated caveat that no one uses it.

A better comparison would look only at having users vs. a high performance app, which has too little information, or having users that aren't willing to pay vs. a high performance app that no one uses, which leave you in the same boat.

I said explicitly “path to monetisation” not “assume they’ll pay and stick around”.

I hope you’ll agree that it’s easier to find a subset of users that will pay when your superset of all users is large vs a super(?)set of zero.

Do users explicitly care about how many milliseconds somethings takes? No definitely not

Do they care if the application feels slow ? Yes absolutely Do faster experiences subconsciously feel better ? Yes Does that subconscious feeling, impact metrics like sales or conversion ? Yes it does

So people do explicitly justify usage decisions with performance, all the time. Agreed that overall features win out but it's often the case that multiple products end up with broadly comparable sets of features and struggle to gain a persistent advantage there. Once you reach that point, perf can be a competitive advantage.

Yet this is what all the JS people were saying in 2014 - 2015 when everything started to become SPA. They argued this is what the users want. That's been used to justify all this stuff for a very long time if you're on Twitter. When it gets traction within Twitter it leaks into orgs. It's the same argument that's used now for all the SSG,SSR,hydration,edge and whatever other buzzword.

The internet is miserable because of all these React sites. I know first hand because my wife has a Chromebook. Yet developers won't listen because they think 6x cpu slow down is good enough to test with on their $4000 Mac book pro.

If users really don't care that much about performance then why aren't we just rendering html and sending new html on every interaction. That's much easier to do, performs pretty well from a CPU/Memory standpoint.

We've taken on a lot of complexity over the years in defense of the users. The argument I go back to is what is "good enough" and the developers/product/design I've worked with don't know what this word means.

I

Server rendering can carry less of a payload to the FE but you aren't sending unnecessary data.

This is absolutely true!

I would say that some frameworks make it easier to make mistakes. For example, Angular can be highly performant...but the automatic change detection kills performance. But wait, you can fix that! Just make your components use OnPush Change detection! ...which is not...the default? Why? In any Corporate app that displays complex UIs you absolutely need to be using it everywhere. but yet.

Personally, I think it is to make it easier for beginners who don't understand why their observables are not showing content on the page but it is still annoying to set it in every component or hunt it down. This is a small part of why we turned to using nx and generators with configurations that add it by default.

https://infrequently.org/2023/02/the-market-for-lemons/#shri...

We have a React+Redux search page where clicking checkboxes takes about that long to update the checkbox, on our good developer machines.

I won't rule out we did something wrong (this page was pretty early in our React understanding), but we've also not managed to fix it due to how much is on that page.

It was all redux’s magic and simplicity was making almost the entire thing rerender on every keystroke. Of course it was the developers fault, but it’s so easy to end in that situation that I blame the tools because to me when you shoot yourself in the foot that many times you start to ask yourself if what you have is a footgun.

Hyperbole. Web apps would not be so ubiquitous and popular for solving business problems if your claim was true.

However almost certainly ubuitity is one measure or factor in an item's usefulness. I'd also claim Usefulness inversely correlates with miserableness in the mind, but perhaps not in practice :P depending on how boring or miserable useful things are.

In general, I think usefulness overrides miserableness simply because the willingness to do useful things, despite miserableness, is clearly tolerated and performed all across human economies and societies through time. all just depends on definitions

Performance people get offended when they hear things like that. I imagine what they will tell a person who says something like this is to:

- Look at the traces. Real metrics, on real devices that users have, not the one that developer has.

- Consider either large contentful paint (will likely be subpar with client-side rendering) or first input delay (will likely be subpar with server-side rendering). Consider, too, the new interaction-to-next-paint metric (rumoured to be bad with all js-heavy sites)

If these metrics look good, then great; carry on doing what you are doing. If they don't look so good, then, they would say, reflect on whether what you are building is losing the business money by driving users away.

Someone mentioned that React is slow, it might take 200ms to update many elements.... and? Unless someone is making a fast-paced interactive game of DOM elements, it doesn't matter. Structuring the UX in a user friendly way matters infinitely more.

I hear normal, non-tech people with average hardware complain about "lagginess" of their machines all the time. And usually the only application they use is Chrome. They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond. And when you sit that person in front of a good, optimized, snappy application, they will sing praise. Not particularly because of performance, but they will enjoy using it more, and they won't be able to explain exactly why.

You'd think that with the ridiculous amounts of money software engineers are paid to do what they do, they'd be able to swallow slightly more difficult collaboration and developer experience in order to deliver a more quality product. Forgive me for being harsh, and I don't mean this as directed to you (I don't know you), but our industry behaves like a bunch of babies.

Aside: if you're making an interactive game, you have 16ms to respond and render, not hundreds. In 16ms, modern games dispatch draw calls for millions of triangles, do AI, physics, netcode, level streaming and other bookeeping. Yet the teams there collaborate just fine.

I'm aware of those complaints. 95% is when people are using a thermal throttled old device, while the app in question is trying to smoothly animate a complete clusterfuck of a webpage (for bonus points it's usually in some god-awful WebView in an app).

It's not simply displaying new checkboxes, inputs, labels, buttons, it's multi-megabyte images with fancy CSS effects and so on.

> They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond.

Of course, no questions there! But it's not because the "framework is not performant enough", it would be slow even in vanilla JS in 95+ % of situations.

> And when you sit that person in front of a good, optimized, snappy application, they will sing praise.

Yes. And it's because you say to the client/designer/productperson that hey, if you want snappiness even for the 99th percentile of your users (ranked by hardware), then let's test on that device, and let's forego that nice animation that you saw in that native app on your friend's iPhone 15 ÜberMaxPro.

And, not surprisingly, many of the aforementioned culprits will say "I want that shiny thing"

> but our industry behaves like a bunch of babies.

I don't think you're harsh at all! And I agree. Many IT workplaces went all-in with the infantilism. (Daycare for autist-savants! Colorful open-office with a playroom, maybe even a ball pit! You can't concentrate today? Don't worry, just play some table tennis, and try it again tomorrow! -- Contrast this with the endless office gray cubicle farms of the engineering departments ~50 years ago. Which is probably the other extreme of the spectrum. And I believe there's a healthy middle ground. Well maybe slacking off on HN is not exactly part of it.)

> Yet the teams there collaborate just fine.

The games industry is famously not in a "fine" place, I'd say :) But yes, of course, they have a clear target, and even if the process requires some blood sacrifice for the crunch times, it works, sometimes. Sometimes we get buggy things like Cyberpunk 2077, which was less-than-optimized for some target platforms.

Then indeed, abstractions a team can agree on matter more. Getting state management right matters. Hiring people and getting them productive quickly matters. Those are strong points in favor of React and even Angular, to an increasing degree for Vue, Svelte and others.

How can you know this? The only scientific way to approach this question is with real-user metrics and analytics.

And there are some benchmarks that show SolidJS and some other things are faster than React at specifically what React is doing (like dom manipulation/reconciliation etc).

And yes, I'm talking broad strokes!

For example, if you have a React-based wrapper around some SAP Gateway calls to replace the standard SAP UI then the user doesn't have much say. Because of the perceived better UX. The users of the solution inside companies (think multinationals, larger government etc) your call agent that use the React-based SAP portal can't really say I am not going to use it. Hands are tight.

The only time performance really matters when you have paying customers

I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. But framing non-JSX approaches as objectively inferior is not in tune with the reality, being that this is something sensible people disagree on.

It’s pretty hard to get more “this is my opinion rather than a statement of objective fact” than this.

> I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have.

Ok.

Um… well, it’s hard to have a discussion if you won’t talk about it…

…but, “code” templates allow autocomplete and type checking in a way that is an objectively distinctive superset of text templates.

It’s because they are code.

A template is (almost always) a weakly typed DSL. Written, ignoring all the history of language design… by a bunch of folk who don’t really know how to write programming languages. …and, they. Are. Bad. Not always… but often. …because writing a language is hard, and because (reason) you can’t ever use an existing template language. Oh no. This framework has to have its own unique one, because otherwise it doesn’t integrate tightly.

Do you like DSLs? Or do they just hide the complexity somewhere else? What if the DSL is bad, not orthogonal in its feature set, poorly implemented …but cute, and useful for a very very narrow use case.

Isn’t the main critique of react that it hides complexity by moving it from one place to another?

Don’t you think it’s a tiny bit ironic that all the other templates based languages with their custom template DSLs are doing the same thing?

Anyway; I think it’s fair to evaluate template languages as what they are: DSLs.

JavaScript is a better language than most template languages by a variety of metrics. Other languages are better than JavaScript, absolutely… but, never, have I seen a template language that is.

You can love declarative configuration all you want, but it’s very very difficult to argue that just because you can make a mess with procedural approaches that they are worse; because they are a strict superset of what’s possible using the declarative approach.

…so sure. I don’t but “JSX is easier to maintain”, but it’s distinctly superior in capability.

You can argue the fact JSX better integrates syntaxes from a proper programming language makes it better than other templating languages (and I’m not going to try persuading you otherwise), but the “JSX is better than template language because it is not one” stance you’re implying won’t help you win any arguments.

That is literally the difference between JSX and most other template languages. Look it up.

The template syntax is converted to literally code and evaluated. The <> are just syntax sugar. How did you imagine the inline code works? The in-line function declarations?

Did someone invent a mini-subset of JS as DSL and a custom runtime…? Don’t be ridiculous. They did not. JSX is literally a thin wrapper around actual code.

JSX is objectively better than than the scores of custom DSL templating systems out there. If anything, I think JSX is not used and supported enough.

In the most general sense, JSX is just syntactic sugar for function composition. That it works well for html components is a side effect; it could certainly be used for more than that.

I

I guess there are specific features you find compelling: it's typed, has good tooling for completions in your editor?

These exist in other template languages, and ones that transform more readily to HTML (which is the goal, don't forget).

Maybe you also value that it has a straight-forward, well-defined transformation to javascript?

That's OK, but since HTML is the goal, it doesn't seem right to optimize for an intermediate representation. To me it's a weakness of react that you have to work with HTML as javascript (which JSX mitigates fairly well, but is hardly ideal).

If you want to have it all, try Svelte.

JSX is objectively better than than the scores of templating systems out there. You get much more: type checking, use of JS for logic, and no need to learn yet custom arcane syntax. If anything, I think JSX is not used and supported enough.

In the general sense, JSX is just syntactic sugar for function composition. That it works well for html-style components is a side effect; it could certainly be used for more than that.

I wish is languages would support JSX natively, with absolutely to ties to React. Let me declare a function using JSX, e.g.,

    type Mode = “upper” | “lower”
    const capitalize = (str: string, mode: Mode) => mode === “upper”? str.toUpperCase() : str.toLowerCase()
    const join = (mode: Mode, …arr: string[]) => arr.map(str => <capitalize {{ str, mode }}/>).join()

    const joined = <join mode=“lower”>Bon Jovi /> // “bonjovi”

I understand that sentiment, but it's part of the reason why computers today don't feel faster than in the past and why we waste sooooo incredibly much energy.

MobX is signals library. In other words, you are already using the signals way of doing things if you mostly manage your state with MobX. I still use MobX as well if I think I can't use SolidJS.

SolidJs if you haven't looked has MobX-like tools built in, computed, autoruns and all the same tools, it triggers "renders" when one of the signals changes. In reality it doesn't have renders, because it's not based on VDOM, but it makes it look like it does.

However I like to keep my signal library separate, I would wish SolidJS had separate signals library I could use elsewhere as well.

Also SolidJS is big library and framework by now, it comes with risks if Ryan Carniato were ever to loose interest.

From a brief look at their website, the downsides for using SolidJs for me seem pretty big. At the very first example, if you change it slightly you can see my problems:

  const CountingComponent = () => {
    const [count, setCount] = createSignal(0);
    const interval = setInterval(
      () => setCount(count => count + 1),
      1000
    );
    onCleanup(() => clearInterval(interval));
    if (count() % 2 == 0) {
      return <div>Even count value is {count()}</div>;
    }
    return <div>Odd count value is {count()}</div>;
  };

2. The fact that the component does not rerender and that my code does not automatically change between even and odd text means I'll probably need to have an additional mental model for writing SolidJS components. Using React+MobX I just write as I would write any other function and it'll just work (There's magic involved, but manageable magic)

Composition API: https://vuejs.org/guide/extras/composition-api-faq.html

Pinia (state management store): https://pinia.vuejs.org/

TypeScript support: https://vuejs.org/guide/typescript/composition-api.html

While I mostly stuck with JavaScript, personally I found the setup more convenient to use than working with hooks in React, and Pinia is also more like MobX than something like Redux, in that you don't have to work with too much accidental complexity for relatively simple setups. Sadly I don't have examples from that project, because it was proprietary, but the linked docs are nice.

Performance on the end-user device, especially if you're just under/over certain thresholds like 1sec to switch "tabs" or whatever you're using, does matter. Especially if you're trying to get people to buy stuff.

I wish all developers had to routinely try their products on a low-end 2-year-old smartphone. That would take the discussion of whether performance matters to a more informed level.

Same. React as a UI library is great. React as a state manager (hooks) or a framework is (hooks or hooks+next) is not good. Writing and fusing business logic to a framework is always a bad idea

Conceptually the body of your component runs on every render. If you want to have some effect on your component not running in sync with that then you have useEffect to set it up and clean it up not when the component is mounted, unmoutend, rerendered ... just when the stuff you are interested in changes.

I hope we go back to server rendered sites, with vainilla javascript sprinkled here and there and abandon monstrosities like React or Angular that shouldn't have existed in the first place.

Could you expand on this. You assert that "applications" are easier to maintain with JS, but blogs are not?

Are you defining "application" here as something with dynamic and interactive content?

Also, why is it easier to "make and maintain"? I'm not necessarily disagreeing, just curious as to why you believe this.

For apps the majority of value is functionality and that's where a lot of changes happen.

The main problem of maintenance happens where there is the most change - in JSX programming (I.E. functionality) is a first class citizen and it lends it easier to change. With templates content is much more of a first-class citizen.

Of course this is all in the margins, you can write blogs/static sites well in react and applications well in template-based languages. The tradeoffs are just a bit skewed in favor of each, and it mostly manifests when you don't have time to be disciplined about changes.

I dislike when JSX is framed as "just Javascript". It's really not - it's a templating language, just a very odd one - like its spiritual predecessor.

Personally I find JSX to be write-only and hard to reason about when looking at someone else's code.

Unfortunately, React went from less-capable and more understandable to more-capable and less-understandable model. But yeah, that's just a newbie-coder take.

1) JSX - It's terrible. Svelte, Vue, Riot... they all got it right. JSX, mixing a weird syntax of HTML and JS together is just inferior to HTML with additional markup.

2) I don't know why but every react project has crazy levels of abstraction. Everything is 15 layers deep and making any sort of change requires way too much effort to navigate 15 files and code reading to make the most mundane changes. Other libraries seem to suffer from this to a far smaller scale.

<a v-on:click="doSomething">

preferable to the jsx version:

<a onClick={doSomething}>

or even this loop example from the vue docs:

    <li v-for="item in items">
      {{ item.message }}
    </li>

    items.map(item => (
      <li key={item.id}>{item.message}</li>
    ))

Then, what about conditionals? Or slots? Or classNames instead of classes? The saving grace of JSX is that it allows the creation of multiple small components inside a single file.

That's definitely not the saving grace of JSX. As I said, every react project is soooooooo overly abstracted into the tiniest little components. It's no wonder people /think/ react is slow.

    <a @click="doSomething">

Vue you can do

    <button :disabled="!isFormValid">Submit</button>

    if (!props.isFormValid) {
        return <button>Submit</button>;
    }

    return <button disabled="disabled">Submit</button>;

Edit: I donno how to format code on here sorry. (oh figured it out, bunch of spaces)

I'm surprised you see that as a disadvantage, for me that's always the biggest advantage of JSX-style syntax! I don't want huge components that do everything, I want components to do as little as necessary to be actually useful. It's the same as if I were writing functions: keep them fairly small, make sure they're doing a specific thing usefully, and then compose them together like Lego bricks.

When I was doing more Vue work, this is one of the things that I struggled the most with, that splitting one component into two components required a load of boilerplate and a whole new file. (And that itself was a big improvement on Angular, which usually had multiple files doing different things, at least when I was last using it). This inevitably meant that I'd try and fit more and more stuff into a single component until it the pain of maintaining it was greater than the pain of splitting it. (At which point it would usually be a lot harder to extract the would-be child component than it needed to be, because I'd left it too long.)

I think the rest is mostly just syntax preferences. Like you say, you can write bad code in both cases, and I think a lot of it comes down to which matches better to your mental model if what HTML generation looks like. But being able to easily start a new component, just like starting a new function, is such an important benefit of JSX, for me at least.

That said, SolidJS as a whole requires a completely different mental model of rendering, even if it does look superficially similar to React. It's also a much smaller ecosystem, with less documentation, so getting to grips with it is that much harder. Very rewarding, but probably not ideal for everyone right now.

Oh, I didn't know that about Vue. Eww!

Having lots of tiny components makes it harder to see the big picture.

Too big and too small are both bad, there's a balance you need to find. Components should be small enough to fit in your head, big enough to represent ideas. The difference is that it's natural for big components to be broken down into smaller ones when their size starts to cause pain. But nobody goes around merging smaller components into bigger ones to make them more readable. When your components are too tiny people just suffer through the pain and develop Stockholm syndrome.

> I'd try and fit more and more stuff into a single component until it the pain of maintaining it was greater than the pain of splitting it

I understand that it seems painful, but this is actually a great workflow: it forces the decision to split to be based on the real pain, not on your fantasies about future pain. Pain is a tool that helps you make good decisions. In that sense React is like Perl: easier to write, harder to reason about.

This isn't a theoretical concern either. Like I said, I've had this issue with Vue before, and component sizes just bloated to the point where many pages were just single, chaotically interwoven components with dozens of state variables that theoretically were never used by each other, but in practice tended to be shared accidentally or out of short term convenience. At which point all bets are off and every bug becomes an exercise in figuring out what's going on.

That's not to say that that's a Vue-specific problem, because I've also had that issue in other frameworks, including React. But far less often in React, because it's much easier to deal with the pain when it starts with a simple refactor, than dealing with it a year and several new features down the line when everything is tangled together like a headphone cord in your pocket.

In JSX, the "disabled" attribute is a boolean; so it would be just:

    return <button disabled={!isFormValid}>Submit</button>;

The issue is people write SO much conditional logic into their react templates. Not that disabled is boolean and can be written better.

This seems to be a 'best practice' issue as well that can be avoided through PR review. My team has been putting logic more and more into local hook files to keep components clean.

People break tables up into ~50+ files. It's crazy, and everyone does this, and its an absolute nightmare to maintain. Its 100% engrained into react culture that this is the right path forward.

React will never get better if people accept over abstraction as the right path forward.

I do not understand why everything needs to be a single page application. Sure, my current employer is behind the times in the technology we use, but honestly, we survive just fine with server side rendering and plain, ol'boring, vanilla Javascript and a little JQuery here and there.

Of course, some things we have written are difficult to maintain at times, but I doubt any other library would have really made it simpler (more of an issue with the requirements than the technology). Abstraction is simple, for us at least.

The DOM output that Lit produces, peppered with magic comments, looks disgusting though :-(

Hard disagree. Every time I work with Svelte\Vue I wish it had JSX, which is way superior to templating because:

- Creating sub components in the same file is super important. Going to a separate file, copying all the imports, writing emits, then going back and importing that file is too much hassle for a simple case where you have a carousel with cards. Refactoring is slow, components end up bloated.

- Passing down functions is more convenient than emits. For all the talk about how svelte is boilerplate free, it's equivalent of passing down a function and calling it is at least 5 extra lines of code.

- Passing down JSX elements is more convenient than slots. Every time I need to remember how to do named slots in vue\svelte I have to read documentation, while in React the mental model is obvious.

or you could try the newfound craze: signals.

I played with Vue and svelte and now a firm React user, mainly due to its ecosystem, for most products the slowness of React does not play a major role at all for me.

> People tend to compare these frameworks on things that don't matter - often it's performance.

Performance matters in a lot of contexts. If you’re doing complex stuff performance matters. If you’re a public facing site depending in search traffic performance matters.

I’ve ended up disliking React simply because it’s become this one size fits all solution that 90% of web development goes through without it ever being necessary. There’s nothing wrong with React itself but it’s often applied badly.

I think I reflect the entirety of the user base of the internet when I say "fuck you" (not you in particular, just the trend of shitting on performance so we have apps running like it is 70's and tape drives on our gigahertz CPUs) here.

You're a react guy, alright.

This also happens in the backend, but the difference is that the company país the price in the form of more infrastructure. But in the frontend is “free” so why care at all, right?