The Market for Lemons(infrequently.org)
infrequently.org
The Market for Lemons
https://infrequently.org/2023/02/the-market-for-lemons/
168 comments
> if they can't they will go somewhere else and then you need to find new developers and everyone knows there aren't any available
The recurring resume-requires-React pattern sure isn't helping.
The recurring resume-requires-React pattern sure isn't helping.
No "isomorphic" please. Please don't moving forward with js-everything, that's actually moving backward.
> "why is this market so inefficient?"
I don’t know, but I too have felt this for the last many (10 or so) years. And not necessarily just web.
I think the answer lies in part in this line:
“The complexity merchants…”
With so much free money floating around, software development has grown more bureaucratic than ever.
I’m not sure how effective emphasis on IDEs, processes, or languages really was 10+ years ago. But the fact that “being more efficient, higher productivity for lower inputs” was something people paid money for indicates (to me) that it was a priority more than it is now. When the economic model becomes “throw money at moonshots looking for the next 1000x thing” then inefficiency is going to take a back seat.
One of the truly amazing things to me is the increase in specialties that must exist and cooperate to deliver/maintain products of any size.
I don’t know, but I too have felt this for the last many (10 or so) years. And not necessarily just web.
I think the answer lies in part in this line:
“The complexity merchants…”
With so much free money floating around, software development has grown more bureaucratic than ever.
I’m not sure how effective emphasis on IDEs, processes, or languages really was 10+ years ago. But the fact that “being more efficient, higher productivity for lower inputs” was something people paid money for indicates (to me) that it was a priority more than it is now. When the economic model becomes “throw money at moonshots looking for the next 1000x thing” then inefficiency is going to take a back seat.
One of the truly amazing things to me is the increase in specialties that must exist and cooperate to deliver/maintain products of any size.
“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.” - Dijkstra
That quote comes from here [1]. A few lines later, writing about a talk he had given at a software company, he says:
[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...
I gave a beautiful lecture, which fell flat on its face. The
managers were horrified at the suggestion that flawless software
should be delivered since company derived its stability from the
subsequent maintenance contracts. The programmers were horrified
too: they derived their intellectual excitement from not quite
understanding what they were doing and their professional
satisfaction from finding weird bugs they had first introduced in
their daring irresponsibility. Teaching the competence to program
boils down to the training of misfits.
[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...
> Teaching the competence to program boils down to the training of misfits.
Haha. Ohh geez, herding cats.
Of course, the joke is I can have the most consistent, predictable engineer ever. He gives me a constant stream of ones. Always passes the test. But I don't even know what Zero means.
Anyways, in the real world I've just had a major issue dumped in my lap and I just need to stop the fucking bleeding in a complex system.
Haha. Ohh geez, herding cats.
Of course, the joke is I can have the most consistent, predictable engineer ever. He gives me a constant stream of ones. Always passes the test. But I don't even know what Zero means.
Anyways, in the real world I've just had a major issue dumped in my lap and I just need to stop the fucking bleeding in a complex system.
[deleted]
> I’m not sure how effective emphasis on IDEs, processes, or languages really was 10+ years ago. But the fact that “being more efficient, higher productivity for lower inputs” was something people paid money for indicates (to me) that it was a priority more than it is now.
It is important to look at these things in a context of software fads... Back when Google/Facebook got big around 2007-2008 it was all about big data cargo culting, then era of frameworks & efficiency & productivity, following that epoch of apps, after that we've had blockchain, and now AI & chatGPT are "eating the world".
Of course in the middle of that we've also had a huge bull market with tons of money thrown at everything.
It is important to look at these things in a context of software fads... Back when Google/Facebook got big around 2007-2008 it was all about big data cargo culting, then era of frameworks & efficiency & productivity, following that epoch of apps, after that we've had blockchain, and now AI & chatGPT are "eating the world".
Of course in the middle of that we've also had a huge bull market with tons of money thrown at everything.
I think part of the problem is the nature of ownership versus a salary. Would you rather have equity within a company and partake of the profits, or would you like a nice salary?
I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount.
I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount.
As someone with equity I always assumed everyone wants equity. I've come to discover that most people just want a nice stable salary.
The incidence of "owners" is higher in tech, in part because its an easy way to start a business. Low capital needs, cheap equipment, no formal qualification required, and lots of examples of success to emulate. In other words equity in computer startup is highly attractive to those who have that bent in the first place.
>> I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount.
In my experience this hasn't always worked well for me. Those that favour equity often end up going off to start their own business, where they get more equity, and don't have to deal with pesky folk like me. It's certainly worth a try, but I think you'll discover that most people just want a salary.
Equally, my advice to workers is to get a good salary first, and consider options et al to be likely worth nothing. For equity to be meaningful it has to be substantial, and you just don't get infinite substantial slices out of 100%.
Of course if your company is google successful, then great, even tiny slices make millionaires. But its vanishingly unlikely that your company turns out like that.
I'll end with this - you have a thesis and it's certainly worth a punt. If nothing else it's valuable data for your next business. It'd be great if your thesis works out (for your sake I hope it does) but be prepared for unexpected outcomes, and try and recognize those outcomes early. Perhaps, just perhaps, there's a reason most companies don't work like this.
The incidence of "owners" is higher in tech, in part because its an easy way to start a business. Low capital needs, cheap equipment, no formal qualification required, and lots of examples of success to emulate. In other words equity in computer startup is highly attractive to those who have that bent in the first place.
>> I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount.
In my experience this hasn't always worked well for me. Those that favour equity often end up going off to start their own business, where they get more equity, and don't have to deal with pesky folk like me. It's certainly worth a try, but I think you'll discover that most people just want a salary.
Equally, my advice to workers is to get a good salary first, and consider options et al to be likely worth nothing. For equity to be meaningful it has to be substantial, and you just don't get infinite substantial slices out of 100%.
Of course if your company is google successful, then great, even tiny slices make millionaires. But its vanishingly unlikely that your company turns out like that.
I'll end with this - you have a thesis and it's certainly worth a punt. If nothing else it's valuable data for your next business. It'd be great if your thesis works out (for your sake I hope it does) but be prepared for unexpected outcomes, and try and recognize those outcomes early. Perhaps, just perhaps, there's a reason most companies don't work like this.
The reason people don’t want equity is that equity is usually irrational once you get beyond a handful of employees. If you are employee #3 and you got 10% equity, sure that could make sense. You have enough impact to influence the value of that equity a lot. If you are employee #20 and you got 0.3% equity, hell no it doesn’t make sense. Employees #1-19 are getting all of the gains from your above-and-beyond efforts. You might as well work at a NGO.
That works once you are profitable enough that the salaries are enough to cover sufficiency. however, if I am taking on the risk of no salary, I not only need substantial equity, I also need control. It's going to be my company.
Now, if what you're trying to describe is a co-op, that's interesting and you should look into that literature, but it is no longer "your" company alone.
Now, if what you're trying to describe is a co-op, that's interesting and you should look into that literature, but it is no longer "your" company alone.
I'm looking into co-op/b-corp. My core model is that I want to create a system where people can contribute at a task level and get equity. An "upwork" for people that want income streams rather than payouts.
"100% equity players" isn't matching for ability or work ethic though, it's matching for employees that have savings instead of mortgages...
Yes, because that is my boat. I'm only working 5-20 hours a week. At core, I want to figure out a way to get other part-time people in to contribute to a cause and then profit if the cause is good.
Sure I'm on board.
I just want to check first that my mortgage provider, landlord, utilities company and supermarket all accept equity...
I just want to check first that my mortgage provider, landlord, utilities company and supermarket all accept equity...
Awesome.
The first step is to save and discover freedom.
At core, I want an open company building open source where people can get an effective royalty on contributions. I'm writing my thoughts on this, and I may revert if it turns out to be a bad idea.
The first step is to save and discover freedom.
At core, I want an open company building open source where people can get an effective royalty on contributions. I'm writing my thoughts on this, and I may revert if it turns out to be a bad idea.
"The first step is to save and discover freedom"
And make sure you don't have kids, health issues, etc etc.
You are shrinking your pool of talent quite a bit, don't you think?
And make sure you don't have kids, health issues, etc etc.
You are shrinking your pool of talent quite a bit, don't you think?
How do you avoid “too many cooks in the kitchen” syndrome? As an idealist, I love what your advocating. I dream of idealistic egalitarian societies.
Sadly I’ve been forced to accept that many employees will happily enter into workplace codependency relationships that allow them to offload risk from themselves (e.g doer-decider duopolies).
Sadly I’ve been forced to accept that many employees will happily enter into workplace codependency relationships that allow them to offload risk from themselves (e.g doer-decider duopolies).
> many employees will happily enter into workplace codependency relationships that allow them to offload risk from themselves (e.g doer-decider duopolies).
This sounds interesting but would be helpful to have some more explanation of what you mean by this.
This sounds interesting but would be helpful to have some more explanation of what you mean by this.
At core, I'm looking for people that want to come and go. At essence, if there was an upwork for equity, then I'd use that.
As an example, I'd post a task "write a language tool to automate generating the code and tests for the type system" and offer 100 shares. Is it the end of the world if the task doesn't get done, no. Is it marginal? probably. However, is it a neat problem, yeah!
As an example, I'd post a task "write a language tool to automate generating the code and tests for the type system" and offer 100 shares. Is it the end of the world if the task doesn't get done, no. Is it marginal? probably. However, is it a neat problem, yeah!
The core problem that I see is that I have no idea what "100 shares" in your startup even means on practical level and no way of realistically valuing them. Even if I'm happy in principal to work for equity, without getting a lawyer and an accountant involved I'd kind of have to assume that the dollar value of those 100 shares is zero, and act accordingly.
> I'd kind of have to assume that the dollar value of those 100 shares is zero, and act accordingly.
Exactly, I want people more interested in the art rather than the finances. However, once I get some profit generated, the model I want to pursue is that every month the profit from the company is distributed.
Exactly, I want people more interested in the art rather than the finances. However, once I get some profit generated, the model I want to pursue is that every month the profit from the company is distributed.
Sure thing - I would like the same equity as you have. Do not be shocked however, when after a day, with my equity in my pocket I wander off and do something different.
The model that I'm going for is an upwork for equity. "Here is a task, it is worth $X shares and there is a dilution schedule. Profit is currently $Y with $N total shares, profits are paid monthly $Y * $X/$N.
It's a mess, but if you solved a problem that I thought was worth a number of shares, and then left... great!
It's a mess, but if you solved a problem that I thought was worth a number of shares, and then left... great!
How large are you aiming for? I suspect beyond around 5 people this falls apart due to either the value of the specific skill at the time matching the current profitability poorly, or the protective clauses that would be needed in a contract making it very difficult to hire talent.
A core idea that I keep coming back to is an "upwork for equity".
I'm not a fan of clauses and believe, especially as an old man, to give back via open source.
I'm not a fan of clauses and believe, especially as an old man, to give back via open source.
A recent blog post making similar points: https://laughingmeme.org/2023/01/23/software-and-its-discont...
Good read there. I think there’s a missing complexity from his list. The complexity of abstractions. Working in software often feels like advanced philosophy now days.
The money has something to do with it. But with too much money in the system. People hoping jobs too quickly. And the accountability loop for producing bad systems is short circuited and ineffective. Hype cycles where young devs never see the other side where they fall flat.
It's the engineers and orgs, not the tools.
It's the engineers and orgs, not the tools.
Does anyone else find this writing style hard to follow and alienating? The clever section titles, verbose passages, inflated vocabulary, and indirect descriptions, make it frustrating to read. Just say things directly.
The writing does a horrendous job presenting an argument. The author constantly references events and trends but does not focus on specifics until much later in the post. Even then, he paraphrases, making it even harder to judge the evidence.
This stylistic choice seemed like part of the point. When people are writing JS, they often do the same, resulting in unmaintainable messes.
Author of the article here.
TL;DR: your JS is probably worse than you think. Write HTML and CSS instead. It will go better for everyone. And feel free to ignore the most popular JS framework vendors; they have not known what they are talking about for at least a decade.
TL;DR: your JS is probably worse than you think. Write HTML and CSS instead. It will go better for everyone. And feel free to ignore the most popular JS framework vendors; they have not known what they are talking about for at least a decade.
I am sorry but i don't think that will work. Speaking as someone who tried to implement a fairly complicated ui in plain JavaScript and jQuery, i ended up shooting myself in the foot while writing code that updated the state of the application correctly.
React actually made this a non issue. There are use cases where vanilla html/css/js is just not the best tool.
React actually made this a non issue. There are use cases where vanilla html/css/js is just not the best tool.
honestly man, while I kind of agree that your writing style is a bit hard to parse as a logical argument, as a 'feeling?' it feels exactly the way I've been feeling for at least the past five years.
Great. Use Next.js and write SSR code, using JS and CSS modules, which outputs HTML and CSS, and use optional client side hydration for client facing functionality. SPAs are fundamentally bad for most websites, but don't confuse them for all JS frameworks. Once you need to do something as simple as turn some data into HTML (like loop over it, filter it), the premise of your article doesn't work.
Having done a lot of both, I prefer HTML and CSS for documents and statically typed, React-like component-based reactive libraries for apps. Building an app with just a smattering of JS goes well until it doesn’t, and requires a lot more discipline due to the stringly-typed nature of it.
Do you have any examples of well trafficked sites with good UIs doing things well? It would seem that there might be outliers you might be able to point to
Most are from a world that is better, but which the complexity merchants have convinced (thanks to asymmetric information) all but their closest competitors to replace with unwieldy tech.
E.g.:
https://app.speedcurve.com/benchmarks/usa/retail/fast/fully-...
The fast sites on "legacy" stacks have 1/10th the COGS for the same performance versus the absolutely stupid costs invoked for React/NG/Ember/etc. SSR + hydration.
Which brings up the real issue: when the framework is both baseline-costly and runtime nasty, metrics like INP will suffer without extraordinary controls. When you see a React site in the list above, it's a fair guess that I've talked with their tech teams and they have felt trapped between unsubstantiated narratives and the reality that shipping React-based sites is losing them tons of money.
The antidote is a frank discussion of up-front cost vs. per-interaction latency. And we aren't having that debate right now. Presumptively the careers of the last decade's charlatans depends on us not levelling up. It's the only reason I can peep for why we haven't evolved past new ways to spell old ideas.
E.g.:
https://app.speedcurve.com/benchmarks/usa/retail/fast/fully-...
The fast sites on "legacy" stacks have 1/10th the COGS for the same performance versus the absolutely stupid costs invoked for React/NG/Ember/etc. SSR + hydration.
Which brings up the real issue: when the framework is both baseline-costly and runtime nasty, metrics like INP will suffer without extraordinary controls. When you see a React site in the list above, it's a fair guess that I've talked with their tech teams and they have felt trapped between unsubstantiated narratives and the reality that shipping React-based sites is losing them tons of money.
The antidote is a frank discussion of up-front cost vs. per-interaction latency. And we aren't having that debate right now. Presumptively the careers of the last decade's charlatans depends on us not levelling up. It's the only reason I can peep for why we haven't evolved past new ways to spell old ideas.
This is looking at the "fully loaded" time. I can tell you this, you can make the fastest retail website ever seen with 100 score on lighthouse and it's going to get absolutely murdered when you try to deploy it.
The business will want pixels. Data analytics. AB Tests. Social buttons. These will be attached to million dollar campaigns. You do not get to say no. There goes your "fully loaded" time. Every client side event is now wrapped in nasty JS beacon reporting, probably a few of them.
The home page team wants recommendations that can't be cached. It's determined to fetch this on the client to enable a faster TTFB. All those products need to fetch images, too. The time to interactive bumps up a bit.
After a while, it turns out even the CMS static content wasn't safe. The CMS team wants interactive elements. You hack a little more JS. The time to interactive bumps up a bit.
The checkout team has a more dynamic approach because of the user expectations. They use some packages they want preloaded because the metrics tell them that getting to checkout faster means more conversion. More unused JS to load on the homepage in case of clicking "add to cart." You might argue about it, the button could take you to the cart page and the server could perform the add to cart. Maybe you win and implement it. This version fails the AB test.
After a while of this, the team chafes at plain css. Just 10% of it is still used on the homepage and people are afraid to delete things because it's so hard to know what the effect is across the site. The common css continues to bloat for forever. Some day, years from now, it's such an unrecognizable mess that the decision is made to delete and start over.
The JS isn't aging well either. Just writing script tags led to poor reusability and breaking the browser cache too often. Pretty early on somebody added rollup and a major project is done to clean up script tags. Progressively enhancing the "legacy framework" html worked well in the beginning but now you're staring at a mile long bug backlog of reports like "when in this state, click this thing and then click the other thing and it's not showing expected x."
Worse, you can't hire any frontenders. Gone are the days when frontend would also know whatever "legacy" backend framework you have. They don't want to work in PHP or Java or whatever, they want to specialize in the frontend. Most of your frontend team joins, complains loudly and leaves inside a year.
I've lived this nightmare a few times. I have cleaned up after this nightmare a few times.
React is ~40kb of well-earned patterns and a sane way to handle complexity over years of development. You still have to engineer well, but after having seen really smart people fail with seemingly smart frameworks, I appreciate the React way.
The business will want pixels. Data analytics. AB Tests. Social buttons. These will be attached to million dollar campaigns. You do not get to say no. There goes your "fully loaded" time. Every client side event is now wrapped in nasty JS beacon reporting, probably a few of them.
The home page team wants recommendations that can't be cached. It's determined to fetch this on the client to enable a faster TTFB. All those products need to fetch images, too. The time to interactive bumps up a bit.
After a while, it turns out even the CMS static content wasn't safe. The CMS team wants interactive elements. You hack a little more JS. The time to interactive bumps up a bit.
The checkout team has a more dynamic approach because of the user expectations. They use some packages they want preloaded because the metrics tell them that getting to checkout faster means more conversion. More unused JS to load on the homepage in case of clicking "add to cart." You might argue about it, the button could take you to the cart page and the server could perform the add to cart. Maybe you win and implement it. This version fails the AB test.
After a while of this, the team chafes at plain css. Just 10% of it is still used on the homepage and people are afraid to delete things because it's so hard to know what the effect is across the site. The common css continues to bloat for forever. Some day, years from now, it's such an unrecognizable mess that the decision is made to delete and start over.
The JS isn't aging well either. Just writing script tags led to poor reusability and breaking the browser cache too often. Pretty early on somebody added rollup and a major project is done to clean up script tags. Progressively enhancing the "legacy framework" html worked well in the beginning but now you're staring at a mile long bug backlog of reports like "when in this state, click this thing and then click the other thing and it's not showing expected x."
Worse, you can't hire any frontenders. Gone are the days when frontend would also know whatever "legacy" backend framework you have. They don't want to work in PHP or Java or whatever, they want to specialize in the frontend. Most of your frontend team joins, complains loudly and leaves inside a year.
I've lived this nightmare a few times. I have cleaned up after this nightmare a few times.
React is ~40kb of well-earned patterns and a sane way to handle complexity over years of development. You still have to engineer well, but after having seen really smart people fail with seemingly smart frameworks, I appreciate the React way.
This sums it up exactly. The problem is with the decision makers who are almost never the dev team. Even when it is the dev team’s fault, that is often also the fault of management who cheaped out and hired a junior team rather than paying for experienced devs to do the spearheading.
Taking >10s for a site to be usable is absolutely insane. This is not ok, I don’t know when it became acceptable.
Well written article, thanks! I think some of your critics need to look up the term "veiled criticism"
Nah it's just too much of purple prose.
Frankly the article is just as bloated with words as the thing it criticizes
Frankly the article is just as bloated with words as the thing it criticizes
> TL;DR: your JS is probably worse than you think. Write HTML and CSS instead. It will go better for everyone.
Dear author,
Could you explain to us how one would write Online Photoshop in HTML and CSS? Or Figma? Or Excalidraw? Or Youtube? Or Google Maps?
Dear author,
Could you explain to us how one would write Online Photoshop in HTML and CSS? Or Figma? Or Excalidraw? Or Youtube? Or Google Maps?
Author here.
So, if you read the post, you probably saw this:
https://infrequently.org/2023/02/the-market-for-lemons/#fn-t...
The little model there helps us distinguish types of sites, and so the very first thing to do is to note that you probably aren't building one of these.
But let's say you are!
In that case, it might help you to know that I've consulted with 4 of the 5 teams you mention, and because they have high management maturity, they often make choices that look different than the stacks you're being pitched at JS conferences.
Outside the editing canvas itself (a 20+ year old codebase ported to WASM), Adobe realised they couldn't afford the overhead of using React the "usual" way and have moved to Lit-based Web Components for PS:
https://web.dev/ps-on-the-web/
YouTube is made of Polymer Web Components, and before that (for most of it's history) was a server-rendered Python frontend with progressive enhancement.
Maps is built on the usual Google frontend tech (Closure Library, Soy, etc.), and while that means it's still lugging around a lot of legacy cruft, it performs because the team both works hard to keep it in check and that the tools started in an era that (correctly) assumed that CPU and bandwidth are not plentiful on the client.
Figma uses React outside the canvas, but their team also includes former browser engineers. They don't use it naïvely. Nor does Excalidraw, as the author knows where the (latency) bodies are buried.
In all these cases, the reason these experiences work well is management maturity, not tech. Strong teams that need to have deep local interaction respect the problem and usually make choices that go against the "HN consensus" because better user experiences matter more than in-group signaling:
https://infrequently.org/2022/05/performance-management-matu...
So, if you read the post, you probably saw this:
https://infrequently.org/2023/02/the-market-for-lemons/#fn-t...
The little model there helps us distinguish types of sites, and so the very first thing to do is to note that you probably aren't building one of these.
But let's say you are!
In that case, it might help you to know that I've consulted with 4 of the 5 teams you mention, and because they have high management maturity, they often make choices that look different than the stacks you're being pitched at JS conferences.
Outside the editing canvas itself (a 20+ year old codebase ported to WASM), Adobe realised they couldn't afford the overhead of using React the "usual" way and have moved to Lit-based Web Components for PS:
https://web.dev/ps-on-the-web/
YouTube is made of Polymer Web Components, and before that (for most of it's history) was a server-rendered Python frontend with progressive enhancement.
Maps is built on the usual Google frontend tech (Closure Library, Soy, etc.), and while that means it's still lugging around a lot of legacy cruft, it performs because the team both works hard to keep it in check and that the tools started in an era that (correctly) assumed that CPU and bandwidth are not plentiful on the client.
Figma uses React outside the canvas, but their team also includes former browser engineers. They don't use it naïvely. Nor does Excalidraw, as the author knows where the (latency) bodies are buried.
In all these cases, the reason these experiences work well is management maturity, not tech. Strong teams that need to have deep local interaction respect the problem and usually make choices that go against the "HN consensus" because better user experiences matter more than in-group signaling:
https://infrequently.org/2022/05/performance-management-matu...
Thank you for the response.
I feel that there is a bit of miscommunication here. You focus your efforts on arguing against React. I do not disagree. I would love nothing better than to throw away React and embrace Lit or native web components for the heavily interactive sites with deep sessions. However, components is just a part of the story. There is also state management, client-side caching, server-side rendering with subsequent hydration, bundling and code splitting, etc. to think of — on which we are hearing little to no guidance from mature developers such as yourself, and, in absence of such guidance, have to fall prey to the twitter thinkfluencers from the js industrial complex that you denounce, but who promise some concrete solutions.
I feel that there is a bit of miscommunication here. You focus your efforts on arguing against React. I do not disagree. I would love nothing better than to throw away React and embrace Lit or native web components for the heavily interactive sites with deep sessions. However, components is just a part of the story. There is also state management, client-side caching, server-side rendering with subsequent hydration, bundling and code splitting, etc. to think of — on which we are hearing little to no guidance from mature developers such as yourself, and, in absence of such guidance, have to fall prey to the twitter thinkfluencers from the js industrial complex that you denounce, but who promise some concrete solutions.
I completely agree react/angular/vue have a place and there are instances where they are essential, but too many programmers are reaching for them as the "only" way to build a web app.
And old, boring framework like rails or django can absolutely provide an adequate ux, especially for smaller projects.
There is still a need for straighforward crud apps modifying business data for internal users, and rewriting these apps in a js framework will introduce a lot of complexity that is simply not needed.
And old, boring framework like rails or django can absolutely provide an adequate ux, especially for smaller projects.
There is still a need for straighforward crud apps modifying business data for internal users, and rewriting these apps in a js framework will introduce a lot of complexity that is simply not needed.
Dear reply comment.
Do you realise that you are talking of a really small minority of what these tools are used for?
Also yt can be done in mostly html and css.
Do you realise that you are talking of a really small minority of what these tools are used for?
Also yt can be done in mostly html and css.
> Do you realise that you are talking of a really small minority of what these tools are used for?
I absolutely do realise that; but the author seems to ignore them altogether (which is a bit odd, given his normally commendable spirit of inclusion). Contrast this with Jason Miller's (another Googler, author of Preact) guide to different architecture decisions based on different product requirements [0]:
[0] - https://jasonformat.com/application-holotypes/
I absolutely do realise that; but the author seems to ignore them altogether (which is a bit odd, given his normally commendable spirit of inclusion). Contrast this with Jason Miller's (another Googler, author of Preact) guide to different architecture decisions based on different product requirements [0]:
[0] - https://jasonformat.com/application-holotypes/
Can be, but having actually looked at (and worked on!) the YT frontend code base, you should use Angular/React. YT FE seems simple but there is a lot of stuff happening behind the scenes.
But how much of the "stuff" is actually necessary? I think part of the point is that the FE complexity is not inherent to the problem being solved, but a side-effect of having too many engineers and PMs with not enough to do, so new problems need to be invented, thus creating the complexity that then requires something like Angular/React.
While Youtube works okayish, most major FE heavy sites suck. Facebook, Linkedin and almost everything that Google produces (Gmail, Google Cloud console, Firebase console) are some of the slowest, buggiest websites created and would be improved by using less React/Angular.
Sure, Figma and Photoshop are a different breed, but the vast majority of CRUD apps should not be SPAs.
While Youtube works okayish, most major FE heavy sites suck. Facebook, Linkedin and almost everything that Google produces (Gmail, Google Cloud console, Firebase console) are some of the slowest, buggiest websites created and would be improved by using less React/Angular.
Sure, Figma and Photoshop are a different breed, but the vast majority of CRUD apps should not be SPAs.
> But how much of the "stuff" is actually necessary?
That's up to the business (product owners) to decide, isn't it? Not up to developers. Take a look at a video page on youtube, and catalog how much interactivity is happening there — the player, which can switch between videos, which need to stay in sync with the description and the comments section; and both need to stay in sync with the suggested videos list on the right. The user can react to a video; or share it; or write a comment; or respond to another commenter. Both the suggested videos list on the right and the comments section need to load new items as the user scrolls down... Plus, if the video happens to be streamed, there is an interactive chat section on the right; and presumably some way to reward the streamer with donations.
All that even before one turns their attention to the youtube studio screen, where the user can upload and edit their videos.
Product requirements is not something that developers have control over. All they can do is adapt their code, say "yes sir", or "I don't know how to do this".
That's up to the business (product owners) to decide, isn't it? Not up to developers. Take a look at a video page on youtube, and catalog how much interactivity is happening there — the player, which can switch between videos, which need to stay in sync with the description and the comments section; and both need to stay in sync with the suggested videos list on the right. The user can react to a video; or share it; or write a comment; or respond to another commenter. Both the suggested videos list on the right and the comments section need to load new items as the user scrolls down... Plus, if the video happens to be streamed, there is an interactive chat section on the right; and presumably some way to reward the streamer with donations.
All that even before one turns their attention to the youtube studio screen, where the user can upload and edit their videos.
Product requirements is not something that developers have control over. All they can do is adapt their code, say "yes sir", or "I don't know how to do this".
If it was written any other way they would be soon labelled as "negative" or even a "hater".
Every non-SPA that I’ve worked on ended up accreting interactivity to the point that I’d wished we had started with a single, unified, well-structured way for managing the UI that handled interactivity well.
I used to do a lot of native Windows apps in C, VB6, and C#. To me, Preact + TypeScript is as good in many ways, better in some, and worse in others— but it averages out to be just fine from a developer perspective.
I personally don’t miss the old native UI days.
The majority of jank that I see on the web is not due to React or Angular or whatnot. It’s due to ads, trackers, and to product owner’s inability to say “no” to piling a million things into important screens.
It is a misplacement of blame to blame React.
I used to do a lot of native Windows apps in C, VB6, and C#. To me, Preact + TypeScript is as good in many ways, better in some, and worse in others— but it averages out to be just fine from a developer perspective.
I personally don’t miss the old native UI days.
The majority of jank that I see on the web is not due to React or Angular or whatnot. It’s due to ads, trackers, and to product owner’s inability to say “no” to piling a million things into important screens.
It is a misplacement of blame to blame React.
Few jobs ago I was a PM director at a scaleup and at some point our frontend platforms engineering (or something like that) came into my purview.
This team didn't build front end experiences but tried to build out tooling in which other devs would. Which was weird to me given that we didn't do anything extraordinary in terms of experience so off the shelf stuff should have worked.
I think this was some evidence towards the point in this article. Two things were at play:
First, the gross complexity of the available frameworks made it seem like something like this was necessary.
Second, the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.
If I had owned this space from the start, I'd have asked the question of "what business outcomes does this enable which we can't achieve at least for a while, with static-ish html, forms, etc" and maybe allow a little complexity where justified. But since it was purely engineering owned for a few years before it got to me, it was way too late to reign the complexity and we ended up doing shit like porting from one framework to another.
This team didn't build front end experiences but tried to build out tooling in which other devs would. Which was weird to me given that we didn't do anything extraordinary in terms of experience so off the shelf stuff should have worked.
I think this was some evidence towards the point in this article. Two things were at play:
First, the gross complexity of the available frameworks made it seem like something like this was necessary.
Second, the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.
If I had owned this space from the start, I'd have asked the question of "what business outcomes does this enable which we can't achieve at least for a while, with static-ish html, forms, etc" and maybe allow a little complexity where justified. But since it was purely engineering owned for a few years before it got to me, it was way too late to reign the complexity and we ended up doing shit like porting from one framework to another.
One of the mantras I like to chant is that your job as a developer is not to write code. Your job is to implement solutions to business problems.
I didn’t understand that until I became a manager. Your whole perspective shifts because you realize that salaries don’t just grow on trees.
I didn’t understand that until I became a manager. Your whole perspective shifts because you realize that salaries don’t just grow on trees.
One thing to consider: a lot of devs are most familiar with React and some set of tools in it's ecosystem.
Sticking with what you know is generally good advice. Especially if you consider hiring and onboarding.
Sticking with what you know is generally good advice. Especially if you consider hiring and onboarding.
> the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low.
I strongly disagree. The fact of the matter is frontend tech debt is just SO MUCH cheaper than backend tech debt.
If all you need to do to is refactor or port over a SPA and leave the existing API alone, you've sidestepped so much pain it's unreal.
If you started out with "simple" form requests instead of an API, the backend is pretty much guaranteed to be an undisciplined mess. Wrong place to cut corners.
I strongly disagree. The fact of the matter is frontend tech debt is just SO MUCH cheaper than backend tech debt.
If all you need to do to is refactor or port over a SPA and leave the existing API alone, you've sidestepped so much pain it's unreal.
If you started out with "simple" form requests instead of an API, the backend is pretty much guaranteed to be an undisciplined mess. Wrong place to cut corners.
> The fact of the matter is frontend tech debt is just SO MUCH cheaper than backend tech debt.
Seeing someone mention this as an opinion, let alone asserting it as fact, is a first for me!
I had the opposite impression, but I'm not sure how I'd debate it as fact without some observational analysis of dependencies and frequency of breaking changes in various frontend and backend projects.
Seeing someone mention this as an opinion, let alone asserting it as fact, is a first for me!
I had the opposite impression, but I'm not sure how I'd debate it as fact without some observational analysis of dependencies and frequency of breaking changes in various frontend and backend projects.
Would you prefer to be on call at 2am to immediately fix something that blew up on the backend that caused an outage, or be given a couple of days to just patch a weird bug that only affects a few users on the frontend?
If you said frontend bugs are cheap I'd agree with you.
But when you say tech debt o don't think about bugs I think about updating dependencies and dealing with their breaking changes. That feels worse to me in frontend code than in backend code. Not for some intrinsic reason but I guess just culturally.
But when you say tech debt o don't think about bugs I think about updating dependencies and dealing with their breaking changes. That feels worse to me in frontend code than in backend code. Not for some intrinsic reason but I guess just culturally.
I don't even know if I disagree with you on these details.
The point is we bit off too much complexity on the front-end when we shouldn't have had to given the vanilla nature of what we did in terms of user experience, but somehow nobody on the eng side questioned it. For me as a dev turned PM it was screamingly obvious.
The point is we bit off too much complexity on the front-end when we shouldn't have had to given the vanilla nature of what we did in terms of user experience, but somehow nobody on the eng side questioned it. For me as a dev turned PM it was screamingly obvious.
Front end debt is only cheaper in the sense that it’s running on someone elses hardware so when it fails you don’t see it fail or the impact of it’s failure
My god, this article reads like a non fiction incarnation of "infinite jest" its basically impossible to understand the authors concrete intent and meaning of whole paragraphs without reading the footnotes and the linked articles while reading the post. And if i understand it correctly, it completely misses the point who is to blame. Angular and react solutions were seldom sold from an actor with deep information to a manager or business with less information. In my experience the top 2 situations were a) managers/half-technical founders wanted what they had read about and google or facebook were backing and did not want to hear about a proper evaluation, b) devs and whole dev teams wanted to just use what they knew and read about 100% thinking this was the best solution because of their inexperience and lack of reflection. The first is just your usual ignorance towards the experts by buzz word driven and half-knowledge managers, the latter could be more likened to the brainwashing of cult members than intransparent market situations.
> And if i understand it correctly
You did not. Per the article, the "buyers" of SPAs are the developers and teams who heard about a technology and thought it would be the right tool.
You did not. Per the article, the "buyers" of SPAs are the developers and teams who heard about a technology and thought it would be the right tool.
I can't look at an app and tell you that it's written in framework A or B, but so many websites are becoming dogs these days, and not just because they have to run Javascript. I think the scripts actually spend a lot of time blocking on the I/O that would have originally been delivered with the initial page. Server side rendering may be a solution but it seems lots of sites have a rather modular approach to putting components on a page that then load lazily over ridiculous amounts of time.
As an example, the American Express account management website. Lots of banking websites are going this way, where it's taking long enough to finish a request that you worry the logout timer will fire before it's done. They have also lost niceties like the ability to take you back to the same page with the items in the same order, that I had on the Dollar Bank website circa 1998. (Seriously, that bank was ahead of the curve and the website was fast, on 33kbps dial-up and a Pentium MMX 200.)
Other websites are the same. Kaiser. State taxes. Delta airlines. Formerly fast things replaced by janky lazy loads that reflow the page and cause you to click the wrong thing. And so much telemetry! Can you actually process all that data? Because if it's working it must be screaming that people are constantly clicking the wrong thing.
As an example, the American Express account management website. Lots of banking websites are going this way, where it's taking long enough to finish a request that you worry the logout timer will fire before it's done. They have also lost niceties like the ability to take you back to the same page with the items in the same order, that I had on the Dollar Bank website circa 1998. (Seriously, that bank was ahead of the curve and the website was fast, on 33kbps dial-up and a Pentium MMX 200.)
Other websites are the same. Kaiser. State taxes. Delta airlines. Formerly fast things replaced by janky lazy loads that reflow the page and cause you to click the wrong thing. And so much telemetry! Can you actually process all that data? Because if it's working it must be screaming that people are constantly clicking the wrong thing.
I remember when Reddit (old.reddit.com, the good one) loaded ultra fast and didn’t move around. I could use the back button without noticeable waiting.
And it didn’t freeze up network requests on other tabs on my phone. I STILL don’t know how it does that. I would love a fix. At least at some point I discovered opening a new tab with HN “unblocked” it somehow.
SPAs have their place. It’s not everywhere. Just like microservices. And ORMs. And all the other “magic” that will solve all my problems.
And it didn’t freeze up network requests on other tabs on my phone. I STILL don’t know how it does that. I would love a fix. At least at some point I discovered opening a new tab with HN “unblocked” it somehow.
SPAs have their place. It’s not everywhere. Just like microservices. And ORMs. And all the other “magic” that will solve all my problems.
You might try https://sh.reddit.com
Thanks, I knew about www.reddit, old.reddit, i.reddit, m.reddit, but I didn't know about this one. I can't find any info on it, what is the goal of sh.reddit UI exactly?
On another note, all kinds of interesting subdomains[0]. I wonder why a few subs get a subdomain?
[0] https://domain.glass/reddit.com
On another note, all kinds of interesting subdomains[0]. I wonder why a few subs get a subdomain?
[0] https://domain.glass/reddit.com
It's the new mobile UI, built on Web Components (via Lit), and it's much faster. Parts of it have apparently already migrated to the old experience.
[deleted]
[deleted]
Not to mention dozens of authorization redirects. Absolutely infuriating.
At this point articles like this exhaust me beyond the point of caring. The popular tools are all reasonably good and in my experience the people complaining about the JavaScript ecosystem do so at the expense of getting stuff done.
Absolutely. Always eye-roll inducing, particularly the ones with bitter, angry, or in this case accusatory tones. JS solves problems people have, and it's not goin away anytime soon. I would love to be something other than a frontend code monkey, but I don't see that happening anytime soon. I just wish people here could shut the fuck up about it.
I’m guessing you’ve got a nice $1k+ dev box and high-speed internet?
Yep, and my users do too. Most of these blog posts can be distilled down to "pick the right tools for the job".
The landscape for non SPAs don’t look great either - Amazon and other e-commerce sites come to mind. It’d be nice to show some examples of who’s doing things well while also being complex, and having a nice UI.
[deleted]
The author spends the bulk of the post (as far as I could tell from the opaque writing style) criticizing React and the React ecosystem.
But when you see the first footnote for their recommended alternatives, many are very similar to React in practice. Notably:
Preact (basically just another implementation of React)
Vue (very similar ecosystem to React in terms of the mentioned SPA SSR etc)
SolidJS
Svelte
Etc.
Then some of the recommended alternatives to the SPA are just as complex or more complex than the things the author had just criticized, including Astro (SSR with islands), Fresh (denos edge based "just in time" SSR), Sveltekit (the same SPA SSR SSG etc complained about for React above).
Not sure how these don't fall under the same opaque criticisms of the JS "lemon market".
But when you see the first footnote for their recommended alternatives, many are very similar to React in practice. Notably:
Preact (basically just another implementation of React)
Vue (very similar ecosystem to React in terms of the mentioned SPA SSR etc)
SolidJS
Svelte
Etc.
Then some of the recommended alternatives to the SPA are just as complex or more complex than the things the author had just criticized, including Astro (SSR with islands), Fresh (denos edge based "just in time" SSR), Sveltekit (the same SPA SSR SSG etc complained about for React above).
Not sure how these don't fall under the same opaque criticisms of the JS "lemon market".
> You wouldn't know it from today's frontend discourse, but the modern era has never been without high-quality alternatives to React, Angular, Ember, and other legacy desktop-era frameworks.
"You wouldn't know it from today's frontend discourse"??? Seriously? Everybody and their dog know about those frameworks.
It feels like the first footnote was added in response to criticism from the reviewers of the drafts. It contradicts the body of the article and makes the whole thing incomprehensible.
The original article must have been a criticism of frontend frameworks in general. It points to the "sandy foundations" and frames all attempts at solutions as simply adding complexity - probably including all those new frameworks everybody talks about.
"You wouldn't know it from today's frontend discourse"??? Seriously? Everybody and their dog know about those frameworks.
It feels like the first footnote was added in response to criticism from the reviewers of the drafts. It contradicts the body of the article and makes the whole thing incomprehensible.
The original article must have been a criticism of frontend frameworks in general. It points to the "sandy foundations" and frames all attempts at solutions as simply adding complexity - probably including all those new frameworks everybody talks about.
I mean yeah we know about them, but do we use them? Are we hiring for them?
Speaking as a front end dev who's been looking for a new role for the past 4 months... basically everyone wants 2-4 years of React experience. Every once in a while you see Angular, usually an older version, or Vue - very occasionally you'll see a "React or other modern framework" requirement.
React is the industry standard right now from where I'm standing. Yes we all know there are other things we could be using, but who's using them? (And are they hiring?)
Speaking as a front end dev who's been looking for a new role for the past 4 months... basically everyone wants 2-4 years of React experience. Every once in a while you see Angular, usually an older version, or Vue - very occasionally you'll see a "React or other modern framework" requirement.
React is the industry standard right now from where I'm standing. Yes we all know there are other things we could be using, but who's using them? (And are they hiring?)
I think author's point is that React is the absolute worst of the evils and it's proprietors shout its false virtues so loudly that it drowns out all discourse and rational thought.
It performs the worst (by a large margin) of the major JS frameworks https://krausest.github.io/js-framework-benchmark/2023/table...
And is highly inefficient in both compute and space: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...
Comparatively, Vue for example, can be used progressively. It is one of the core reasons the Wikimedia Foundation and GitLab chose it: https://phabricator.wikimedia.org/T241180 . Solid and Preact both perform close to Vanilla and bundle far smaller, improving the end user experience. One of Vue's main technical goals this year is Vapor mode (inspired by Solid) which should yield lighter, faster, and more modular client packages.
My take is that React now is the worst of the major libraries yet the most heavily used. It's core design is fundamentally flawed so additional layers of complexity are needed to mitigate it. It doesn't make any sense except for the complexity peddlers who's fortunes depend on more suckers.
If you watched the Next.js conf last year, you know what I mean. You can tell they invested a lot of money into production value. I watched a Microsoft developer conference shortly after and the difference was night and day. Ask yourself why Vercel needs to invest that much into a developer conference where ostensibly we developers want good tech, not flashy presentations. Who are they actually selling to?
Working at a startup building on Next.js and React, I commiserate with the author's take on complexity peddlers. We have dozens of lines of code for what should take just a handful to do in vanilla. In look at this code everyday wondering why we have piles of JavaScript for very simple interactions.
Most recently, a dev made some well intentioned changes that somehow changed Next to only output CSR (no server output HTML); thereby fully defeating the purpose. Now we have a server render cycle calling out to an API that returns JS to render on the client. Probably should just render on the client and skip the middle man!
The senior eng team absolutely regrets going Next.js (decision made before I joined).
We've been fleeced.
It performs the worst (by a large margin) of the major JS frameworks https://krausest.github.io/js-framework-benchmark/2023/table...
And is highly inefficient in both compute and space: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas...
Comparatively, Vue for example, can be used progressively. It is one of the core reasons the Wikimedia Foundation and GitLab chose it: https://phabricator.wikimedia.org/T241180 . Solid and Preact both perform close to Vanilla and bundle far smaller, improving the end user experience. One of Vue's main technical goals this year is Vapor mode (inspired by Solid) which should yield lighter, faster, and more modular client packages.
My take is that React now is the worst of the major libraries yet the most heavily used. It's core design is fundamentally flawed so additional layers of complexity are needed to mitigate it. It doesn't make any sense except for the complexity peddlers who's fortunes depend on more suckers.
If you watched the Next.js conf last year, you know what I mean. You can tell they invested a lot of money into production value. I watched a Microsoft developer conference shortly after and the difference was night and day. Ask yourself why Vercel needs to invest that much into a developer conference where ostensibly we developers want good tech, not flashy presentations. Who are they actually selling to?
Working at a startup building on Next.js and React, I commiserate with the author's take on complexity peddlers. We have dozens of lines of code for what should take just a handful to do in vanilla. In look at this code everyday wondering why we have piles of JavaScript for very simple interactions.
Most recently, a dev made some well intentioned changes that somehow changed Next to only output CSR (no server output HTML); thereby fully defeating the purpose. Now we have a server render cycle calling out to an API that returns JS to render on the client. Probably should just render on the client and skip the middle man!
The senior eng team absolutely regrets going Next.js (decision made before I joined).
We've been fleeced.
> The senior eng team absolutely regrets going Next.js (decision made before I joined).
I am also late to a Next.js engineering party. It was chosen because hype but the developers had no experience in it so they were really just writing it like an SPA (actually no getStaticProps, no getServerSideProps, all client side fetching). The thing was/is a bit of a mess. I think the main problem for them was not taking the time to fully grok the server/client split and take advantage of it before diving in to implement features.
I used to dislike Next.js but it's grown on me considerably. Definitely has some problems. That said, I'm having a hard time imagining what this could possibly be:
> We have dozens of lines of code for what should take just a handful to do in vanilla.
I am also late to a Next.js engineering party. It was chosen because hype but the developers had no experience in it so they were really just writing it like an SPA (actually no getStaticProps, no getServerSideProps, all client side fetching). The thing was/is a bit of a mess. I think the main problem for them was not taking the time to fully grok the server/client split and take advantage of it before diving in to implement features.
I used to dislike Next.js but it's grown on me considerably. Definitely has some problems. That said, I'm having a hard time imagining what this could possibly be:
> We have dozens of lines of code for what should take just a handful to do in vanilla.
> I used to dislike Next.js but it's grown on me considerably.
Give Astro.js a spin. Notably, take a critical eye to the HTML and JS output of Astro.js vs Next.js.
> I'm having a hard time imagining what this could possibly be
Think of something as simple as whether a div element is highlighted or not by simply adding/removing a CSS class name. In our case, it's a price tile like you'd see on Target.com. For this piece of functionality, there is a huge mountain of JS (also comprising the state) since we need to manipulate the object model to get the correct behavior when we conditionally render a class name. In vanilla, one might just do something like this and have a general purpose selection behavior:
Another version with super simple option-detail selection: https://jsfiddle.net/84b5rhpk/3/
Even cleaner V3: https://jsfiddle.net/7szur3ex/
This code is incredibly fast; requires no compilation, it's highly reusable since it cross cuts the DOM structure using `querySelectorAll` (I can reuse this function to select anything), easy to understand, has no dependency on the underlying data model, and it is stupid easy to debug. A developer doesn't need to learn the quirks of a framework or library to do this.
You might make the case that "well, a lot more things are also happening when the user makes a selection", but I'd offer that almost all of the side effects would be easier with vanilla in our case.
Give Astro.js a spin. Notably, take a critical eye to the HTML and JS output of Astro.js vs Next.js.
> I'm having a hard time imagining what this could possibly be
Think of something as simple as whether a div element is highlighted or not by simply adding/removing a CSS class name. In our case, it's a price tile like you'd see on Target.com. For this piece of functionality, there is a huge mountain of JS (also comprising the state) since we need to manipulate the object model to get the correct behavior when we conditionally render a class name. In vanilla, one might just do something like this and have a general purpose selection behavior:
const $ = (selector) => document.querySelectorAll(selector)
function select(evt) {
$("li").forEach(li => li.className = "")
evt.target.className = "selected"
}
$("li").forEach(li => li.addEventListener("click", select))
Another version with super simple option-detail selection: https://jsfiddle.net/84b5rhpk/3/
Even cleaner V3: https://jsfiddle.net/7szur3ex/
This code is incredibly fast; requires no compilation, it's highly reusable since it cross cuts the DOM structure using `querySelectorAll` (I can reuse this function to select anything), easy to understand, has no dependency on the underlying data model, and it is stupid easy to debug. A developer doesn't need to learn the quirks of a framework or library to do this.
You might make the case that "well, a lot more things are also happening when the user makes a selection", but I'd offer that almost all of the side effects would be easier with vanilla in our case.
Ah yeah, React doesn't make this any easier. You'll probably end up with a useState combined with className={clsx(selected[idx] && "selected")} or something. I don't think that's more complicated or even more LoC but it's definitely doing more work than vanilla so the performance difference is inarguable. You'd have to box off the state to its own component to avoid re-rendering the entire list.
> I don't think that's more complicated or even more LoC but it's definitely doing more work than vanilla so the performance difference is inarguable
It's not just the LoC,
https://jsfiddle.net/7szur3ex/
This is like 95% of the interactivity needed on an e-commerce PDP in 15 lines of JavaScript.
It's not just the LoC,
- I don't need a build chain for this; there's no transpilation.
- I don't need an external library to download to the client to do this.
- I can get the HTML from anywhere. Rails, PHP, Node.js, ASP.NET, static bucket in S3. Anywhere; I have more flexibility on my backend to pick something that's fast.
- It's incredibly fast in the browser and SEO friendly *without any extra work* because all of the HTML is already sitting there.
- I didn't need any rehydration or complex data flow/data passing logic from server to client.
- It's easily debuggable even in production
https://jsfiddle.net/7szur3ex/
This is like 95% of the interactivity needed on an e-commerce PDP in 15 lines of JavaScript.
You might be moving the goalposts slightly. The original comment said there were things you can do in a handful of lines in vanilla that it takes dozens of lines of React because you were concerned about complexity. Setting up the project should not be part of that complaint [if you guys have to set up the project every time you try to add a class to a selected item, I can understand why that would be cumbersome ;) ]. Vanilla JS tool chains being comparitively less complex and emitting smaller builds is not the line of discussion I thought I was engaging.
You don't have to set it up every time, but many features require that you tweak the setup and/or migrate your setup/configuration. I can't imagine having to tweak <script src="..." />
Rather than moving the goal posts, I'd proffer that you are missing the forest for the trees.
Case in point: Next 12 to Next 13. The architecture of layout pages, client vs server only components, new build chain (surely will have its own kinks and bugs to iron out). Then there will be a Next 14, TurboPack 2, React 19, etc. Migrating some remaining systems from Node 12/14 to Node 16/18 and updating our CI configurations, local dev environments, and praying that all the packages update without issue. Breaking changes in upstream NPM packages. React's shift from class components to functional components and hooks. Working on integrating InstantSearch into a Next.js app this week and the `useClearRefinements` hook can't be included on the server side (despite the fact that our SSR is broken right now). So I needed to use `next/dynamic` and exclude it from SSR to get it to build which seemed extra ridiculous because...
As I mentioned, this week, I noticed that our SSR pages were suddenly no longer generating any HTML on the server essentially turning our Next app into a full CSR app with server side API calls. I checked in with CTO and FE dev to see if this is intentional or accidental. Something errant with the toolchain, configuration, or change in how we are loading assets is now causing Next to misbehave (haven't figured this one out yet).
I will never, ever have to deal with this with those 15 lines of JS. Those 15 lines of JS will never need to be migrated into a different runtime, build process, tool chain, or stack. 10 years later, those 15 lines of JS are still going to work. Whatever migrations you need to do to modernize your toolchain and stack over the next two years is work and effort that you're not spending on creating value.
So the tool chain creates its own complexity that is secondary to the core development complexity. That's Alex Russell's point in the article: the complexity merchants have created an environment where there's so much unnecessary complexity and -- wouldn't you guess it? -- they have just the thing you need to solve it! They have you on a treadmill while they're feeding you doughnuts and chocolate.
Rather than moving the goal posts, I'd proffer that you are missing the forest for the trees.
Case in point: Next 12 to Next 13. The architecture of layout pages, client vs server only components, new build chain (surely will have its own kinks and bugs to iron out). Then there will be a Next 14, TurboPack 2, React 19, etc. Migrating some remaining systems from Node 12/14 to Node 16/18 and updating our CI configurations, local dev environments, and praying that all the packages update without issue. Breaking changes in upstream NPM packages. React's shift from class components to functional components and hooks. Working on integrating InstantSearch into a Next.js app this week and the `useClearRefinements` hook can't be included on the server side (despite the fact that our SSR is broken right now). So I needed to use `next/dynamic` and exclude it from SSR to get it to build which seemed extra ridiculous because...
As I mentioned, this week, I noticed that our SSR pages were suddenly no longer generating any HTML on the server essentially turning our Next app into a full CSR app with server side API calls. I checked in with CTO and FE dev to see if this is intentional or accidental. Something errant with the toolchain, configuration, or change in how we are loading assets is now causing Next to misbehave (haven't figured this one out yet).
I will never, ever have to deal with this with those 15 lines of JS. Those 15 lines of JS will never need to be migrated into a different runtime, build process, tool chain, or stack. 10 years later, those 15 lines of JS are still going to work. Whatever migrations you need to do to modernize your toolchain and stack over the next two years is work and effort that you're not spending on creating value.
So the tool chain creates its own complexity that is secondary to the core development complexity. That's Alex Russell's point in the article: the complexity merchants have created an environment where there's so much unnecessary complexity and -- wouldn't you guess it? -- they have just the thing you need to solve it! They have you on a treadmill while they're feeding you doughnuts and chocolate.
Okay, I'm just saying this isn't the conversation I signed up for. I've heard people scream about react and tool chains and how much they hate js pretty much nonstop since I've been a user of this site. I am not interested. If I thought it would go this way, I wouldn't have engaged you.
Haha, I hope you don't feel attacked; apologies if it comes across that way. I am right with you on that treadmill and really appreciate the discussion and counter-perspective to help me think through my own. If anything, this interaction has helped me clear some fog around our stack so I appreciate that you were willing to engage in a discussion.
Cheers!
Cheers!
The article is a bit too bitter for my taste, but I agree with most of it. Except for the developer experience improvement these frameworks supposedly offer, I don’t even buy that.
For over a decade it seems to me the industry has been enamored with crazy complex solutions to problems that mostly don’t exist. I keep reading their proposals in dismay and basically chugging along with almost the same stack as before. Clients are as happy as ever.
I tried to show (here and elsewhere) that, for instance, PHP/MySQL + HTML/CSS/VanillaJS is faster, easier to read and write than React/Angular/FrameworkDuJour, but we seem to live in different worlds. I still think jQuery was the biggest improvement in frontend development quality of life and hasn’t been matched since.
I’ve mostly resigned to believe that React and friends are maybe great for hiring, being hired, manage teams. Actual coding is another discussion altogether.
For over a decade it seems to me the industry has been enamored with crazy complex solutions to problems that mostly don’t exist. I keep reading their proposals in dismay and basically chugging along with almost the same stack as before. Clients are as happy as ever.
I tried to show (here and elsewhere) that, for instance, PHP/MySQL + HTML/CSS/VanillaJS is faster, easier to read and write than React/Angular/FrameworkDuJour, but we seem to live in different worlds. I still think jQuery was the biggest improvement in frontend development quality of life and hasn’t been matched since.
I’ve mostly resigned to believe that React and friends are maybe great for hiring, being hired, manage teams. Actual coding is another discussion altogether.
I think there’s a bit too much “blaming the tool” going on here. Be reasonable about what you introduce into a software project. If it’s a bunch of CRUD you probably can wait to add a front-end framework. If you find yourself needing it for that one big feature where you have to implement drag-and-drop and a bunch of DOM manipulation, don’t rewrite your whole app, just tailor that one experience.
If you don’t NEED a high level of server communication or data continuation between components, you probably also don’t need any crazy state management. And again, when you build that one wizard experience that really needs something more, tailor the solution local to that one experience.
Not to say that larger and more complex projects don’t exist, but for most things you can get away with a lot less, and there’s balance between performance, developer joy and increasing productive capacity.
If you don’t NEED a high level of server communication or data continuation between components, you probably also don’t need any crazy state management. And again, when you build that one wizard experience that really needs something more, tailor the solution local to that one experience.
Not to say that larger and more complex projects don’t exist, but for most things you can get away with a lot less, and there’s balance between performance, developer joy and increasing productive capacity.
> Be reasonable about what you introduce into a software project. ... don’t rewrite your whole app, just tailor that one experience.
You just described exactly why most web devs strongly prefer to build SPAs today instead of using SSR (separation of concerns).
You just described exactly why most web devs strongly prefer to build SPAs today instead of using SSR (separation of concerns).
Well, I think the main difficulty with SSR is you'd think it would be more of an incremental step. I don't think it's so much a "separation of concerns" issue (i.e. just having some of your presentation logic running on-server doesn't mean it's necessarily not isolated logic) as it is a "wow I have to rewrite significant parts of my application to take advantage of this" issue. Some frameworks definitely do a better job with this than others IMO, but not everybody wants to (or should) migrate their React app to NextJS (for example) just to get SSR.
TFA is a rant that seems mostly targeted at React, judging from the links/examples. The article is not very clear or easy to follow but it still has a point. All modern frameworks are ridiculously complex, esp. given the fact that modern JavaScript is extremely versatile, with classes, modules, web components, etc.
A new empty Angular project via the Angular CLI copies almost 40,000 files of node modules (350 Mo), which is apparently considered "very little space" by today's standard (actual quote from a SO answer).
It's all quite demoralizing. I actually like SPAs! and I agree that state must be managed on the client somehow; but this is insane. Plain old JS with some Redux, querying a well thought out and simple API on the server will get you a long long way.
A new empty Angular project via the Angular CLI copies almost 40,000 files of node modules (350 Mo), which is apparently considered "very little space" by today's standard (actual quote from a SO answer).
It's all quite demoralizing. I actually like SPAs! and I agree that state must be managed on the client somehow; but this is insane. Plain old JS with some Redux, querying a well thought out and simple API on the server will get you a long long way.
As someone whose worked with React/Angular/Svelte/etc for the past 5-6 years, the biggest benefit and the biggest hurdle to these frameworks is the complexity. The complexity in these frameworks has resulted in us being able to build massive complex applications, but if not done with the proper level of care, that application will be a performance crap sandwich.
And that I would say is the biggest problem with these stacks, they are incredibly powerful and can get you places but you have to know how to use them! If you are an experienced web developer you should be able to pick up these frameworks and run with them. But the problem arises when you have a team made up of a number of Sr developers along with Mid/Jr devs. The Sr devs might know all these footguns and hurdles, but the Jr's/Mid's might not. With a small team this gap in knowledge can be effectively managed but the issue really becomes apparent when you have multiple teams, all with the same makeup.
But say you are building an app with a very experienced team and don't run into the knowledge issues above, well you can still have issues depending on your vendors. In this case I'm talking about say a chatbot or some other integration into your app where the vendors team wrote said code. In this case you have the same issue where you can have the most experienced devs on your team, but if the vendor wrote some crap code, you're going to have issues in your app.
All of this is to say, applications have just become massive recently, and managing that complexity and making sure your application stays performant gets harder and harder.
And that I would say is the biggest problem with these stacks, they are incredibly powerful and can get you places but you have to know how to use them! If you are an experienced web developer you should be able to pick up these frameworks and run with them. But the problem arises when you have a team made up of a number of Sr developers along with Mid/Jr devs. The Sr devs might know all these footguns and hurdles, but the Jr's/Mid's might not. With a small team this gap in knowledge can be effectively managed but the issue really becomes apparent when you have multiple teams, all with the same makeup.
But say you are building an app with a very experienced team and don't run into the knowledge issues above, well you can still have issues depending on your vendors. In this case I'm talking about say a chatbot or some other integration into your app where the vendors team wrote said code. In this case you have the same issue where you can have the most experienced devs on your team, but if the vendor wrote some crap code, you're going to have issues in your app.
All of this is to say, applications have just become massive recently, and managing that complexity and making sure your application stays performant gets harder and harder.
And there are a number of vulnerabilities with those packages, which are not being fixed. I think NPM should remove any package that are not maintained or have severe (any?) vulnerabilities. IMO, we have too many packages,some restriction to publish will be good.
People that complain about SPAs are the modern knights tilting at windmills. What are the primary ways people today consume content? Youtube, tiktok, whatsapp, facebook messenger, instagram, discord, etc, etc.
Before someone qualifies my post with "ackshually I do this thing", yes I read blogs too.
That being said, NOBODY READS BLOGS. People don't want static html and css. They want real time updates, they want notifications, they want gamification. They want to play the slot machine.
So while you want to shit on javascript (it's fun to bundle in the shit language javascript when going on these tirades because everyone fucking hates javascript). The problem is not javascript. The problem is, we want real fucking apps, with interactivity, and we want them instantly, over an internet connection.
I want to play chess in my browser over an internet connection. And when chess 2.0. comes out I better have that shit in my browser in under 100ms.
Oh, and sure JS is shit. But if we were using Rust for our UIs we'd have the same problem. The most prominent Rust web UI frameworks are literal React and SolidJs clones.
And JS will be replaced, but we don't have a good enough garbage collected language for it yet.
edit: Can you even think of a modern business that could be just served by just html and css. Like what? A restaurant? Is that what we really think the average software engineer is working on? Restaurant websites?
Before someone qualifies my post with "ackshually I do this thing", yes I read blogs too.
That being said, NOBODY READS BLOGS. People don't want static html and css. They want real time updates, they want notifications, they want gamification. They want to play the slot machine.
So while you want to shit on javascript (it's fun to bundle in the shit language javascript when going on these tirades because everyone fucking hates javascript). The problem is not javascript. The problem is, we want real fucking apps, with interactivity, and we want them instantly, over an internet connection.
I want to play chess in my browser over an internet connection. And when chess 2.0. comes out I better have that shit in my browser in under 100ms.
Oh, and sure JS is shit. But if we were using Rust for our UIs we'd have the same problem. The most prominent Rust web UI frameworks are literal React and SolidJs clones.
And JS will be replaced, but we don't have a good enough garbage collected language for it yet.
edit: Can you even think of a modern business that could be just served by just html and css. Like what? A restaurant? Is that what we really think the average software engineer is working on? Restaurant websites?
Nobody is trying to convince you to build a chess app that doesn't use JavaScript.
More importantly, Alex is not arguing for you not to build things with JavaScript either!
He's arguing against writing inefficient JavaScript where you ship MBs of code to the browser to serve simple functionality.
Scroll to the footnotes and you'll find a big list of JavaScript frameworks which Alex does recommend, because they optimize for performance and low overhead.
More importantly, Alex is not arguing for you not to build things with JavaScript either!
He's arguing against writing inefficient JavaScript where you ship MBs of code to the browser to serve simple functionality.
Scroll to the footnotes and you'll find a big list of JavaScript frameworks which Alex does recommend, because they optimize for performance and low overhead.
What do Solid, Svelte and Vue bring to the table exactly? None of those frameworks solve the dataflow problem and the performance benefits they bring do not make a dent. Also why would I want to use some DSL for html templating when I could use an actual programming language?
I personally like the article and I respect author deeply, as he's one of the people who did a lot for the web. Many developers have been raised on his articles and materials.
However I agree these alternative frameworks section took me out of the piece, because these do not really solve most of the issues. They _just_ maybe get around by not having a virtual dom. But many of them still do a lot of css-in-js, still need rendering on the server (but lack the tooling), and do not solve the dataflow. I definitely have aversion towards new syntaxes of html as well (in parts because i built similar framework myself 10 years ago and it's really gnarly down the line)
However I agree these alternative frameworks section took me out of the piece, because these do not really solve most of the issues. They _just_ maybe get around by not having a virtual dom. But many of them still do a lot of css-in-js, still need rendering on the server (but lack the tooling), and do not solve the dataflow. I definitely have aversion towards new syntaxes of html as well (in parts because i built similar framework myself 10 years ago and it's really gnarly down the line)
Hey; OP here. Thanks for taking the time to read.
Something I've tried to highlight in other posts, and perhaps skimped on in the verbiage around the lists, was that results for users are the result of culture, not technology. I've worked with teams that absolutely killed it using slow-as-molasses tools (React, Angular...even Ember), and I've seen teams screw things up with "fast" tools.
But the outliers are just that. In the main, what I observe as most determinative of good outcomes is the marriage of stack complexity with management (which can be at the TL level, not necessarily PMs or EMs) that has the capacity to wrestle with the dimensions of complexity a stack presents.
This writeup (linked from the original article) might be helpful in outlining the way culture is co-variate with good outcomes and _tends_ to select for more appropriate tooling:
https://infrequently.org/2022/05/performance-management-matu...
Something I've tried to highlight in other posts, and perhaps skimped on in the verbiage around the lists, was that results for users are the result of culture, not technology. I've worked with teams that absolutely killed it using slow-as-molasses tools (React, Angular...even Ember), and I've seen teams screw things up with "fast" tools.
But the outliers are just that. In the main, what I observe as most determinative of good outcomes is the marriage of stack complexity with management (which can be at the TL level, not necessarily PMs or EMs) that has the capacity to wrestle with the dimensions of complexity a stack presents.
This writeup (linked from the original article) might be helpful in outlining the way culture is co-variate with good outcomes and _tends_ to select for more appropriate tooling:
https://infrequently.org/2022/05/performance-management-matu...
> Also why would I want to use some DSL/html templating when I could use an actual programming language?
I feel like the core issue is that HTML is radically insufficient, so DSL/Templates come into play to alleviate the burden. What's generally worse is having everyone going their own way doing random stuff within an org, so best practices must emerge and that starts to feel like a DSL in a way.
I feel like the core issue is that HTML is radically insufficient, so DSL/Templates come into play to alleviate the burden. What's generally worse is having everyone going their own way doing random stuff within an org, so best practices must emerge and that starts to feel like a DSL in a way.
Perhaps I interpreted the article differently, but I don't think it's about Javascript - it's about complex Javascript frameworks. Ie, ones that cause bloat via large dependency trees, and unnecessary computations. These aren't required for the interactivity you described.
I've written one of those React clones in Rust you mention. It was as you say - as much of a mess in practice as a JS framework.
I've written one of those React clones in Rust you mention. It was as you say - as much of a mess in practice as a JS framework.
> but I don't think it's about Javascript
I get that and that's part of the point of my comment. That these screeds always make sure to mention javascript because by bundling javascript in the screed you get default acceptance from the JS haters.
But the fundamental essence of the article is about complaining about SPAs. Which betrays a striking ignorance of what most frontend web software engineers are working on. They are not working on websites for businesses that only need a single form and an email to get the form responses. That usecase is solved and does not require a software engineer. It can be built on wordpress or squarespace.
SPAs are the answer to the question of how do we build an app that is delivered in real time over an internet connection.
The reason these apps are built with JS is because until relatively recently it was the only option. Why is it still used while there are other options? Because WASM is not mature and JS is still faster and there is no killer reason to switch off it.
I get that and that's part of the point of my comment. That these screeds always make sure to mention javascript because by bundling javascript in the screed you get default acceptance from the JS haters.
But the fundamental essence of the article is about complaining about SPAs. Which betrays a striking ignorance of what most frontend web software engineers are working on. They are not working on websites for businesses that only need a single form and an email to get the form responses. That usecase is solved and does not require a software engineer. It can be built on wordpress or squarespace.
SPAs are the answer to the question of how do we build an app that is delivered in real time over an internet connection.
The reason these apps are built with JS is because until relatively recently it was the only option. Why is it still used while there are other options? Because WASM is not mature and JS is still faster and there is no killer reason to switch off it.
> People that complain about SPAs are the modern knights tilting at windmills. What are the primary ways people today consume content? Youtube, tiktok, whatsapp, facebook messenger, instagram, discord, etc, etc.
Facebooks and youtubes and tiktoks are built to push ads most efficiently and SPAs are just that. You're not the customer for them, you're product.
Facebooks and youtubes and tiktoks are built to push ads most efficiently and SPAs are just that. You're not the customer for them, you're product.
Has this author been on the other side of the fence? I have encountered, for every bloated javascript problem child, an equally burdensome python monolith, or sprawling maze of go microservices. I suspect the root cause is something to do with human error, but I digress.
The benefit of much-derided React code when I can onboard new developers from 3 different countries and backgrounds and have them all writing DRY, tested, idiomatic code within a few days. They can then ship a feature that then provides more values to the end user, who probably doesn't care a fig what HTML is. Or, like a patient senior developer, they understand that shipping is preferable to not shipping, and that perfect performance, accessibility, and usability are all asymptotic to us mere mortals.
The benefit of much-derided React code when I can onboard new developers from 3 different countries and backgrounds and have them all writing DRY, tested, idiomatic code within a few days. They can then ship a feature that then provides more values to the end user, who probably doesn't care a fig what HTML is. Or, like a patient senior developer, they understand that shipping is preferable to not shipping, and that perfect performance, accessibility, and usability are all asymptotic to us mere mortals.
We are replacing truly the most disgusting codebase I've ever seen right now, a WP instance (alright) highly customized (worrisome) written by pre-for-loop contractors (uh-oh) which has over 10k lines of jQuery (uh-oh) for a relatively small site, but all of the jQuery lives in one main.js (UH-OH) and executes on every page whether or not it does anything to that page. It's also written in such a way that it crawls the DOM so many times on huge HTML payloads that the entire page slows to a crawl as your computer fan winds up. You'll often get 10 seconds of non-responsive page after the first paint. There's barely any interactivity here as well, just a couple of modals and buttons.
As the client scaled up, they started having serious performance problems that rendered the site completely unusable for some users, and some pages were so bad on the backend that simply visiting a page could cause an outage. Refactorings were considered (minor ones attempted), but the code is so poorly written and brittle that it's actually easier to just fucking rewrite it, so they/we just do targeted performance enhancements, bugfixes, and minor updates while rewriting.
All that to say, the worst codebases I've ever seen are PHP monoliths, (though I've seen some rough Django/flask as well) shitted out by contracting firms which bill high rates for code written by juniors. People (particularly those who frequent this site) are way too focused on the choice of framework when trying to assess these outcomes.
As the client scaled up, they started having serious performance problems that rendered the site completely unusable for some users, and some pages were so bad on the backend that simply visiting a page could cause an outage. Refactorings were considered (minor ones attempted), but the code is so poorly written and brittle that it's actually easier to just fucking rewrite it, so they/we just do targeted performance enhancements, bugfixes, and minor updates while rewriting.
All that to say, the worst codebases I've ever seen are PHP monoliths, (though I've seen some rough Django/flask as well) shitted out by contracting firms which bill high rates for code written by juniors. People (particularly those who frequent this site) are way too focused on the choice of framework when trying to assess these outcomes.
> We lost a decade to smooth talkers and hollow marketeering
To eliminate lemon markets somebody has to be tasked (and rewarded) for doing the slog work that will reduce the information asymmetry. This would normally be trusted experts (tech journalism, academia etc).
To eliminate lemon markets somebody has to be tasked (and rewarded) for doing the slog work that will reduce the information asymmetry. This would normally be trusted experts (tech journalism, academia etc).
Despite all this NextJS has brought me a lot of joy using it. Probably the most joy of all front end experiences web or even desktop (and I quite liked WPF!)
That said I get it: it can be annoying for the user when the site does unpredictable shit which it can sometimes do with a SPA. For example shit appearing just before you click an area of the screen so you end up clicking the wrong thing.
The complexity is a problem too, there is a lot of shit to learn these days to get the app working. NextJS is like autopilot most of the time but you still gonna drop down and troubleshoot NPM dependencies etc. sometimes so there is a lot to know.
That said I get it: it can be annoying for the user when the site does unpredictable shit which it can sometimes do with a SPA. For example shit appearing just before you click an area of the screen so you end up clicking the wrong thing.
The complexity is a problem too, there is a lot of shit to learn these days to get the app working. NextJS is like autopilot most of the time but you still gonna drop down and troubleshoot NPM dependencies etc. sometimes so there is a lot to know.
People tried different things for many years and web apps won simply because they did what people want without the trouble of native apps.
Installing, maintaining, and securing native apps is too much trouble.
Installing, maintaining, and securing native apps is too much trouble.
The author is not advocating for native apps over Web apps. That's not the pretext for this post, and if you're reading it (and the author's motives) through that lens, then you're reading it wrong.
(In fact, they lament the domination of native mobile apps over Web apps—blaming "complexity merchants" for that outcome.)
(In fact, they lament the domination of native mobile apps over Web apps—blaming "complexity merchants" for that outcome.)
Web apps can't work without at least one native app. If that native app can be installed, maintained and secured, so can the others.
The real reason is HTML/JS/CSS is universal platform to code against, unlike myriad of OS-specific toolkits.
The real reason is HTML/JS/CSS is universal platform to code against, unlike myriad of OS-specific toolkits.
I wish I knew what the author was fulminating about.
This article is in dire need of examples and case studies but instead, the author says that it is hard to summarise a “decade” of JS/SPA bloat into one article.
Anyway, to his point about the market for JS frameworks shrinking, I’ve moved my projects to HTMX + AlpineJS. Couldn’t be happier though the entire apparatus seems to be holding together with wire and spit and prayers.
This article is in dire need of examples and case studies but instead, the author says that it is hard to summarise a “decade” of JS/SPA bloat into one article.
Anyway, to his point about the market for JS frameworks shrinking, I’ve moved my projects to HTMX + AlpineJS. Couldn’t be happier though the entire apparatus seems to be holding together with wire and spit and prayers.
Is the author talking about information websites, websites with limited interactivity, or web applications that would feel more at home as desktop applications?
I honestly believe that many of the complaints about SPAs as a bad paradigm don't solve themselves with progressive enhancement; they solve themselves with a better cross-OS development environment and safe, sandboxed modern applets. (Alternatively, your company needs to be homogeneous, and third-party vendors need to develop for both Mac and Windows, and hope Wine is good enough for any other option.)
That leaves websites with limited interactivity. If the author is speaking about these, I can understand the frustration. I'd love to see solutions like liveview or htmx take over. Maybe other solutions will be good enough. However, for us to get beyond talking past each other on these conversations I think we need to always be considering the context and detail the use cases.
I honestly believe that many of the complaints about SPAs as a bad paradigm don't solve themselves with progressive enhancement; they solve themselves with a better cross-OS development environment and safe, sandboxed modern applets. (Alternatively, your company needs to be homogeneous, and third-party vendors need to develop for both Mac and Windows, and hope Wine is good enough for any other option.)
That leaves websites with limited interactivity. If the author is speaking about these, I can understand the frustration. I'd love to see solutions like liveview or htmx take over. Maybe other solutions will be good enough. However, for us to get beyond talking past each other on these conversations I think we need to always be considering the context and detail the use cases.
the author recommends in the first footnote to use other frameworks like vue, svelte, lit/polymer etc., which makes this seem more like an argument against react, when the entire article is about how javascript-driven spa/ssr stacks are bad. there are a couple clarifications next to it to soften that blow but react also "start[s] with simple output" in the same way these tools do. why act like react is the only lemon merchant? i say this as an active user of vue, so maybe im simply at the most complex of them but from my perspective the other tools are about as complex
Setting aside the FA for a second and considering just the market for lemons itself. Imagine being George Akerlof. You coined one of the most famous things in economics (the market for lemons), for which you won the Nobel Frikkin' Prize[1] and your spouse[2] is still a more famous economist than you.
[1] Nobel Memorial Prize if you're a Taleb-inspired pointless hair splitter
[2] Janet Yellen
[1] Nobel Memorial Prize if you're a Taleb-inspired pointless hair splitter
[2] Janet Yellen
I studied economics. Akerlof is more famous economist. Yellen is famous political economist
To be clear, I meant "famous person who is an economist" rather than "economist who is famous among economists" but I take your point.
Its interesting as a theme to spot check things these days with: "is what I think is normal really a zirp/vc-bubble anomaly?"
For me the biggest source of unnecessary complexity is Kubernetes.
If you use envelope math, you rarely need more than one reasonably sized instance, and your key performance bottleneck is database and external apis.
Lots of people can get away with single machine running on Heroku/ec2, until their product logic becomes too complicated for a single dev team to maintain.
If you use envelope math, you rarely need more than one reasonably sized instance, and your key performance bottleneck is database and external apis.
Lots of people can get away with single machine running on Heroku/ec2, until their product logic becomes too complicated for a single dev team to maintain.
Hilarious. The page isn't rendering as (I think) it was intended - half of the screen literally sticks to the top. Maybe the author went too far with his point %) Otherwise, I generally agree. )
SPAs were a zero interest rate phenomenon :’DDD I laughed so hard
In the author's footnote #1, he praises Svelte and Vue. So the whole article boils down to "Don't use React, use Svelte/Vue instead."
Yesterday there was a post for Patterns, an AI framework. Deja vu.
Pretty soon everyone and his school buddies are going to be putting out frameworks for building an AI-enabled application, if they aren't already.
And eventually Microsoft and Apple will incorporate one into their developer products, and maybe some of those VC startups will get acquired.
Pretty soon everyone and his school buddies are going to be putting out frameworks for building an AI-enabled application, if they aren't already.
And eventually Microsoft and Apple will incorporate one into their developer products, and maybe some of those VC startups will get acquired.
I disagree that JS frameworks are in any way a problem. React is not substantially different from developing a Rails frontend using um... what do the kids use these days? HAML? Hamlet! No, that's not right. Anyway...
The real trouble comes when you think that "switching to <hot new framework>" will solve all of your problems. This is equivalent to thinking that giving your troops Scottish-made swords (when they've been using German-made swords) will somehow make them fight better.
Armed with this disinformation, teams march blindly into the meat grinder of reality. "We need to do auth... again? Didn't we just do that in Django? And then Angular? Arghhhh". If your auth implementation in django was bad, and you rewrote it in angular and introduced problems, rewriting it in react is not going to magically make your developers do it right this time.
The real trouble comes when you think that "switching to <hot new framework>" will solve all of your problems. This is equivalent to thinking that giving your troops Scottish-made swords (when they've been using German-made swords) will somehow make them fight better.
Armed with this disinformation, teams march blindly into the meat grinder of reality. "We need to do auth... again? Didn't we just do that in Django? And then Angular? Arghhhh". If your auth implementation in django was bad, and you rewrote it in angular and introduced problems, rewriting it in react is not going to magically make your developers do it right this time.
React is not substantially different from developing a Rails frontend
I think you misinterpreted the article. The developer experience isn’t what’s at stake here, it’s what the user experiences. And for 95% of systems (99%?) as simple Rails app will be faster than a React app.
I think you misinterpreted the article. The developer experience isn’t what’s at stake here, it’s what the user experiences. And for 95% of systems (99%?) as simple Rails app will be faster than a React app.
User experience is affected directly by developer experience. If it's tedious, or complex, or error-prone, to develop using a framework, then the user experience will likely suffer.
I'm curious to see actual performance comparison metrics for a site written on rails versus one written on, e.g., Next.js.
Really the specific framework isn’t an issue: it’s down to minimising as much as possible the amount of JS you ship to the client.
This is a pompously written puff piece. Moving logic to the client is the right choice for an application, and the wrong choice for mostly non-interactive content. Know what you're building and choose the right tools/use the right techniques.
Javascript has been (and kind of continues to be) a mess, but thankfully you can compile almost anything to WebASM these days, and 95% of people have browsers that support WebASM, so if you want to build your app in Rust with QT have at it.
Javascript has been (and kind of continues to be) a mess, but thankfully you can compile almost anything to WebASM these days, and 95% of people have browsers that support WebASM, so if you want to build your app in Rust with QT have at it.
> Moving logic to the client is the right choice for an application, and the wrong choice for mostly non-interactive content
Well then we're fucked. Juniors and a good chunk of intermediate level devs do not understand where one solution ends and another begins, let alone how they work or their trade-offs, so if we want things to not suck ass in the real world (where there aren't enough senior devs who actually know and care) we'll have to figure this one out.
My gut says that it starts with a solution similar to Qwik, but I haven't thought about the DX implications deeply enough.
Well then we're fucked. Juniors and a good chunk of intermediate level devs do not understand where one solution ends and another begins, let alone how they work or their trade-offs, so if we want things to not suck ass in the real world (where there aren't enough senior devs who actually know and care) we'll have to figure this one out.
My gut says that it starts with a solution similar to Qwik, but I haven't thought about the DX implications deeply enough.
JavaScript is a mess but HTML is a catastrophe. I don’t understand how JS gets so much flak when most of its shortcomings are actually shortcomings of HTML interaction.
> Know what you're building and choose the right tools/use the right techniques.
I feel that this is the author's point: in the modern era, the "right tool" is React (in the worst possible way and often because of ignorance). As the saying goes: when all you have is a hammer, every problem looks like a nail.
I feel that this is the author's point: in the modern era, the "right tool" is React (in the worst possible way and often because of ignorance). As the saying goes: when all you have is a hammer, every problem looks like a nail.
Is there an example of QT via WASM? That would be quite the sight.
Holy crap is that a broken mess. They should take that down.
Is Rust with Qt a thing?
[deleted]
> Those who dared speak up were branded "negative" and "haters", no matter how much data they lugged in tow.
I'd argue the rot goes beyond JS frontends and into a lot of webdev infrastructure, including libraries and full-stack frameworks. And that lemons tend to cluster with other lemons.
I'd argue the rot goes beyond JS frontends and into a lot of webdev infrastructure, including libraries and full-stack frameworks. And that lemons tend to cluster with other lemons.
I've made a peace with this, but I'm building what I would consider a modern stack. The central component is a reactive back-end much like Excel, and the UI is then a minimal HTML shim on top of a server. I believe tailwind is a great way to represent styles and CSS without a bunch of fuss, and this combo is working well with me.
The key challenge I have is that I need to switch gears from platform building and building products. https://www.adama-platform.com/
The key challenge I have is that I need to switch gears from platform building and building products. https://www.adama-platform.com/
I really love what you’re building here. If you ever get to a point where you’d want outside help from a PL wonk, let me know. Email is my HN username at Google’s ubiquitous email service.
[deleted]
Did I miss it, or did the author not state what the better solution is?
> No, we need to move our attention back to the folks that have been right all along. The people who never gave up on semantic markup, CSS, and progressive enhancement for most sites. The people who, when slinging JS, have treated it as special occasion food.
[deleted]
BuckyBeaver(1)
BuckyBeaver(1)
One of the linked articles is much better and to the point: https://ericwbailey.website/published/modern-health-framewor...
My 2c: I've seen good experiences, but a lot more poor ones. I've worked on them and they were n times more expensive for very little benefit. I don't think it's by design, but more cynical people might. I think it's just a dogma among developers and management too afraid to step in because developers hold too much power. They want to work on this because everyone else is, and if they can't they will go somewhere else and then you need to find new developers and everyone knows there aren't any available.
We switched to a server side rendered spa stack because the developers said "don't want to be stuck on old fashioned stacks, want to work on cool things". We then needed twice the time and twice the developers to get things done.
So basically the way out of this is for someone to hype up a server side solution and sell it as a shiny new thing. It needs to be logical in a way that makes lights in heads go on, but also somewhat mysterious and new. Deno Islands fit that mold, we'll see if it pans out.