Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Just add native support for Sass and call it a day.


SASS encourage developers to build long chains of selectors and it makes them brittle and non-reusable.


Yeah, it's easily abused and trivial errors of judgement create non-trivial problems later down the line.

IMO part of the problem is that nested LESS/SASS looks just enough like JSON to mislead inexperienced devs, who often try to treat the nested structure as an object, rather than thinking of it as a string-builder.

It invariably ends up creating huge swarths of pointless specificity and stylesheet bloat.


CSS offers plenty of ways to hang yourself without resorting to SASS. The people who are dangerous with SASS tend to already be just as dangerous with plain CSS, in my experience.

The additional options for self harm are well offset by the features.


"Just add native support for jQuery and call it a day" "Just add native support for React and call it a day"

We can do lots of amazing things in the ecosystem, but often we're working around missing primitives in the platform. Just "adding native support" for today's hottest library doesn't fix things properly. It's better to figure out what problem they were solving, and then fix that problem more directly.

(jQuery is largely solving "DOM APIs suck". We've fixed that a little bit, with things like query() (née querySelector(), which was an awkward first attempt at it) and fetch(), but are still struggling to work through browser dev apathy at things like event registration or creating elements.)

(Figuring out what problem, precisely, React is solving is exciting and interesting. It's non-obvious - it's not just "some DOM things are slow", as there's lots of DOM things both fast and slow, and you don't need a fancy (read:slow) tree-diffing algo to fix those. There's something fundamental going on that we might be able to do better - maybe it's more fully separating the "display thread" that contains DOM from the rest of your JS, and letting you do a lot of DOM-ish manipulation in threads other than the display thread. Maybe that means actually using an even more lightweight display abstraction, so you can cheaply spam out updates without having to do expensive diffing first. There's a lot of possibilities here.)


DOM APIs didn't suck too badly. They weren't great, but they were usable.

The problem was that every old browser had its own API and feature set. Jquery abstracted over all that, including bugs in specific versions of browsers and continually is updated to handle the case of a browser claiming to implement a feature but lying.

Really if all browsers had the same API and feature set, there'd be no need for jQuery as it is today; you'd have a very different library.


Among other problems (perf, etc.) you'd have the application/xhtml+xml problem all over again, this time in styles.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: