5 ms·

Legacy bootstrap did ship with considerably fat set of dependencies - jQuery, popper, etc. Compare that to Bulma or something more modern, it ships without thes

Legacy bootstrap did ship with considerably fat set of dependencies - jQuery, popper, etc. Compare that to Bulma or something more modern, it ships without these dependencies. When the world is moving towards css-in-js and other aggressive ways of trimming unwanted code, removing dependencies is a good move by Bootstrap

mythrwy 8y ago
Only part of the world is moving to css-in-js. I won't be on the boat leaving for that destination.
- GordonS 8y ago
  Completely agree - I find the current trend (and that's what I see it as) of css-in-js to be most disagreeable. CSS works fine without JS, or even better with SASS/LESS.
  - JustSomeNobody 8y ago
    I both love it and hate it. I love it because a lot of the supporters, on the inside, hate it too. They've spent the last decade saying, ya gotta keep 'em separated. Now they have to say no, it is fine to mix 'em. And it's killing them to say it, but they need jobs, so they follow the herd. But, yeah, other than that, it's a stupid idea.
- pault 8y ago
  CSS in JS isn't CSS. It's just SS. It ignores the best part of the language; the cascade.
  - deleted 8y ago
    [deleted]
  - charrondev 8y ago
    Or the worst from my point of view. CSS rots more than any other code in a front end codebase and the methods for static analysis are incredibly limited. Refactoring and static analysis tools are incredibly limited or nonexistent for plain CSS or SCSS (when talking about the barriers between HTML and the stylesheet). We do all of our new views and stylesheets using React, TypeScript, and Typestyle. As a result we can expose much controlled methods of theming and have a compiler enforced link between variables, selectors, and their usages. We can refactor easily. We can catch simple typos at compile time instead of runtime, and validate them more easily in CI.
    - pault 8y ago
      > have a compiler enforced link between variables, selectors, and their usages. That sounds interesting. Can you describe that in more detail?
  - rmrfrmrf 8y ago
    1) it doesnt ignore it 2) anyone claiming not to have a single `style=""` attribute (which is almost as specific and 1000x less maintainable) in their code is lying
    - pault 8y ago
      I will swear on my life that I haven't used a style attribute in the last five years. Since I started using BEM for namespacing I have had a very easy time keeping my CSS clean and maintainable. I won't deny others their opinions, though.
      - chrisweekly 8y ago
        BEM is a decent convention for old-school, global document styling, in the absence of scope. But it's also manual, error-prone, and verbose, making it a poor substitute for actual namespacing provided by components. I sympathize with your resistance to css-in-js; I've been doing webdev since 1998 and only really embraced it in the last couple years. I'm reminded of quotes like "The difficulty lies not so much in new ideas, but in escaping the old."
        pault 8y ago
        Fair enough. I felt the same way about JSX when it came out so maybe I need to give it another look. :)
      - mercer 8y ago
        I think BEM was the point where I decided to give up and accept CSS in my JS.
  - chrisweekly 8y ago
    The cascade was great for HTML in the absence of scope, which is to say in the age of documents. It's a reasonable approach to dealing with all the problems inherent in managing global state. But globals suck. In the age of components it makes little sense to cling to the cascade as if it were more than a means to an end.
- frosted-flakes 8y ago
  Is CSS Modules considered to be "CSS-in-JS"? It does require JavaScript to import the class names, but the stylesheet itself is static. I personally find it to be a great solution to the scoping problem, and combined with Sass it's very flexible. Even theming is a cinch with a single shared Sass file with theming variables, or CSS custom properties. Every CSS-in-JS library I've tried makes everything way too cumbersome with no real upside. I especially hate how they all spread my style declarations all over the place.
  - mercer 8y ago
    I can't answer your question, but after a lot of experimenting and reading I ended up with styled-components as my preferred solution if I were to go the SPA way. It allows you to write your CSS inside the backtick js strings (template literals?) and then inserts/removes the relevant CSS as components are loaded/unloaded. Personally I've gone in an entirely different direction (server-side everything, and simply diffing the HTML on the client when necessary), but if I were to build a proper front-end app, I'd probably go for styled-components. The main downside is that the stuff needed to parse the css-in-js-string is yet another thing that increases payload size, but for an app it's not too bad.

mythrwy 8y ago

Only part of the world is moving to css-in-js. I won't be on the boat leaving for that destination.

GordonS 8y ago
Completely agree - I find the current trend (and that's what I see it as) of css-in-js to be most disagreeable. CSS works fine without JS, or even better with SASS/LESS.
- JustSomeNobody 8y ago
  I both love it and hate it. I love it because a lot of the supporters, on the inside, hate it too. They've spent the last decade saying, ya gotta keep 'em separated. Now they have to say no, it is fine to mix 'em. And it's killing them to say it, but they need jobs, so they follow the herd. But, yeah, other than that, it's a stupid idea.
pault 8y ago
CSS in JS isn't CSS. It's just SS. It ignores the best part of the language; the cascade.
- deleted 8y ago
  [deleted]
- charrondev 8y ago
  Or the worst from my point of view. CSS rots more than any other code in a front end codebase and the methods for static analysis are incredibly limited. Refactoring and static analysis tools are incredibly limited or nonexistent for plain CSS or SCSS (when talking about the barriers between HTML and the stylesheet). We do all of our new views and stylesheets using React, TypeScript, and Typestyle. As a result we can expose much controlled methods of theming and have a compiler enforced link between variables, selectors, and their usages. We can refactor easily. We can catch simple typos at compile time instead of runtime, and validate them more easily in CI.
  - pault 8y ago
    > have a compiler enforced link between variables, selectors, and their usages. That sounds interesting. Can you describe that in more detail?
- rmrfrmrf 8y ago
  1) it doesnt ignore it 2) anyone claiming not to have a single `style=""` attribute (which is almost as specific and 1000x less maintainable) in their code is lying
  - pault 8y ago
    I will swear on my life that I haven't used a style attribute in the last five years. Since I started using BEM for namespacing I have had a very easy time keeping my CSS clean and maintainable. I won't deny others their opinions, though.
    - chrisweekly 8y ago
      BEM is a decent convention for old-school, global document styling, in the absence of scope. But it's also manual, error-prone, and verbose, making it a poor substitute for actual namespacing provided by components. I sympathize with your resistance to css-in-js; I've been doing webdev since 1998 and only really embraced it in the last couple years. I'm reminded of quotes like "The difficulty lies not so much in new ideas, but in escaping the old."
      - pault 8y ago
        Fair enough. I felt the same way about JSX when it came out so maybe I need to give it another look. :)
    - mercer 8y ago
      I think BEM was the point where I decided to give up and accept CSS in my JS.
- chrisweekly 8y ago
  The cascade was great for HTML in the absence of scope, which is to say in the age of documents. It's a reasonable approach to dealing with all the problems inherent in managing global state. But globals suck. In the age of components it makes little sense to cling to the cascade as if it were more than a means to an end.
frosted-flakes 8y ago
Is CSS Modules considered to be "CSS-in-JS"? It does require JavaScript to import the class names, but the stylesheet itself is static. I personally find it to be a great solution to the scoping problem, and combined with Sass it's very flexible. Even theming is a cinch with a single shared Sass file with theming variables, or CSS custom properties. Every CSS-in-JS library I've tried makes everything way too cumbersome with no real upside. I especially hate how they all spread my style declarations all over the place.
- mercer 8y ago
  I can't answer your question, but after a lot of experimenting and reading I ended up with styled-components as my preferred solution if I were to go the SPA way. It allows you to write your CSS inside the backtick js strings (template literals?) and then inserts/removes the relevant CSS as components are loaded/unloaded. Personally I've gone in an entirely different direction (server-side everything, and simply diffing the HTML on the client when necessary), but if I were to build a proper front-end app, I'd probably go for styled-components. The main downside is that the stuff needed to parse the css-in-js-string is yet another thing that increases payload size, but for an app it's not too bad.