20 ms·

I wrote JavaScript to avoid JavaScript

74 points by asaaki 6y ago

ochronus 6y ago
Nice! Pagespeed Insights is also happy with your site ;) I especially liked the new format stats, pretty impressive. Now if only I found a good node module for avif conversion...
- asaaki 6y ago
  Thanks. If you're okay with a non-node/js solution, use https://github.com/kornelski/cavif-rs https://github.com/kornelski/cavif-rs - it does the job for me pretty well. For node it looks surprisingly disappointing right now, the only real candidates being the packages @saschazar/wasm-avif (v1.0.0) and avif (v0.0.1-alpha2) — I'll probably never understand the ecosystem and community, the format is out for some time and fully supported in the most widely used browser, yet barely noticeable support in the JS world.
  - ochronus 6y ago
    Thanks for the tips - I'm tied to node at the moment - wasm-avif has serious issues with thready safety an memleaks :( tried it.
    - asaaki 6y ago
      If you're in control of the environment, you might want to consider the yak shaving road and build a node package with a C, C++ or Rust library then. ;-)
    - davidmurdoch 6y ago
      Sharp lib is veeeerrryyy close to AVIF support: https://github.com/lovell/sharp/issues/2289 https://github.com/lovell/sharp/issues/2289 (you can compile a version to use for yourself, it's just not production stable yet).
anonymoushn 6y ago
On OSX Chrome, this page is always horizontally scrollable because the navbar is wider than the rest of the content by a margin of the vertical scrollbar's width. You can set max-width: 100% on the navbar to fix this.
- vanderZwan 6y ago
  I suspect scrollbars are among the most underrated source of unexpected CSS bugs across different browsers/platforms. I never see anyone online complain about them, yet at work we constantly have to work our way around them.
- asaaki 6y ago
  That's interesting. I'll have Mac access only next month. The setting `max-width: 100%` actually breaks the design completely, chopping it down to a half. I have to try this solution[1] to see if that helps to avoid the scrolling. [1] https://stackoverflow.com/a/56382662/653173 https://stackoverflow.com/a/56382662/653173
Dionakra 6y ago
I did almost the same last weekend. I wanted to start a blog[1] but all options seemed too much for a simple purpose that is a blog. After researching about VuePress, Sapper, Next.js, Gatsby and so on, I finally decided that it wouldn't have any kind of JavaScript. I was tempted to create yet another static site generator, but I am sticking to the old HTML + CSS duo (and, regarding CSS, classless CSS) for my blog. Yes, it has some downsides, but hey, it only needs a text editor and internet connection and the blog is blazingly fast. [1] https://boix.dev/ https://boix.dev/
- muspimerol 6y ago
 For ease of maintenance and portability I think markdown is really the king of formats for blog content. Are you writing the posts in HTML? Why are you intermittently using for paragraphs and to wrap other elements?
 - Dionakra 6y ago
 Yep, I am writing the posts in HTML. The reason to avoid Markdown (which I love) and other things is to avoid any kind of building tools. I tried to install Gatsby on a Windows machine and I had several errors. I wanted to remove any dependency on external software. I wanted it to be modifiable with just a text editor and nothing else. Regarding the use of is because the tag with the chosen CSS leaves too much space after <h*> tags, while doesn't, and as I wanted to just use HTML tags and not create my own version of the CSS, I found the easiest way to achieve that.
 - muspimerol 6y ago
 I definitely understand the desire to avoid a build-time tool. Especially Gatsby is way harder than it should be to get up and running. But for me, portability and data integrity trumps ease-of-publishing. If you want to move your blog to a new system in 5 years, you'll have to migrate a bunch of HTML. If you had the posts in markdown, chances are it would be a plug-and-play with the new system. That's the reason I pointed out the usage - your source of truth for your data is HTML, but in this case it's already getting mixed up with design-related oddities. Not bashing your choice for your blog, I think it's reasonable. I just wonder if HTML is the most resilient way to store blog data. It's something I considered a lot when redoing my blog last year.
nodelessness 6y ago
He used the stones to destroy the stones.
gbrindisi 6y ago
Wonderful! I am so irritated with JavaScript bloat... completely unnecessary cruft 99% of the time. I built my blog with the goal to have zero js but I had to capitulate for google analytics. The blog is a static website deployed on a CDN and I have no access to access.log - I honestly couldn’t find any analytics solution that won’t require js.
- chrismorgan 6y ago
  > I had to capitulate for google analytics. Ask yourself how much you actually need analytics. I found I seldom looked at it. I myself replaced Google Analytics with self-hosted Matomo for a while, but then I just dropped it altogether because I simply don’t need it. Now I do have server logs that I can look at, and from time to time I do (and they reveal things like Atom feeds consume the substantial majority of the traffic and page loads, which client-side JS logging would never have revealed!), but it wouldn’t bother me to have no analytics at all.
  - gbrindisi 6y ago
    I just want to know if what I write is being read and how is propagated/shared
    - zelphirkalt 6y ago
      If effort or time was not a limitation, you could opt for a tool that you can self host, instead of increasing Google's data.
    - forgotmypw17 6y ago
      access.log
  - asaaki 6y ago
    I decided to have no (client side) tracking at all, for both usually it requires JS and cookies. And honestly I don't like to have both on my site if not strictly necessary (as a European citizen I'm also quite aware of all the shenanigans one has to do wrt privacy and consent).
chrismorgan 6y ago
I strongly advise against this style of justification: text-align: justify; text-justify: inter-character; Justification is typically only particularly suitable for fairly narrow columns, combined with hyphenation. And inter-character justification is… hazardous, only to be entered into with substantial caution. Sometimes layouts and what occurs to the inline-end [right] of the layout can also justify justification But unless one of these conditions is true, I recommend against any form of justification, especially inter-character. Another bit of CSS that I would like removed is the `html { cursor: default; }`. Apps can do that so that chrome uses the default cursor (and restore it to auto in content areas), but content websites shouldn’t do that. I want to see the usual I-beam when I’m hovering over text.
- jakub_g 6y ago
  +1. Justification is something that you feel like you should do to have "nice layout" but it hinders readability according to many studies. Check BBC, NYTimes, The Guardian, Reuters, AP News, Wikipedia, HN - none of them uses text justification.
  - zelphirkalt 6y ago
    Huh? Can you link such a study? I always found it easier to read justified text. Already the annoyance, that the text is not ending at the same "column" on the screen on the right side of the text is distracting. It also looks like no one really took care and simply dumped a ton of words, when it is left aligned, at least to me.
    - notRobot 6y ago
      https://ux.stackexchange.com/a/93442 https://ux.stackexchange.com/a/93442
      - a20201109 6y ago
        That link mentions no such studies. It has opinions from typographers, but no data on how text justification affects readability.
joseluisq 6y ago
At first glance, the title is a bit misleading I think a more accurate one could have been "I don't write Javascript to avoid it" or "I just avoid to write Javascript", etc. Anyway great that the author remarks the idea to avoid Javascript bloat but honestly that's not something new.
zelphirkalt 6y ago
Someone must have gotten the a hold of the credentials of the device, where I put my brain dumps and made it into a blog post. I wish more people did approach web development in this kind of minimalist most accessible and responsive way, that does not require me to trust all their scripts and simply lets me access a hypertext document to get the information I seek.
- dgb23 6y ago
  The OP mentions things like Nextjs, which I find odd. A well crafted site built with the help of Nextjs (and similar) works w/o JS just fine: The site becomes progressively enhanced through hydration, but if you disable JS altogether, you can still read and navigate the site. For sites with minimalist designs, straight forward data models and low to no interaction (like a blog or similar) I agree that any sort of JS can be overkill. But professional web devs use these technologies because they tick some important boxes (trade-offs) ranging from expressivity, structure to performance and provide a uniform way to write front-ends.
  - zelphirkalt 6y ago
    Aha? That sounds interesting. Usually those "I'm gonna use a full blown framework, although nothing special is needed." websites appear in pure white over the whole screen, with nothing to be seen. Which is usually when I close the tab. Are you saying, that NextJS encourages a design, which keeps no script in mind? Is it its default to render a noscript tag or something? This would definitely raise it in my personal rating.
    - ruicaridade 6y ago
      Next has two different ways to deploy: 1. Next renders the React page server-side and sends it as html/css. Once everything is done loading on the client, it becomes a regular React page. Requires a server. 2. Next pre-renders your whole website with data fetched at build time, like Hugo or Jekyll. Drop it on a CDN and you're golden.
draw_down 6y ago
Boo JavaScript! We hate you, JavaScript!
ChiefOBrien 6y ago
I don't like the style this site uses. Ugly color choice, typography and whitespace all over the place, and emoji ridden visual noise. Like why spend all the time picking exotic fonts and optimizing images if the presentation is simply put, awful?
vanderZwan 6y ago
So whenever I see an article about this topic I like to open the Network tab of Developer Tools, disable cache and refresh to see how this work out in practice. This page loaded in just under a second, and had 1.30MB of data in total. Pretty good! However, when looking at where all the data is there seems to be something fishy going on. Basically, for some reason it loaded both a .webp and .webm file for the sticky header animation. The webp is a 450 KiB choppy animation, the webm a 770 KiB smooth one. If we skipped the webp that would be a 33% reduction in data and presumably equivalent speed-up of page load, so why bother loading a choppy gif? Looking into the page source I get this tag: <video autoplay="" loop="" muted="" playsinline="" poster="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.webp"> <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.hvec.mp4" type="video/mp4; codecs=hvc1"> <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.hvec.mp4" type="video/mp4; codecs=hevc"> <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.h264.mp4" type="video/mp4; codecs=avc1"> <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.webm" type="video/webm; codecs=vp9"> </video> So I'm wondering if there is a point in adding a poster like that, given that it's not going to be seen for most people and probably going to be a major part of the data budget on any page that has any number of video tags on it. (Also, my browser acts a bit funny here: if I refresh again it only downloads the webp, but still shows the webm - despite cache being disabled. Could it be that the video tag ignores my cache settings?)
- infensus 6y ago
 I've had similar experiences with video cache and never fully understood it. For example, when I want to block a webm with ublock, adding a rule and refreshing never works, I need to close and reopen the tab for it to take effect.
- asaaki 6y ago
 I think I should just remove the poster, it was initially replacing the GIF, which was megabytes in size. Given that the sizes of the WebP and WebM animations are pretty close I can live without it; all major browsers support both formats anyway. I cannot help with the caching fun here, quick tested in both Chrome and Firefox. There's probably something strange in the video tag, either by design or by implementation.
ubermonkey 6y ago
As a counterpoint, I just want to mention that I once wrote perl that wrote Javascript that wrote HTML. And I'm not even ashamed of it.
- asaaki 6y ago
  Perl … haven't seen that old friend for a very long time.
  - ubermonkey 6y ago
    I should be clear this was about 15 years ago.
davidmurdoch 6y ago
> The only annoying part is still that the image dimensions are not reserved appropriately, even with present width and height attributes. So the layout can jump around if you scroll past the not yet loaded image. If you have an idea how to deal with that within picture groups, I love to hear about it. See https://www.andyshora.com/css-image-container-padding-hack.html https://www.andyshora.com/css-image-container-padding-hack.h... I used the trick on https://jessicakhope.com's https://jessicakhope.com's blog-post pages. View the source on https://jessicakhope.com/blog/family-workcation-in-portland-oregon/ https://jessicakhope.com/blog/family-workcation-in-portland-..., for examples. The site is static and is generated by hugo. The image container paddings are generated at compile time.
- asaaki 6y ago
  Thank you for the tip/link. Seems to be an appropriate solution, just have to fiddle with my build process for a bit.
temporallobe 6y ago
I do a lot of JavaScript, maintaining older and newer apps. I have been of the opinion for a decade that most apps and even static sites are way more JavaScript-heavy than they need to be and that we depend far too much on frameworks, so much so that even very good developers don’t know much actual HTML and CSS. Yeah I know it’s the old “too much abstraction” argument, but I strongly believe it. It’s a breath of fresh air when people write articles like this because it brings us down to earth. Now, I’m not saying going JS-free is appropriate for all cases or even most cases. Sometimes the customer has complex requirements or the project you’re brought in on uses JS at its core (Rails, React, Angular, any of the SPA frameworks). Heck, I’ve even written my own SPA framework because reasons. Point is, there is absolutely nothing wrong with the “old fashioned” static page apps in many cases - using forms, letting the back-end handle business logic, not having to worry about routing, etc.

74 points by asaaki 6y ago

Nice! Pagespeed Insights is also happy with your site ;) I especially liked the new format stats, pretty impressive. Now if only I found a good node module for avif conversion...

asaaki 6y ago
Thanks. If you're okay with a non-node/js solution, use https://github.com/kornelski/cavif-rs https://github.com/kornelski/cavif-rs - it does the job for me pretty well. For node it looks surprisingly disappointing right now, the only real candidates being the packages @saschazar/wasm-avif (v1.0.0) and avif (v0.0.1-alpha2) — I'll probably never understand the ecosystem and community, the format is out for some time and fully supported in the most widely used browser, yet barely noticeable support in the JS world.
- ochronus 6y ago
  Thanks for the tips - I'm tied to node at the moment - wasm-avif has serious issues with thready safety an memleaks :( tried it.
  - asaaki 6y ago
    If you're in control of the environment, you might want to consider the yak shaving road and build a node package with a C, C++ or Rust library then. ;-)
  - davidmurdoch 6y ago
    Sharp lib is veeeerrryyy close to AVIF support: https://github.com/lovell/sharp/issues/2289 https://github.com/lovell/sharp/issues/2289 (you can compile a version to use for yourself, it's just not production stable yet).

anonymoushn 6y ago

On OSX Chrome, this page is always horizontally scrollable because the navbar is wider than the rest of the content by a margin of the vertical scrollbar's width. You can set max-width: 100% on the navbar to fix this.

vanderZwan 6y ago
I suspect scrollbars are among the most underrated source of unexpected CSS bugs across different browsers/platforms. I never see anyone online complain about them, yet at work we constantly have to work our way around them.
asaaki 6y ago
That's interesting. I'll have Mac access only next month. The setting `max-width: 100%` actually breaks the design completely, chopping it down to a half. I have to try this solution[1] to see if that helps to avoid the scrolling. [1] https://stackoverflow.com/a/56382662/653173 https://stackoverflow.com/a/56382662/653173

Dionakra 6y ago

I did almost the same last weekend. I wanted to start a blog[1] but all options seemed too much for a simple purpose that is a blog. After researching about VuePress, Sapper, Next.js, Gatsby and so on, I finally decided that it wouldn't have any kind of JavaScript. I was tempted to create yet another static site generator, but I am sticking to the old HTML + CSS duo (and, regarding CSS, classless CSS) for my blog. Yes, it has some downsides, but hey, it only needs a text editor and internet connection and the blog is blazingly fast. [1] https://boix.dev/ https://boix.dev/

muspimerol 6y ago
For ease of maintenance and portability I think markdown is really the king of formats for blog content. Are you writing the posts in HTML? Why are you intermittently using for paragraphs and to wrap other elements?
- Dionakra 6y ago
 Yep, I am writing the posts in HTML. The reason to avoid Markdown (which I love) and other things is to avoid any kind of building tools. I tried to install Gatsby on a Windows machine and I had several errors. I wanted to remove any dependency on external software. I wanted it to be modifiable with just a text editor and nothing else. Regarding the use of is because the tag with the chosen CSS leaves too much space after <h*> tags, while doesn't, and as I wanted to just use HTML tags and not create my own version of the CSS, I found the easiest way to achieve that.
 - muspimerol 6y ago
 I definitely understand the desire to avoid a build-time tool. Especially Gatsby is way harder than it should be to get up and running. But for me, portability and data integrity trumps ease-of-publishing. If you want to move your blog to a new system in 5 years, you'll have to migrate a bunch of HTML. If you had the posts in markdown, chances are it would be a plug-and-play with the new system. That's the reason I pointed out the usage - your source of truth for your data is HTML, but in this case it's already getting mixed up with design-related oddities. Not bashing your choice for your blog, I think it's reasonable. I just wonder if HTML is the most resilient way to store blog data. It's something I considered a lot when redoing my blog last year.

nodelessness 6y ago

He used the stones to destroy the stones.

gbrindisi 6y ago

Wonderful! I am so irritated with JavaScript bloat... completely unnecessary cruft 99% of the time. I built my blog with the goal to have zero js but I had to capitulate for google analytics. The blog is a static website deployed on a CDN and I have no access to access.log - I honestly couldn’t find any analytics solution that won’t require js.

chrismorgan 6y ago
> I had to capitulate for google analytics. Ask yourself how much you actually need analytics. I found I seldom looked at it. I myself replaced Google Analytics with self-hosted Matomo for a while, but then I just dropped it altogether because I simply don’t need it. Now I do have server logs that I can look at, and from time to time I do (and they reveal things like Atom feeds consume the substantial majority of the traffic and page loads, which client-side JS logging would never have revealed!), but it wouldn’t bother me to have no analytics at all.
- gbrindisi 6y ago
  I just want to know if what I write is being read and how is propagated/shared
  - zelphirkalt 6y ago
    If effort or time was not a limitation, you could opt for a tool that you can self host, instead of increasing Google's data.
  - forgotmypw17 6y ago
    access.log
- asaaki 6y ago
  I decided to have no (client side) tracking at all, for both usually it requires JS and cookies. And honestly I don't like to have both on my site if not strictly necessary (as a European citizen I'm also quite aware of all the shenanigans one has to do wrt privacy and consent).

chrismorgan 6y ago

I strongly advise against this style of justification: text-align: justify; text-justify: inter-character; Justification is typically only particularly suitable for fairly narrow columns, combined with hyphenation. And inter-character justification is… hazardous, only to be entered into with substantial caution. Sometimes layouts and what occurs to the inline-end [right] of the layout can also justify justification But unless one of these conditions is true, I recommend against any form of justification, especially inter-character. Another bit of CSS that I would like removed is the `html { cursor: default; }`. Apps can do that so that chrome uses the default cursor (and restore it to auto in content areas), but content websites shouldn’t do that. I want to see the usual I-beam when I’m hovering over text.

jakub_g 6y ago
+1. Justification is something that you feel like you should do to have "nice layout" but it hinders readability according to many studies. Check BBC, NYTimes, The Guardian, Reuters, AP News, Wikipedia, HN - none of them uses text justification.
- zelphirkalt 6y ago
  Huh? Can you link such a study? I always found it easier to read justified text. Already the annoyance, that the text is not ending at the same "column" on the screen on the right side of the text is distracting. It also looks like no one really took care and simply dumped a ton of words, when it is left aligned, at least to me.
  - notRobot 6y ago
    https://ux.stackexchange.com/a/93442 https://ux.stackexchange.com/a/93442
    - a20201109 6y ago
      That link mentions no such studies. It has opinions from typographers, but no data on how text justification affects readability.

joseluisq 6y ago

At first glance, the title is a bit misleading I think a more accurate one could have been "I don't write Javascript to avoid it" or "I just avoid to write Javascript", etc. Anyway great that the author remarks the idea to avoid Javascript bloat but honestly that's not something new.

zelphirkalt 6y ago

Someone must have gotten the a hold of the credentials of the device, where I put my brain dumps and made it into a blog post. I wish more people did approach web development in this kind of minimalist most accessible and responsive way, that does not require me to trust all their scripts and simply lets me access a hypertext document to get the information I seek.

dgb23 6y ago
The OP mentions things like Nextjs, which I find odd. A well crafted site built with the help of Nextjs (and similar) works w/o JS just fine: The site becomes progressively enhanced through hydration, but if you disable JS altogether, you can still read and navigate the site. For sites with minimalist designs, straight forward data models and low to no interaction (like a blog or similar) I agree that any sort of JS can be overkill. But professional web devs use these technologies because they tick some important boxes (trade-offs) ranging from expressivity, structure to performance and provide a uniform way to write front-ends.
- zelphirkalt 6y ago
  Aha? That sounds interesting. Usually those "I'm gonna use a full blown framework, although nothing special is needed." websites appear in pure white over the whole screen, with nothing to be seen. Which is usually when I close the tab. Are you saying, that NextJS encourages a design, which keeps no script in mind? Is it its default to render a noscript tag or something? This would definitely raise it in my personal rating.
  - ruicaridade 6y ago
    Next has two different ways to deploy: 1. Next renders the React page server-side and sends it as html/css. Once everything is done loading on the client, it becomes a regular React page. Requires a server. 2. Next pre-renders your whole website with data fetched at build time, like Hugo or Jekyll. Drop it on a CDN and you're golden.

draw_down 6y ago

Boo JavaScript! We hate you, JavaScript!

ChiefOBrien 6y ago

I don't like the style this site uses. Ugly color choice, typography and whitespace all over the place, and emoji ridden visual noise. Like why spend all the time picking exotic fonts and optimizing images if the presentation is simply put, awful?

vanderZwan 6y ago

So whenever I see an article about this topic I like to open the Network tab of Developer Tools, disable cache and refresh to see how this work out in practice. This page loaded in just under a second, and had 1.30MB of data in total. Pretty good! However, when looking at where all the data is there seems to be something fishy going on. Basically, for some reason it loaded both a .webp and .webm file for the sticky header animation. The webp is a 450 KiB choppy animation, the webm a 770 KiB smooth one. If we skipped the webp that would be a 33% reduction in data and presumably equivalent speed-up of page load, so why bother loading a choppy gif? Looking into the page source I get this tag: <video autoplay="" loop="" muted="" playsinline="" poster="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.webp"> <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.hvec.mp4" type="video/mp4; codecs=hvc1"> <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.hvec.mp4" type="video/mp4; codecs=hevc"> <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.h264.mp4" type="video/mp4; codecs=avc1"> <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.webm" type="video/webm; codecs=vp9"> </video> So I'm wondering if there is a point in adding a poster like that, given that it's not going to be seen for most people and probably going to be a major part of the data budget on any page that has any number of video tags on it. (Also, my browser acts a bit funny here: if I refresh again it only downloads the webp, but still shows the webm - despite cache being disabled. Could it be that the video tag ignores my cache settings?)

infensus 6y ago
I've had similar experiences with video cache and never fully understood it. For example, when I want to block a webm with ublock, adding a rule and refreshing never works, I need to close and reopen the tab for it to take effect.
asaaki 6y ago
I think I should just remove the poster, it was initially replacing the GIF, which was megabytes in size. Given that the sizes of the WebP and WebM animations are pretty close I can live without it; all major browsers support both formats anyway. I cannot help with the caching fun here, quick tested in both Chrome and Firefox. There's probably something strange in the video tag, either by design or by implementation.

ubermonkey 6y ago

As a counterpoint, I just want to mention that I once wrote perl that wrote Javascript that wrote HTML. And I'm not even ashamed of it.

asaaki 6y ago
Perl … haven't seen that old friend for a very long time.
- ubermonkey 6y ago
  I should be clear this was about 15 years ago.

davidmurdoch 6y ago

> The only annoying part is still that the image dimensions are not reserved appropriately, even with present width and height attributes. So the layout can jump around if you scroll past the not yet loaded image. If you have an idea how to deal with that within picture groups, I love to hear about it. See https://www.andyshora.com/css-image-container-padding-hack.html https://www.andyshora.com/css-image-container-padding-hack.h... I used the trick on https://jessicakhope.com's https://jessicakhope.com's blog-post pages. View the source on https://jessicakhope.com/blog/family-workcation-in-portland-oregon/ https://jessicakhope.com/blog/family-workcation-in-portland-..., for examples. The site is static and is generated by hugo. The image container paddings are generated at compile time.

asaaki 6y ago
Thank you for the tip/link. Seems to be an appropriate solution, just have to fiddle with my build process for a bit.

temporallobe 6y ago

I do a lot of JavaScript, maintaining older and newer apps. I have been of the opinion for a decade that most apps and even static sites are way more JavaScript-heavy than they need to be and that we depend far too much on frameworks, so much so that even very good developers don’t know much actual HTML and CSS. Yeah I know it’s the old “too much abstraction” argument, but I strongly believe it. It’s a breath of fresh air when people write articles like this because it brings us down to earth. Now, I’m not saying going JS-free is appropriate for all cases or even most cases. Sometimes the customer has complex requirements or the project you’re brought in on uses JS at its core (Rails, React, Angular, any of the SPA frameworks). Heck, I’ve even written my own SPA framework because reasons. Point is, there is absolutely nothing wrong with the “old fashioned” static page apps in many cases - using forms, letting the back-end handle business logic, not having to worry about routing, etc.