Too Much JavaScript? Why the Front End Needs to Build Better

2 points by hernantz 1 year ago | 5 comments
  • mydriasis 1 year ago
    > Often, it boils down to one common problem: Too much client-side JavaScript. This is not a cost-free error. One retailer realized they were losing $700,000 a year per kilobyte of JavaScript, Russell said.

    Boy that's a lot.

    You know recently I tried writing "just browser native javascript" for my little baby website. It's all through Github pages, so they give you a nice little server that you can use based on your git repository. It's shockingly nice, and also shockingly easy to get stuff done with just vanilla JS.

    I wonder how much I could get done if I weren't terrible at CSS, haha. That's really the only thing holding me back from making my site appealing to look at. The JS is honestly very easy, it's a simple language to use and the browser is an awesome environment with a billion and one tools ready for you to use.

    But CSS, man. Every time I try to style something it winds up looking like a 2002 haunted house nightmare.

    • shortrounddev2 1 year ago
      if WASM could manipulate the dom we could write our pages entirely in compiled languages which optimize their builds. As it is right now, WASM seems to be useful only to people who do clientside computation
      • rolandtannous 1 year ago
        what happened to static website generators? They're clean, fast and leave almost 0 carbon footprint (theoretically)
        • senttoschool 1 year ago
          They're still here. But SSG websites can still have plenty of Javascript. It's just that the HTML for every page was pre-rendered.

          But SSGs aren't practical for web apps. They work great for content-only sites.

          • PaulHoule 1 year ago
            Or what about the sever-side rendered UI that Ebay, Amazon and all the "dot com" companies built in 1999?

            I was developing Figma-like applications in 2005 but today I think 95% of React apps are simple form applications that are not so simple because of all the complexity of React, the build system, etc

            The knowledge of how to make these SSR applications seems to be lost, like the formula for Damscasus steel or how Stonehenge or the Egyptian pyramids were made.

            It can't be that DX is being privileged over UX because developers are always complaining about Javascript build systems and "how hard it is to keep up" although if you really look close there has been primarily stagnation since the rise of React, I mean, we got hooks, and we have numerous "me too" frameworks like Vue and Svelte that put blinders on to make it more straightforward to write form applications that could be written as SSRs at the expense of being able to write applications which need a client-side framework (say a 3-d world in react-three-fiber.)

            People who were ahead of the curve in SSR development circa 2000 knew you needed maybe 100 loc of helper functions in your back end to do things like: take a form value and write it into

               <input type="hidden" name={name} value={value} />
            which of course proper character escaping. <select> always should have been something like

               <select selectedValue="x">
      <option value="x">ecchs!</option>
   </select>
            but you can write some helper function that behaves like that. After about a decade of web apps, you finally started seeing frameworks like Ruby on Rails, Struts, Spring, etc. that sometimes contained those helper functions but sometimes didn't. When they did contain those helper functions they were a much larger contribution to developer productivity and application quality than the rest of the framework.

            There was also the mystification around "model-view-controller" which never really applied to web applications (at least one of these was always missing) where the whole point of it (forgotten) was your routing system could display a different template depending on how the form got processed: if the form didn't validate you could redisplay the form with an error message, otherwise you could display another page. With that kind of system you can load a 20k form when you need to load it and not load 20MB of Javascript.

            At the time this knowledge didn't really get codified and we missed many opportunities such as a sane <select> for HTML 5.

            Another "path not taken" would be a DSL for forms which today could be implemented like HTMX. This

            https://en.wikipedia.org/wiki/Wireless_Application_Protocol

            is long forgotten but had a much smarter language for complex forms than HTML ever had. I really do like the improvements to forms in HTML 5 but I think people would really benefit from a system for validation and conditional forms (like your tax forms) that is driven by rules. Maybe you could sell it today as a "no code" tool.