[azangru]

> 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?

[slightlyoff]

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...

[azangru]

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.

[zeroxp]

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.

[di4na]

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.

[azangru]

> 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/

[tylerhou]

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.

[Zanfa]

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.

[azangru]

> 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".