5 ms·

Html is a language. CSS is a language. JavaScript is a language. You can build the Dom by loading html, and you can build the Dom by making calls from JS. You c

Html is a language. CSS is a language. JavaScript is a language. You can build the Dom by loading html, and you can build the Dom by making calls from JS. You can write style rules against a selector using CSS, or you can write some declarative JS that looks almost the same but with more commas and fewer semicolons. Going back to the good-old-days isn't going to save you since the language is incidental. Anyone who puts up their first Gatsby site is going to be amazed by how fast the performance feels. They certainly won't be wishing they'd burned their JS stickers. My biggest problem with the article is that it ignores the cost of "putting users before devs". Writing the simplest, most performant iteration of a site that matches the minimum requirements as you perceive them for today's users isn't that expensive. But that approach crumbled quickly as parameters change slightly. You're one bad focus group or new CEO away from needing to completely rebuild from scratch, except you'll probably need to keep maintaining the old site forever. Then the new site when it becomes the new old site. Then the next one. Repeat until your increasingly-expensive business is completely unviable.

TheOtherHobbes 7y ago
CSS is a dystopian nightmare from a Lovecraftian dimension of metaphysical horror. I had to do a teeny-tiny bit of CSS work before Christmas and I literally had to look up the edge cases and exceptions for all of the five common CSS statements I ended up using, because they were all context-dependent in insane ways - endless "This only works if XXXX is also applied here, but does nothing/fails silently if it isn't, even though you might expect it to work, and this mode is only documented on StackExchange etc because the official CSS docs are incomprehensible and no one ever reads them anyway. And by the way, you'll also need a file of resets for many of the most common options." https://www.w3.org/Style/CSS/current-work https://www.w3.org/Style/CSS/current-work
- jkoudys 7y ago
  Well... yeah. I'm much happier using some css-in-ts solution, because then I can use stricter types against what I define. No need to track down why my `background-colour` isn't doing anything somewhere, or setting up some separate tool to validate it. While we're looking at cultural problems, this view of style-work as somehow being easier/lighter/less-important/etc. vs the "real" code is at the root of so many of these problems. It's very fashionable to praise functional programming and all the virtues of being declarative, yet we can't connect that with good practices for style.
ericb 7y ago
> Writing the simplest, most performant iteration of a site that matches the minimum requirements as you perceive them for today's users isn't that expensive. But that approach crumbled quickly as parameters change slightly. Maintaining two apps (front end and back) instead of one--that seems like an approach whose affordability crumbles more quickly when change is needed to me.

TheOtherHobbes 7y ago

CSS is a dystopian nightmare from a Lovecraftian dimension of metaphysical horror. I had to do a teeny-tiny bit of CSS work before Christmas and I literally had to look up the edge cases and exceptions for all of the five common CSS statements I ended up using, because they were all context-dependent in insane ways - endless "This only works if XXXX is also applied here, but does nothing/fails silently if it isn't, even though you might expect it to work, and this mode is only documented on StackExchange etc because the official CSS docs are incomprehensible and no one ever reads them anyway. And by the way, you'll also need a file of resets for many of the most common options." https://www.w3.org/Style/CSS/current-work https://www.w3.org/Style/CSS/current-work

jkoudys 7y ago
Well... yeah. I'm much happier using some css-in-ts solution, because then I can use stricter types against what I define. No need to track down why my `background-colour` isn't doing anything somewhere, or setting up some separate tool to validate it. While we're looking at cultural problems, this view of style-work as somehow being easier/lighter/less-important/etc. vs the "real" code is at the root of so many of these problems. It's very fashionable to praise functional programming and all the virtues of being declarative, yet we can't connect that with good practices for style.

ericb 7y ago

> Writing the simplest, most performant iteration of a site that matches the minimum requirements as you perceive them for today's users isn't that expensive. But that approach crumbled quickly as parameters change slightly. Maintaining two apps (front end and back) instead of one--that seems like an approach whose affordability crumbles more quickly when change is needed to me.