I'll just comment on the stanforddaily website how clean it looked and loaded fast even without any crap like AMP. Just compare it to the current site.
We went the other route.
http://web.archive.org/web/20041010133026cs_/http://www.stan...
I like this idea, but I wonder how long it would take my brain to think like this.
I feel like new people keep entering the web field and forgetting all the lessons learned from the (very very recent) past.
The inline approach might work for a small site. But in that case, why use a pre-processor at all and why would you need config objects?
CSS doesn't need to be rocket science. If you want atomic CSS then leverage CSS and style the base elements, it's actually pretty good at what it does.
Edit: I may have misinterpreted it's use case, I am all for compenent based styles. I still think there is no need for a pre-processor of inline styles with a completely new lexicon. If you are already in the context of a component you already have the beauty of a scoped and simplified CSS workspace, why make that so much more complicated with a new build pipeline and completely new syntax and lexicon?
The entry barrier for web technologies is just rather low. This is probably the main reason for Node's huge growth in the past years: It's just the path of least resistance to get into back end development.
There _are_ people who are good at both visual design and computer science, but not as many as designers who learned enough to code what they needed to.
Putting styles needed to render your above the fold content inside <head> is a sensible thing to do, assuming you've been able to restrain yourself by not animating the buggery out of everything, and have kept your stylesheet small. It saves a roundtrip to the server or CDN that will block your content from rendering.
Putting all your styles inline? Sheer madness. Inventing your own syntax to do it? Even worse. The whole thing with CSS is, used well, it does actually reduce page weight vs. old skool HTML table and element based styling. You lose all that if you start bunging all your styles inline.
Still, I suppose if your page is already 4 #@<£ing megabytes because of all the crap you've cargo-culted in, maybe it doesn't matter so much. </snark>
> No megabytes of css
Why would there ever be megabytes of CSS for such a site, apart from for ads, which is the main problem with modern 'content sites'.
> no bootstrap
Bootstrap can be tiny, and a big win in productivity/quality, so 'no Bootstrap' likely cost the devs in its lack of availabilty at the time. It looks far worse and is less usable on mobile particularly (but on desktop too) than it would be if built with Bootstrap.
> No webpack with plethora of dependencies to load, parse and execute.
Why is that even relevant? Who exactly is advocating for 'webpack with plethora of dependencies' for that kind of website?
It's an industry wide issue that we keep trying to solve using shitty duct-tape and hacks, while not addressing the underlying problem.
This is just a reaction to that (and one that I agree with)
Edit:
> Why would there ever be megabytes of CSS for such a site, apart from for ads, which is the main problem with modern 'content sites'.
Dunno, but people keep doing it for some reason
> Bootstrap can be tiny, and a big win in productivity/quality, so 'no Bootstrap' likely cost the devs in its lack of availability at the time. It looks far worse and is less usable on mobile particularly (but on desktop too) than it would be if built with Bootstrap.
Bootstrap can be, but IME it typically isn't. Additionally, I constantly hear webdevs say it "makes mobile better", but I tend to disagree. I admit that this is purely opinion.
> Who exactly is advocating for 'webpack with plethora of dependencies' for that kind of website?
Pretty much every webdev I talk to. Admittedly not necessarily webpack but usually something similar.
I do understand that good tools being misused aren't bad tools, but, as a user, you can't expect me to be happy when I see those or similar tools when most of your industry is abusing them.
Bootstrap, a theme for it, app css, a couple of 3rd party vendors, and we are over a megabyte.
> a big win in productivity/quality
Only if you are doing an SPA which mimics desktop applications. Which journalism sites are usually not
>Why is that relevant for such a site? Who exactly is advocating for a 'plethora of dependencies' for that kind of website?
Well no one, but sites still do this in the wild, while being driven by business decisions rather than technical concerns, which is understable surely, but look how nostalgic people are getting.
Who's doing that? And if they are adding dependencies without consideration of page-speed, they're to blame, and they'll never understand performance.
Bootstrap is not the problem. Hypothetical bad devs would have been making similar mistakes with flash prior to that, or whatever alternative CSS libs were available, and were being cobbled together piecemeal prior to Bootstrap.
> a big win in productivity/quality
>> Only if you are doing an SPA which mimics desktop applications. Which journalism sites are usually not
That is false. Bootstrap's primary use-case is as a CSS framework, not something solely for SPAs. From the early days it solved cross browser issues even for supposedly simple things like 'forms' for which there were no well-established conventions beforehand. Go trawl through the BS1 & 2 issue threads around form elements, and see all the things they fixed.
> Why is that relevant for such a site? Who exactly is advocating for a 'plethora of dependencies' for that kind of website?
>> Well no one, but sites still do this in the wild [...]
So those tools don't deserve the abuse/noise.
> Who's doing that?
You either don't use the web since 2008 or something or are lying: nearly all websites start with this setup.
To be fair, there really wasn't any "mobile" to speak of back then, so the developers couldn't even try to make it look good on mobile.
I feel like while they were inspired by some concepts from there, the biggest contributor to the idea (apart from the need of locking in people in one 'easily acessible' platform) was opera's OBML format/protocol which was really decent at the time and provided a lot of benefits AML is marketed for. Probably the only problem with it was the lack of any interactive javascript, and that where it failed to meet adoption. Oh, but well, it was really niche as well, that did nothing good too.
Sure, but it oftentimes isn't