9 ms·

One of the most confusing things I find with web development (which I'm mostly new to, coming from a backend background) is that everyone seems entirely happy w

by SCdF 9y ago

One of the most confusing things I find with web development (which I'm mostly new to, coming from a backend background) is that everyone seems entirely happy with JS (or more accurately the DOM?) and CSS being giant mutable state buckets. I've worked in mostly backend software for a decade, and web dev is easily the hardest thing I've ever had to work on. CSS especially is a nightmare. It's near impossible in complex projects to work out if your change is going to change other things adversely. Not only do you have to know all usages of the CSS class (for example), but if it's a scoped class (.foo .bar) you have to know all instances in which is it scoped in this exact way. Because it's visual you're basically testing with your eyes, there is no "refactor to green" possible. In Javascript it seems normal to (at least in angular) push to global scope, and so it can be really unclear where values come from, or how they get set. I once tried to work out why a fancy ajaxed select box (rendered in JS / CSS, naturally) was firing its onblur event at the wrong time. There were at least three JS event handlers (from memory, jquery, angular and native) that could possibly have events against it. Everything is smushed together, and because it's about losing or gaining focus the observer effect comes into play, and… it's a nightmare. From memory I just gave up, and I presume that particular bug still exists today. Testing any of this stuff is also pretty nightmarish. Knowing the web I'm almost certainly behind the curve and there is new hotness out to solve this, but I've never much luck with automated browser testing. Things like Protractor tests are incredibly onerous to write, and inevitably end up as flakey slow messes that fail builds due to flake more often than they find issues. I imagine there are lots of ways to solve these sorts of things, but all I've read feel like variants and retellings of "do it right", which isn't really that helpful, because a) what is right?, and b) it's easy to slowly slip away from "right" without noticing.

mquander 9y ago
I don't think it's true that everyone seems happy with this. In the past 10 years culture has shifted dramatically towards encapsulating and minimizing JS state (modules, moving away from imperative jQuery code and toward MVC, React) and, to your other point, moderately towards more strict CSS organizational techniques (OOCSS, SMACSS, BEM). I agree that the culture by default was to program everything against a giant mutable state bucket and I'm not sure why that happened.
- ungzd 9y ago
  But the idea of React is to have central application-level global mutable state, instead of jQuery's lots of fragments of local state attached to DOM nodes ($(...).data) or kept in callback closures, CPS-style. IMHO, article does not explain in what cases it can be better to have a global mutable state (i.e. containing mutation in Redux) instead of lots of local mutable state.
  - setzer22 9y ago
    I think the single state object in React/Redux is more an implementation detail than anything. Using regular js variables would allow free mutation for everyone at any place, so a new "variable system" must be created by encapsulating all state in an object. You cannot avoid keeping state and mutating it, the point is to do so in a predictable and controlled way. It is not that relevant whether you refer to `state.value` or just `value` as long as you're able to keep track of all your mutation sources easily. Having a global object is just a way of conveniently do that in javascript.
ams6110 9y ago
Yes it's really quite amazing that browser development has gained the traction it has, considering what a terrible environment it is to work in. I think its a combination of a lot of devs never having done anything else, so they don't know better, and also that removing the friction of deploying and configuring native apps was worth all of that.
- antod 9y ago
  Definitely leaning towards the latter IMO. That stuff was a nightmare.
- rmrfrmrf 9y ago
  * lowest barrier to entry of any platform * View Source of anything * development tools that keep improving by the day * non-proprietary, open standards * completely sandboxed from host environment * runs anywhere * first-class GUI support The list goes on...
  - otakucode 9y ago
    Right... when was the last time you USED View Source on something done in JS and actually used on a production site? Sandboxing from the environment also has its upsides and its downsides. What people actually want applications to DO is deal with their information. And sandboxing the host means they lose any semblance of control over that data, leading to it getting monitored, mined, etc. And it doesn't solve any of the actual problems. It just changes the target while simultaneously making those targets SO much juicier. Want the personal info of 143 million Americans? Hack the web app of a credit company, no need to hunt down and break into 143 million different machines! And the users won't even know if the data was stolen unless a company volunteers the information! Sometimes they even do! I really, really have to wonder about "first-class GUI support". Prior to the web applications used standard UI controls. Because that makes sense and makes computers easy to use. The web brought 'every single UI is different', which is horrendous. And when you can manage to put together a UI with web tech, then it's trapped in the browser. Which actively goes out of its way to make it as difficult as possible to manage running several different things at once. I think the answer to the webs success boils down to delivering what users actually want. Despite all the other warts, its valuable enough to convince them to not care. They want to search for something they want, vaguely, and be using an application one second later. All other considerations be damned. They'll wrestle with confusing UIs that change all the time without warning. They'll accept not having a lick of control over their data. They'll deal with being aggressively advertised to and companies trying to hound them into subscriptions because the 'service' of working around the sandboxing by keeping their data together needs ongoing cash infusions when the user only wanted a single product they could use for long periods of time. Like if people who made hammers started making ones that would only work with nails gotten from the hammer manufacturer and they didn't permit you to get enough to last, requiring a subscription so they could sell the information about what kind of nails and how often you were using them to a nail company.
lomnakkus 9y ago
I don't think people are (were) actually happy with it: Hence the immutable/FRP-ish UIs of React and similar frameworks. Of course they still have to cope with the realities of web browsers so there's still some ugliness in there, but the awfulness is mostly contained. (Though, you're absolutely right about CSS. It works fine for global state. The only problem is that "components", i.e. small bits of UI, aren't global.)
_hardwaregeek 9y ago
For styling, I'd look into CSS in JS, specifically JSS. Not only are all selectors scoped, you can create functions that return the proper styling. Frankly I think web developers as a whole need to rethink CSS and/or any paradigm based on traditional CSS like SASS/SCSS. We shouldn't need messy global variables like classes and ids to change styling. Not to mention the usual arguments for CSS just don't make sense. CSS isn't decoupled, in fact the reliance on HTML classes and ids is extremely coupled. JSS can just be left in a separate file and imported wherever it needs to be used.
- pagnol 9y ago
  Thanks for mentioning JSS. I'd never come across it before but it looks very interesting.
  - octalmage 9y ago
    I'm currently using it in a pretty large project and it's been awesome. Having the CSS related to the component in the component is really nice (which is found in other frameworks). When refactoring you don't have to wonder what this class could be tied to since it's all right there. You also benefit from dead code elimination so unused CSS classes get removed.
- deleted 9y ago
  [deleted]
amiga-workbench 9y ago
Its difficult to get front-end developers to scope their CSS properly and separate UI components into non-conflicting separate modules. Without the insight of having ever kept a back-end applications various functions isolated and grouped logically they always just lump everything together. Define a grid system to handle rough layout, then hang your widgets inside each cell, if you have to use !important, ever, you have failed.
- archagon 9y ago
  Are there best practices for scoping CSS correctly? I seem to reinvent the wheel every time I make a new website.
  - rmrfrmrf 9y ago
    https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules takes care of it all for you.
  - k__ 9y ago
    BEM -> CSS modules -> CSS-in-JS https://twitter.com/markdalgleish/status/910281166128791553 https://twitter.com/markdalgleish/status/910281166128791553
nawitus 9y ago
> CSS especially is a nightmare. It's near impossible in complex projects to work out if your change is going to change other things adversely. This is solved with shadow DOM. > In Javascript it seems normal to (at least in angular) push to global scope, and so it can be really unclear where values come from, or how they get set. Well, nobody forces you to do it in JavaScript. I think newer frameworks (and culture around them) discourages this. > Testing any of this stuff is also pretty nightmarish. Knowing the web I'm almost certainly behind the curve and there is new hotness out to solve this, but I've never much luck with automated browser testing. Things like Protractor tests are incredibly onerous to write, and inevitably end up as flakey slow messes that fail builds due to flake more often than they find issues. I agree that testing the whole application is tricky, but testing components is easy enough these days.
- agency 9y ago
  > This is solved with shadow DOM. http://caniuse.com/#feat=shadowdom http://caniuse.com/#feat=shadowdom
  - nawitus 9y ago
    You can use a polyfill.
otakucode 9y ago
Essentially every single aspect of the web is terrible. It was designed as a static document presentation system with hyperlinks. And for years and years and years, no matter how much interactivity was shoehorned into this system, the standards bodies absolutely refused to make any design decisions based on the absurd notion that it was an application platform. They have only changed this view very recently, and the consequences of their decisions made to optimize the creation of static documents with hyperlinks will continue to be felt for a decade probably. Had the web been designed as a distributed application platform with HTML being a user interface layout language and such, things would have developed very differently. And because making it do anything interactive most often required misuse and abuse of the browser, it wasn't much pursued by bona fide software engineers who knew the pitfalls of ad hoc 'organic' development and 'just keep typing until something works' mindsets. So, that's what we got. Big ball of global mutable state, scripting languages designed to make it so you could have a button light up when the mouse hovered over it bent over and made to do real work, dependency webs so complex that they're generating novel unsolved problems for graph theorists at every turn, etc. All of this because users want to be able to search vaguely for what they want and be using an application a moment later. Something that could be solved a trillion different ways but nobody realized at the time that it is what people really wanted. So now we oh-so-slowly move towards the web becoming an actual application platform, but hamstrung by companies that feel entitled to every data point we ever generate so they seek to insert latency into even the simplest interactions by requiring asking their machines for permission.
- adrianN 9y ago
  Had the web been designed that way it probably would have died an early death. Back then we didn't have gigabytes of RAM, fat pipes, and an abundance of cores to run interpreted code that is shipped from hundreds of kilometers away.
BurningFrog 9y ago
You're mostly right. Just know that things are fantastically much better than 10 years ago!
unoti 9y ago
> One of the most confusing things I find with web development (which I'm mostly new to, coming from a backend background) is that everyone seems entirely happy with JS (or more accurately the DOM?) and CSS being giant mutable state buckets. Actually, as you guessed, lots of people in the modern web community are unhappy with the mess of mutable state, and have done something about it! Redux [1] is all about using immutable state to tame the mess into a simple model involving application state expressed as an immutable object, the ui produces events, which get piped through a reducer, yielding a new state. If you skim over the "redux motivation" link below you'll see it talks all about the issues you're raising. There are tons of variants of this theme, including NGRX which is the same concept applied to Angular 2. [2] > CSS especially is a nightmare. It's near impossible in complex projects to work out if your change is going to change other things adversely... I feel your pain, and have struggled with this endlessly in the past. However, this is a mostly a well-solved problem in modern environments. For example in Angular 2, the css is automatically scoped for you down to the component level in a sane way[3]. Try React with Redux, or Angular2 with NGRX and see if it solves the issues you're concerned with. It's enough different options to make your head spin, I know. Just try out Angular 2 or Redux and see what you think. [1] http://redux.js.org/docs/introduction/Motivation.html http://redux.js.org/docs/introduction/Motivation.html [2] http://onehungrymind.com/build-better-angular-2-application-redux-ngrx/ http://onehungrymind.com/build-better-angular-2-application-... [3] http://blog.ng-book.com/css-isolation-in-angular-2-components/ http://blog.ng-book.com/css-isolation-in-angular-2-component...
seanwilson 9y ago
> One of the most confusing things I find with web development (which I'm mostly new to, coming from a backend background) is that everyone seems entirely happy with JS (or more accurately the DOM?) and CSS being giant mutable state buckets. Why is it surprising that people are working within the constraints of what is practical right now? What are you going to use instead that is so much better? If you want to do web development, you have to use CSS and JavaScript in some form. Just with backend work, there are good and bad ways of doing frontend coding.
lewisl9029 9y ago
It's unfortunate that mutable global state is the default approach to web development, but it's certainly not true that everybody is happy with it. We're actually in a golden age of web development right now driven mostly by functional approaches to web development that adhere to the principles of minimizing global state, sensibly managing what global state is necessary by means of treating it effectively as an immutable collection, and defaulting to pure functions where-ever possible and limiting in-place mutation to hot code paths, while still being mindful of containing those side-effects to within lower-level function boundaries. On the JS side, we have projects like Redux that effectively forbid direct mutation of global state by a pattern of describing state mutations using data (Actions), and handling those mutation descriptions in pure functions that take existing state, along with the aforementioned state change descriptions, and return the expected next state without any observable side effects (Reducers). This approach leads to a codebase that is simple to test and to reason about, and enables certain development and debugging workflows that would not be possible otherwise, such as component-level, state-preserving hot-reloading, server-side state hydration and pre-rendering, and time-travelling debugging (See Redux Devtools). The popularity of Redux in production React apps today is a testament to how well this approach scales in terms of app complexity and team size. In terms of CSS, definitely take a look at styled-components and Glamorous. They are AFAIK the state of the art in component-oriented CSS libraries, and can do anything you can in standard CSS (media-queries, pseudo-selectors, etc), unlike earlier CSS in JS libraries that come with all sorts of tradeoffs and limitations. The major win you get with these libraries is that styles are locally scoped by default and do not extend past component boundaries, so you can ensure each component is solely responsible for styling everything within their own borders, and will be styled consistently regardless of the surrounding context. The global-by-default, specificity-based-overriding, and recklessly-cascading aspects of CSS have long been considered harmful in component oriented architectures (rightfully so, in my experience), and tools like these allow you to opt-out of those properties by default, while still allowing you the opportunity to apply them mindfully and sparingly only when they happen to be the right tools for the job. Also, with Glamorous, which uses JS objects to represent CSS rules, you can programmatically manipulate your styles with everything in JavaScript available at your disposal (no more struggling with crappy DSLs like SCSS and LESS), and can make use of JS variables and modules to enable style reuse and take advantage of Webpack tree shaking to ensure only used CSS rules are included in your final bundle.
pdfernhout 9y ago
Check out Tachyons and similar CSS libraries which use CSS classes to essentially define inline styles efficiently. When you are making components, this can work out well in containing potential interactions of CSS. http://tachyons.io/ http://tachyons.io/ Combined with a lightweight vdom library like Mithril.js using the HyperScript API and maintaining state in plain old JavaScript objects (updating on any user interaction, network events, timers, or some few other events), this makes web single-page application development quite pleasant and scalable. You can also test much of such vdom-based UIs without creating real DOM nodes. https://mithril.js.org/ https://mithril.js.org/ Here is one example FOSS project I wrote in that style: https://github.com/pdfernhout/Twirlip7 https://github.com/pdfernhout/Twirlip7 Of course, few web developers grok this yet because most affirm "best practices" from years ago (e.g. semantic CSS, HTML-first design, JavaScript as a progressive afterthought) -- and also are used to coding in non-standard HTML-ish templating systems (e.g. Angular, Vue, JSX) which give them a false sense of security they can maintain more complex apps that are mostly about JavaScript. React has helped a lot of developers begin to move past some of that, but it has its own licensing issues and also baggage (including JSX) from being only half-way to the new paradigm outlined above.

by SCdF 9y ago

mquander 9y ago

I don't think it's true that everyone seems happy with this. In the past 10 years culture has shifted dramatically towards encapsulating and minimizing JS state (modules, moving away from imperative jQuery code and toward MVC, React) and, to your other point, moderately towards more strict CSS organizational techniques (OOCSS, SMACSS, BEM). I agree that the culture by default was to program everything against a giant mutable state bucket and I'm not sure why that happened.

ungzd 9y ago
But the idea of React is to have central application-level global mutable state, instead of jQuery's lots of fragments of local state attached to DOM nodes ($(...).data) or kept in callback closures, CPS-style. IMHO, article does not explain in what cases it can be better to have a global mutable state (i.e. containing mutation in Redux) instead of lots of local mutable state.
- setzer22 9y ago
  I think the single state object in React/Redux is more an implementation detail than anything. Using regular js variables would allow free mutation for everyone at any place, so a new "variable system" must be created by encapsulating all state in an object. You cannot avoid keeping state and mutating it, the point is to do so in a predictable and controlled way. It is not that relevant whether you refer to `state.value` or just `value` as long as you're able to keep track of all your mutation sources easily. Having a global object is just a way of conveniently do that in javascript.

ams6110 9y ago

Yes it's really quite amazing that browser development has gained the traction it has, considering what a terrible environment it is to work in. I think its a combination of a lot of devs never having done anything else, so they don't know better, and also that removing the friction of deploying and configuring native apps was worth all of that.

antod 9y ago
Definitely leaning towards the latter IMO. That stuff was a nightmare.
rmrfrmrf 9y ago
* lowest barrier to entry of any platform * View Source of anything * development tools that keep improving by the day * non-proprietary, open standards * completely sandboxed from host environment * runs anywhere * first-class GUI support The list goes on...
- otakucode 9y ago
  Right... when was the last time you USED View Source on something done in JS and actually used on a production site? Sandboxing from the environment also has its upsides and its downsides. What people actually want applications to DO is deal with their information. And sandboxing the host means they lose any semblance of control over that data, leading to it getting monitored, mined, etc. And it doesn't solve any of the actual problems. It just changes the target while simultaneously making those targets SO much juicier. Want the personal info of 143 million Americans? Hack the web app of a credit company, no need to hunt down and break into 143 million different machines! And the users won't even know if the data was stolen unless a company volunteers the information! Sometimes they even do! I really, really have to wonder about "first-class GUI support". Prior to the web applications used standard UI controls. Because that makes sense and makes computers easy to use. The web brought 'every single UI is different', which is horrendous. And when you can manage to put together a UI with web tech, then it's trapped in the browser. Which actively goes out of its way to make it as difficult as possible to manage running several different things at once. I think the answer to the webs success boils down to delivering what users actually want. Despite all the other warts, its valuable enough to convince them to not care. They want to search for something they want, vaguely, and be using an application one second later. All other considerations be damned. They'll wrestle with confusing UIs that change all the time without warning. They'll accept not having a lick of control over their data. They'll deal with being aggressively advertised to and companies trying to hound them into subscriptions because the 'service' of working around the sandboxing by keeping their data together needs ongoing cash infusions when the user only wanted a single product they could use for long periods of time. Like if people who made hammers started making ones that would only work with nails gotten from the hammer manufacturer and they didn't permit you to get enough to last, requiring a subscription so they could sell the information about what kind of nails and how often you were using them to a nail company.

lomnakkus 9y ago

I don't think people are (were) actually happy with it: Hence the immutable/FRP-ish UIs of React and similar frameworks. Of course they still have to cope with the realities of web browsers so there's still some ugliness in there, but the awfulness is mostly contained. (Though, you're absolutely right about CSS. It works fine for global state. The only problem is that "components", i.e. small bits of UI, aren't global.)

_hardwaregeek 9y ago

For styling, I'd look into CSS in JS, specifically JSS. Not only are all selectors scoped, you can create functions that return the proper styling. Frankly I think web developers as a whole need to rethink CSS and/or any paradigm based on traditional CSS like SASS/SCSS. We shouldn't need messy global variables like classes and ids to change styling. Not to mention the usual arguments for CSS just don't make sense. CSS isn't decoupled, in fact the reliance on HTML classes and ids is extremely coupled. JSS can just be left in a separate file and imported wherever it needs to be used.

pagnol 9y ago
Thanks for mentioning JSS. I'd never come across it before but it looks very interesting.
- octalmage 9y ago
  I'm currently using it in a pretty large project and it's been awesome. Having the CSS related to the component in the component is really nice (which is found in other frameworks). When refactoring you don't have to wonder what this class could be tied to since it's all right there. You also benefit from dead code elimination so unused CSS classes get removed.
deleted 9y ago
[deleted]

amiga-workbench 9y ago

Its difficult to get front-end developers to scope their CSS properly and separate UI components into non-conflicting separate modules. Without the insight of having ever kept a back-end applications various functions isolated and grouped logically they always just lump everything together. Define a grid system to handle rough layout, then hang your widgets inside each cell, if you have to use !important, ever, you have failed.

archagon 9y ago
Are there best practices for scoping CSS correctly? I seem to reinvent the wheel every time I make a new website.
- rmrfrmrf 9y ago
  https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules takes care of it all for you.
- k__ 9y ago
  BEM -> CSS modules -> CSS-in-JS https://twitter.com/markdalgleish/status/910281166128791553 https://twitter.com/markdalgleish/status/910281166128791553

nawitus 9y ago

> CSS especially is a nightmare. It's near impossible in complex projects to work out if your change is going to change other things adversely. This is solved with shadow DOM. > In Javascript it seems normal to (at least in angular) push to global scope, and so it can be really unclear where values come from, or how they get set. Well, nobody forces you to do it in JavaScript. I think newer frameworks (and culture around them) discourages this. > Testing any of this stuff is also pretty nightmarish. Knowing the web I'm almost certainly behind the curve and there is new hotness out to solve this, but I've never much luck with automated browser testing. Things like Protractor tests are incredibly onerous to write, and inevitably end up as flakey slow messes that fail builds due to flake more often than they find issues. I agree that testing the whole application is tricky, but testing components is easy enough these days.

agency 9y ago
> This is solved with shadow DOM. http://caniuse.com/#feat=shadowdom http://caniuse.com/#feat=shadowdom
- nawitus 9y ago
  You can use a polyfill.

otakucode 9y ago

Essentially every single aspect of the web is terrible. It was designed as a static document presentation system with hyperlinks. And for years and years and years, no matter how much interactivity was shoehorned into this system, the standards bodies absolutely refused to make any design decisions based on the absurd notion that it was an application platform. They have only changed this view very recently, and the consequences of their decisions made to optimize the creation of static documents with hyperlinks will continue to be felt for a decade probably. Had the web been designed as a distributed application platform with HTML being a user interface layout language and such, things would have developed very differently. And because making it do anything interactive most often required misuse and abuse of the browser, it wasn't much pursued by bona fide software engineers who knew the pitfalls of ad hoc 'organic' development and 'just keep typing until something works' mindsets. So, that's what we got. Big ball of global mutable state, scripting languages designed to make it so you could have a button light up when the mouse hovered over it bent over and made to do real work, dependency webs so complex that they're generating novel unsolved problems for graph theorists at every turn, etc. All of this because users want to be able to search vaguely for what they want and be using an application a moment later. Something that could be solved a trillion different ways but nobody realized at the time that it is what people really wanted. So now we oh-so-slowly move towards the web becoming an actual application platform, but hamstrung by companies that feel entitled to every data point we ever generate so they seek to insert latency into even the simplest interactions by requiring asking their machines for permission.

adrianN 9y ago
Had the web been designed that way it probably would have died an early death. Back then we didn't have gigabytes of RAM, fat pipes, and an abundance of cores to run interpreted code that is shipped from hundreds of kilometers away.

BurningFrog 9y ago

You're mostly right. Just know that things are fantastically much better than 10 years ago!

unoti 9y ago

> One of the most confusing things I find with web development (which I'm mostly new to, coming from a backend background) is that everyone seems entirely happy with JS (or more accurately the DOM?) and CSS being giant mutable state buckets. Actually, as you guessed, lots of people in the modern web community are unhappy with the mess of mutable state, and have done something about it! Redux [1] is all about using immutable state to tame the mess into a simple model involving application state expressed as an immutable object, the ui produces events, which get piped through a reducer, yielding a new state. If you skim over the "redux motivation" link below you'll see it talks all about the issues you're raising. There are tons of variants of this theme, including NGRX which is the same concept applied to Angular 2. [2] > CSS especially is a nightmare. It's near impossible in complex projects to work out if your change is going to change other things adversely... I feel your pain, and have struggled with this endlessly in the past. However, this is a mostly a well-solved problem in modern environments. For example in Angular 2, the css is automatically scoped for you down to the component level in a sane way[3]. Try React with Redux, or Angular2 with NGRX and see if it solves the issues you're concerned with. It's enough different options to make your head spin, I know. Just try out Angular 2 or Redux and see what you think. [1] http://redux.js.org/docs/introduction/Motivation.html http://redux.js.org/docs/introduction/Motivation.html [2] http://onehungrymind.com/build-better-angular-2-application-redux-ngrx/ http://onehungrymind.com/build-better-angular-2-application-... [3] http://blog.ng-book.com/css-isolation-in-angular-2-components/ http://blog.ng-book.com/css-isolation-in-angular-2-component...

seanwilson 9y ago

> One of the most confusing things I find with web development (which I'm mostly new to, coming from a backend background) is that everyone seems entirely happy with JS (or more accurately the DOM?) and CSS being giant mutable state buckets. Why is it surprising that people are working within the constraints of what is practical right now? What are you going to use instead that is so much better? If you want to do web development, you have to use CSS and JavaScript in some form. Just with backend work, there are good and bad ways of doing frontend coding.

lewisl9029 9y ago

It's unfortunate that mutable global state is the default approach to web development, but it's certainly not true that everybody is happy with it. We're actually in a golden age of web development right now driven mostly by functional approaches to web development that adhere to the principles of minimizing global state, sensibly managing what global state is necessary by means of treating it effectively as an immutable collection, and defaulting to pure functions where-ever possible and limiting in-place mutation to hot code paths, while still being mindful of containing those side-effects to within lower-level function boundaries. On the JS side, we have projects like Redux that effectively forbid direct mutation of global state by a pattern of describing state mutations using data (Actions), and handling those mutation descriptions in pure functions that take existing state, along with the aforementioned state change descriptions, and return the expected next state without any observable side effects (Reducers). This approach leads to a codebase that is simple to test and to reason about, and enables certain development and debugging workflows that would not be possible otherwise, such as component-level, state-preserving hot-reloading, server-side state hydration and pre-rendering, and time-travelling debugging (See Redux Devtools). The popularity of Redux in production React apps today is a testament to how well this approach scales in terms of app complexity and team size. In terms of CSS, definitely take a look at styled-components and Glamorous. They are AFAIK the state of the art in component-oriented CSS libraries, and can do anything you can in standard CSS (media-queries, pseudo-selectors, etc), unlike earlier CSS in JS libraries that come with all sorts of tradeoffs and limitations. The major win you get with these libraries is that styles are locally scoped by default and do not extend past component boundaries, so you can ensure each component is solely responsible for styling everything within their own borders, and will be styled consistently regardless of the surrounding context. The global-by-default, specificity-based-overriding, and recklessly-cascading aspects of CSS have long been considered harmful in component oriented architectures (rightfully so, in my experience), and tools like these allow you to opt-out of those properties by default, while still allowing you the opportunity to apply them mindfully and sparingly only when they happen to be the right tools for the job. Also, with Glamorous, which uses JS objects to represent CSS rules, you can programmatically manipulate your styles with everything in JavaScript available at your disposal (no more struggling with crappy DSLs like SCSS and LESS), and can make use of JS variables and modules to enable style reuse and take advantage of Webpack tree shaking to ensure only used CSS rules are included in your final bundle.

pdfernhout 9y ago

Check out Tachyons and similar CSS libraries which use CSS classes to essentially define inline styles efficiently. When you are making components, this can work out well in containing potential interactions of CSS. http://tachyons.io/ http://tachyons.io/ Combined with a lightweight vdom library like Mithril.js using the HyperScript API and maintaining state in plain old JavaScript objects (updating on any user interaction, network events, timers, or some few other events), this makes web single-page application development quite pleasant and scalable. You can also test much of such vdom-based UIs without creating real DOM nodes. https://mithril.js.org/ https://mithril.js.org/ Here is one example FOSS project I wrote in that style: https://github.com/pdfernhout/Twirlip7 https://github.com/pdfernhout/Twirlip7 Of course, few web developers grok this yet because most affirm "best practices" from years ago (e.g. semantic CSS, HTML-first design, JavaScript as a progressive afterthought) -- and also are used to coding in non-standard HTML-ish templating systems (e.g. Angular, Vue, JSX) which give them a false sense of security they can maintain more complex apps that are mostly about JavaScript. React has helped a lot of developers begin to move past some of that, but it has its own licensing issues and also baggage (including JSX) from being only half-way to the new paradigm outlined above.