3 ms·

The scope of problems being solved is much higher. Adding a two or three libraries- jquery and a plugin or two- and not giving a toss about performance was inde

The scope of problems being solved is much higher. Adding a two or three libraries- jquery and a plugin or two- and not giving a toss about performance was indeed easy. Few auxiliary tools were required. Back then, we all could have a pretty strong hand on the wheel of our websites & how they functioned, at a detailed level. It was feasible, for the scope was small. But now, we all use package managers, we all use bundlers, we all use minifiers, we all use production builds, we all use tree shakers. Any one of these concerns is a significant realm that tends to have significant people-years worth of work poured into it. The need for these capabilities distances the practitioner from the core truth of the media: we no longer see clearly what we are doing, we no longer have personal stake or control in the processes. There's still a strong latent desire to re-simplify, to de-configure the web, to de-build it. We had hopes that EcmaScript Modules would help, we had hope HTTP2 Push would be a viable delivery platform, for un-tooling, but we never really made an earnest go at tackling the optimization problems that all brought in; works like Cache-Digest never de-facto materialized or got made-available. Front-end architecture similarly has been dominated by high-abstraction top-down frameworks, namely React, which complects in a wide host of assumptions/abstractions that distance the practitioner from the actual media-form. Just as ESM was a hope that we might get back to understandable, without lots of framework/tools, WebComponents too presents a hope that we can strip away a lot of the specific complexity & find a more inter-modular, general & understandable grounding. The web can & should be at a similar power level to where it is, more so, but in more honest, accessible, direct manners than the crafted-of-necessity deep layering we cobble with today.

kimi 4y ago
> and not giving a toss about performance was indeed easy. Few auxiliary tools were required. When the internet came through a modem and bandwidth was very expensive, performance was concern #1. So pages were kilobytes, not multi-megabyte monstruosities.
- Tade0 4y ago
  > When the internet came through a modem and bandwidth was very expensive, That effectively ended in the mid 00s. Otherwise we wouldn't have had services like YouTube. Between those times and around 2012 there was an explosion of script bloat because back then it was more important to have an interactive page than a fast page. Bandwidth resurfaced as a concern only with the proliferation of mobile devices. The whole premise of tree shaking, introduced in 2012 was to reduce bloat.
- rektide 4y ago
  which of the techniques that i listed that are common now dlwere possible then? we did indeed squeeze a lot out of the code we wrote. and we were very aware of js performance issues- using array.join religiously instead of concatenation was a big one. but most of the modern techniques & concerns simply werent appplicable or possible. the shift from writing it ourselves to loading dozens or hundreds of modules came quite late, all told. that lead to the explosion of performance tools & techniques.

kimi 4y ago

> and not giving a toss about performance was indeed easy. Few auxiliary tools were required. When the internet came through a modem and bandwidth was very expensive, performance was concern #1. So pages were kilobytes, not multi-megabyte monstruosities.

Tade0 4y ago
> When the internet came through a modem and bandwidth was very expensive, That effectively ended in the mid 00s. Otherwise we wouldn't have had services like YouTube. Between those times and around 2012 there was an explosion of script bloat because back then it was more important to have an interactive page than a fast page. Bandwidth resurfaced as a concern only with the proliferation of mobile devices. The whole premise of tree shaking, introduced in 2012 was to reduce bloat.
rektide 4y ago
which of the techniques that i listed that are common now dlwere possible then? we did indeed squeeze a lot out of the code we wrote. and we were very aware of js performance issues- using array.join religiously instead of concatenation was a big one. but most of the modern techniques & concerns simply werent appplicable or possible. the shift from writing it ourselves to loading dozens or hundreds of modules came quite late, all told. that lead to the explosion of performance tools & techniques.