I feel like actually, a grand bulk of how “front-end” works now is interesting workarounds for browser limitations that don’t exist anymore.
but because change is expensive we just kinda kept using the elaborate workarounds despite not needing them
and because institutional memory can’t exist in an industry with a 5 year 95% turnover rate, most people don’t remember that we don’t need most of this shit anymore
there is also a component of the old embrace extend extinguish too. There has always been a low wail of people wanting to replace the open web with some proprietary product, and microsoft and facebook may have actually succeeded with typescript and react
like, take SPAs and AJAX as an example. the limitation was that when you clicked anything on a traditional webpage the whole screen would go blank while the next page’s html loads.
so our elaborate work around was to hold onto the html and css, just download and replace the content- smoother transition.
but you give up on the progressive renderer built into the browser, so it doesn’t scale well. and your js packages are so big now, you don’t notice browsers fixed the original problem
like, if you can get your page html and css small enough, usually by jettisoning those 5mb bundles of javascript… http2 and little browser rendering tweaks over the years; it is *seamless* now. the image of the page you’re on is held, until the next page finishes loading.. so long as it loads fast enough
but it won’t ever load fast enough because you gotta have your “fast” framework
build tools and bundling was working around the overhead of making multiple http requests; it’s “quicker” if you stick all the javascript into one file, then download all at once.
browser optimisations have rendered that original problem non existent now. but we’re still bundling because… we built too much ecosystem around having a build tool?
@zens im really new to web frontend (and frontend generally)
could you point me in the rught direction for this kinda stuff? do you mean like htmx? (surely there are even simpler methods?)
@aynish just ditching the javascript altogether and authoring plain html and css.
@aynish the assumption is that plain html and css is something that is broken and needs to be “fixed” with piles of javascript
it used to kind of be the case but isn’t anymore
you don’t need the frameworks. they were designed to work around mistakes that have been fixed in the browser
@aynish i also recently wrote about this very counterintuitive result
Yeah this is all too real, the "solution to problem caused by previous solution" pattern of tech. Its nice to get off the treadmill. For example if I make a small web app w/ preact and parcel, it will be like 7kb to 14kb unminified/uncompressed... But as soon as I wanna display a legible stacktrace to the user when an error occurs, I have install the 'sourcemapped-stacktrace' package and oops.. bundle.js is ~100kb now.
Theoretically possible to make it load that part after the page we care about loads, but now we're loading error handler separately and **after** everything else loads, and we need fallbacks, and, and, and, it never ends.
Idk if there is any ideal solution to this. Web dev is just hard.
