12 ms·

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 ignor

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.

taurath 4y ago
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
- slightlyoff 4y ago
  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-loaded/ 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.
  - trollied 4y ago
    Taking >10s for a site to be usable is absolutely insane. This is not ok, I don’t know when it became acceptable.
  - mrj 4y ago
    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.
    - 4y ago
nafey 4y ago
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.
- cuu508 4y ago
  What kind of app were you building?
  - deleted 4y ago
    [deleted]
will_wright 4y ago
Well written article, thanks! I think some of your critics need to look up the term "veiled criticism"
- ilyt 4y ago
  Nah it's just too much of purple prose. Frankly the article is just as bloated with words as the thing it criticizes
azangru 4y ago
> 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?
- di4na 4y ago
  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.
  - tylerhou 4y ago
    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 4y ago
      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 4y ago
        > 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".
christophilus 4y ago
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.
stevebmark 4y ago
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.
mock-possum 4y ago
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.

taurath 4y ago

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

slightlyoff 4y ago
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-loaded/ 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.
- trollied 4y ago
  Taking >10s for a site to be usable is absolutely insane. This is not ok, I don’t know when it became acceptable.
- mrj 4y ago
  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.
  - 4y ago

nafey 4y ago

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.

cuu508 4y ago
What kind of app were you building?
- deleted 4y ago
  [deleted]

will_wright 4y ago

Well written article, thanks! I think some of your critics need to look up the term "veiled criticism"

ilyt 4y ago
Nah it's just too much of purple prose. Frankly the article is just as bloated with words as the thing it criticizes

azangru 4y ago

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

di4na 4y ago
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.
- tylerhou 4y ago
  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 4y ago
    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 4y ago
      > 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".

christophilus 4y ago

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.

stevebmark 4y ago

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.

mock-possum 4y ago

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.