Stop Making JavaScript Do Everything – Fast WebApp 101
bytes.vadelabs.com
From embarrassing 30s to consistent 90s on Lighthouse - this is the story of performance optimization gone wrong, then right. What started as a typical modern web stack became a journey of unlearning, where an accidental JavaScript-free deploy revealed that sometimes less is more.
  • LazerFX@sh.itjust.worksEnglish
    0·
    8 days ago

    I started developing websites in the mid-90’s, and shipped my first commercial one in '99. I didn’t really have JavaScript (As we know it today) - it was a fancy client-side ‘make-funky-things-happen’ enabler, not a ‘make-the-whole-page-work’ enabler. I’ve always looked at frameworks as something that’s useful to solve specific problems - Google Mail couldn’t be made without a framework. A web forum? It might help. A regular website? Doesn’t need it.

    You don’t need an SPA to render any of the marketing, sales or other websites. Most webshops don’t need an SPA, just some light basket handling and data rendering and caching. But say that to any modern web dev, and you’re looked at as though you’ve got three heads, while they ship a page that’s multiple megabytes of JS to layout some text and prettify some pictures.

    • hperrin@lemmy.caEnglish
      0·
      7 days ago

      I’m a modern web dev and I completely agree with you. Too much unnecessary JavaScript these days.

  • hperrin@lemmy.caEnglish
    0·
    7 days ago

    JavaScript is adequate for doing everything, but should be used sparingly.

    I feel like if your web page is mostly dependent on the speed of your chosen framework, it’s probably not doing anything complicated enough to warrant a framework in the first place. In that case, JavaScript becomes unnecessary fluff.

    My email service is mainly bottlenecked by the speed of my Postgres queries, so optimizing them is much more important and impactful. Good database and query design is a must.

    Just look at Gmail. Their frontend is slow as hell, but their backend is lightning fast, and nobody really complains. Once you’re past that first couple seconds of a loading bar, you care a lot more about how quickly the next interaction takes, and the next, and the next. I believe page load times for a dynamic page don’t matter as much as the industry thinks they do.

    That being said, there’s obviously an upper limit. Five seconds to even get the HTML would be really pushing it.

    I’ve written tons of simple pages that just use plain old JS too. It’s surprisingly easy to not use a framework these days. Here’s one of my favorites, that lets you perform WebDAV functions all with plain JS:

    https://github.com/sciactive/nephele/blob/master/packages/plugin-index/src/IndexPage.svelte

    (It’s rendered on the server side with Svelte into plain HTML, and all the JS in the <script> tag at the top there is plain JS that runs in the browser.)