4 ms·

So we have gone back to the days of Java and WinForms where everything from the UI layout to styles to business logic was in the same damn language in the same

So we have gone back to the days of Java and WinForms where everything from the UI layout to styles to business logic was in the same damn language in the same damn file and many times in the same goddamn function. Why? Why in the world would you ever willingly want to go back to that? Has the JavaScript community collectively lost it's mind? Or has all that kool-aid gone to its head and everyone is under the impression that they can do no wrong? What happened to all that talk and bluster that Java and JavaScript are different? Even .Net and Java have moved away from that convention with XAML and JavaFX. Those who don't remember the past are condemned to repeat it. My only hope is that the JavaScript community comes to it's senses before it is too late and they take down a good language and platform because of their inability to look outside the bubble.

tracker1 8y ago
It's not quite the same... styling conventions can still be followed, inherited style structures can also be passed from a global theme, or higher order components. You get the added advantages of a more flexible configuration that more easily integrates with the rest of the application as a whole. When developing a website with mostly static or cms type content, it's fine to establish a common layout structure that targets css output like sass, less, pre/postcss etc. When developing an application with components, it's generally best for component styling to stay closer to the component. CIJ is simply an option that works very well with all the advantages of per-component styling. But over separate .scss files has the added advantage of easily injected runtime/configuration values. It's much harder to generate different global values for $primaryColor and related in scss for different deployment targets. More so if you want to swap out themes, or certain options via application configuration in the application.
- quantummkv 8y ago
  > inherited style structures can also be passed from a global theme, or higher order components. Correct me if I am wrong, but isn't this the whole point of Cascading Style Sheets? > It's much harder to generate different global values for $primaryColor and related in scss for different deployment targets. More so if you want to swap out themes, or certain options via application configuration in the application. Isn't this exact problem solved by custom css properties/css variables? Why recreate CSS in JavaScript with all of the compile-time and run-time overhead when you can write a small function to manipulate css variables?
  - tracker1 8y ago
    Okay, so you want a global setting for buttons... button {...} Now you have a component where there's a variation on the button... .foo button {...} Now you want all buttons to have that variation... button {...new...} Now you change button defaults... button {...new...} Oh crap, `.foo button` is broken.
  - tracker1 8y ago
    As to the last part... lets say there's an application default for $someVariable, a per-client optional override, an application configurable (runtime database) override, and a user-level override. Are you suggesting that I setup a complicated system to do SCSS generation across the source of the entire application at each one of those layers? (including runtime, on-demand). Sending JSON, and merging JSON is FAR easier.
- WorldMaker 8y ago
  > It's much harder to generate different global values for $primaryColor and related in scss for different deployment targets. Much harder? The tools are often one and the same. I use webpack to bundle my JS and CSS. Configuring a different SCSS entry point based on deployment target isn't strategically different from changing a JS entry point in webpack. If I'm using SCSS imports in my JS entry point (and configured the webpack loaders to do their magic for me), it's exactly the same effort. I've even got one project that injects its theming dynamically with a runtime import(…) and webpack just does its usual thing when bundling that dynamic import.
  - tracker1 8y ago
    with JS, I don't have to change the JS entry point, just set a different environment variable... I can also compose nested rules into one configuration set. I can also dynamically inject into that configuration at runtime via application/user control settings.
mynegation 8y ago
And as far as I am concerned that was goddamn great. No, not that these things were in the same file or function - there are ways to separate that, but I miss the days when I could do it all in one language with one tool chain instead of three. On a related note, that gave me the benefit of consistent styling that was more or less taken care of, with all platform-specific features like accessibility and keyboard shortcuts available.

tracker1 8y ago

It's not quite the same... styling conventions can still be followed, inherited style structures can also be passed from a global theme, or higher order components. You get the added advantages of a more flexible configuration that more easily integrates with the rest of the application as a whole. When developing a website with mostly static or cms type content, it's fine to establish a common layout structure that targets css output like sass, less, pre/postcss etc. When developing an application with components, it's generally best for component styling to stay closer to the component. CIJ is simply an option that works very well with all the advantages of per-component styling. But over separate .scss files has the added advantage of easily injected runtime/configuration values. It's much harder to generate different global values for $primaryColor and related in scss for different deployment targets. More so if you want to swap out themes, or certain options via application configuration in the application.

quantummkv 8y ago
> inherited style structures can also be passed from a global theme, or higher order components. Correct me if I am wrong, but isn't this the whole point of Cascading Style Sheets? > It's much harder to generate different global values for $primaryColor and related in scss for different deployment targets. More so if you want to swap out themes, or certain options via application configuration in the application. Isn't this exact problem solved by custom css properties/css variables? Why recreate CSS in JavaScript with all of the compile-time and run-time overhead when you can write a small function to manipulate css variables?
- tracker1 8y ago
  Okay, so you want a global setting for buttons... button {...} Now you have a component where there's a variation on the button... .foo button {...} Now you want all buttons to have that variation... button {...new...} Now you change button defaults... button {...new...} Oh crap, `.foo button` is broken.
- tracker1 8y ago
  As to the last part... lets say there's an application default for $someVariable, a per-client optional override, an application configurable (runtime database) override, and a user-level override. Are you suggesting that I setup a complicated system to do SCSS generation across the source of the entire application at each one of those layers? (including runtime, on-demand). Sending JSON, and merging JSON is FAR easier.
WorldMaker 8y ago
> It's much harder to generate different global values for $primaryColor and related in scss for different deployment targets. Much harder? The tools are often one and the same. I use webpack to bundle my JS and CSS. Configuring a different SCSS entry point based on deployment target isn't strategically different from changing a JS entry point in webpack. If I'm using SCSS imports in my JS entry point (and configured the webpack loaders to do their magic for me), it's exactly the same effort. I've even got one project that injects its theming dynamically with a runtime import(…) and webpack just does its usual thing when bundling that dynamic import.
- tracker1 8y ago
  with JS, I don't have to change the JS entry point, just set a different environment variable... I can also compose nested rules into one configuration set. I can also dynamically inject into that configuration at runtime via application/user control settings.

mynegation 8y ago

And as far as I am concerned that was goddamn great. No, not that these things were in the same file or function - there are ways to separate that, but I miss the days when I could do it all in one language with one tool chain instead of three. On a related note, that gave me the benefit of consistent styling that was more or less taken care of, with all platform-specific features like accessibility and keyboard shortcuts available.