CSS-In-JS and Static Rendering | Hacker News Reader

CSS-In-JS and Static Rendering

frontarm.com

47 pointsjamesknelson19 comments

I recently tried to use a popular UI combo (React + Material UI) and wanted to use static CSS. Just good ol' regular CSS files included in the HTML head. This so I could host my frontend on a static webserver (AKA a CDN) and use Content-Security-Policy.

I had to jump deep in a rabbit hole of build systems that no-one seems to understand and a dependency hell that I haven't experienced since my Python days. Any Github/Stackoverflow post I could find on the subject was already obsolete.

The 'advise' most devs gave would boil down to disabling CSP by allowing unsafe-inline, or serving the index.html through a NodeJS server and injecting CSP nonces through a templating system. Both are not solutions, but workarounds to a problem that shouldn't exist.

Once again, I had to conclude that the modern webdev frameworks are not mature enough to use for any serious work. I'll try again in 2020.

I think your issue might be specifically with the material UI library which might not be designed to work with static CSS.

Personallly I find these UI libraries are more trouble than they're worth. React itself is perfectly happy to work that way.

Try https://parceljs.org/

> modern webdev frameworks are not mature enough

How much time have you invested? I know it can be very confusing given the variety of alternatives, but there are pretty sweet tools out there.

> How much time have you invested?

I usually invest about a month full-time, get more and more frustrated and eventually hire someone else to do it for me.

Just about every year I think that 'by now they should have worked out most problems', so I'll try again. Each year I have to completely re-learn everything because all last-year frameworks are either out of fashion, or have completely changed their API. Also the tools and language features change at a high pace.

Don't get me wrong, I applaud the progress that is being made, and I'm really excited that we now have very powerful UI features to work with (single page JS applications in general). But the fast pace of development in this space means that we end up with broken toolchains and completely outdated codebases in a matter of months. Try working on a ~2 year old React codebase.

You used a framework that specifically uses CSS in JS and tried to use it as a server-side rendered website.

There is plenty of react frameworks that are geared toward traditional CSS: reactstrap, semantic-ui-react and ant design. Not to mentions that you could have used any css framework.

> You used a framework that specifically uses CSS in JS and tried to use it as a server-side rendered website.

No, I DONT want server side rendering. That's the whole point. I want an application that renders client side, but without the dynamic CSS injection that breaks CSP.

The only current solution that is being offered [1] would be using server-side rendering to inject CSP nonces into your client-side rendered app... it's madness.

It should be possible to compile the CSS-in-JSS into a .css file and serve that css file statically.

[1] https://github.com/cssinjs/jss/blob/master/docs/csp.md

>The 'advise' most devs gave would boil down to disabling CSP by allowing unsafe-inline, or serving the index.html through a NodeJS server and injecting CSP nonces through a templating system. Both are not solutions, but workarounds to a problem that shouldn't exist.

I've observed that a lot of JavaScript framework devs don't really understand web security problems and the point of mitigations such as CSP, properly. These devs manually manipulate the style attribute by concatenating strings together instead of using the DOM element `.style.styleName` properties. They inject inline scripts. Hell, the React dev tools still rely on injecting a script into most pages which fails the minute you have a strict script-src.

On so many occasions I've tried to use JS libraries and had to ditch them because they were poorly written like this. The bug tracker issues are closed or often just ignored with "solutions" like you mentioned that don't fix the underlying problem and leave your app less secure.

To me, this looks like a solution looking for a problem, especially when the author talks about all the workarounds that become necessary just to get back to square one.

It also switches up the pyriamid of reliability[1].

[1]:

        /----\
       / CSS  \
      /--------\
          /\
         /JS\
      /--------\
     /   HTML   \
    /------------\

Definitely agree. CSS is there to provide uniformity across an application's (or website's) UI. Its global for a good reason.

Personally, I don't mind the concept. I can write CSS on a microwave if I have to. But CSS is supposed to be simple, not to be mixed with JS.

There are good designers out there who know HTML and CSS but not JS. This will lead to a problem for those people.

Let's be honest, you cannot just jump into a React component and edit CSS if your knowledge of JS is slim to none.

simple != reliable

What is so hard about writing CSS in JS?

Scoping. The way you style a large, complex application is going to be very different using CSS-In-JS vs pure CSS.

Yes, it is going to be safer and much simpler.

I think you're missing the point you can do both? If you want to load a global stylesheet for common theming and then provide component level CSS in JS then that's absolutely fine and even suggested. Having dealt with many styling solutions in my time I find using styled components with the style mentioned is one of the greatest developer experiences I've had in many years. Being able to interpolate your react state within your css is just great and opens up the doors to massively simplify dynamic layouts which the state of which are much better represented in JS

I don’t understand, simple things do tend to be reliable.

There are good designers out there who don't know HTML, CSS or JS. There are also good designers out there who know all three.

CSS-in-JS (or if not, BEM at the least) is a closer fit to the mental model of styling things in design software like Sketch and Figma. So having to use CSS in full utilising-the-cascade-and-complex-selectors mode could reasonably be seen as a bigger barrier to entry than just using something like Styled Components or Emotion. I've come across plenty of designers comfortable with CSS who felt more at home using Styled Components.

I'm not arguing that there won't be some people for whom CSS-in-JS creates barriers, but there will also be others for whom it knocks them down.

It is all getting a bit silly really. The web needs to be accessible and not restricted to those under thirty that know lots about build tools and little about the world. I prefer the web as originally envisaged with the HTML being essentially human readable rather than obfuscated machine code. It doesn't need to be some data rendered on the frontend by scripts that embed CSS, everything works fine if done old school but properly.

After the browser wars, the iPhone, RWD and frameworks we were left with a complicated mess. But CSS Grid, CSS variables and HTML5 semantic tags have came along with Javascript that you can just use without some silly 'jQuery' thing to make it cross browser.

The choice is ever more complication - which is not accessible - or back to basics with sensible document structure - Tim Berners Lee style - and everything accessible. By accessible I mean code that mere mortals can edit and update.

Nobody is asking if what they make can be edited and maintained in ten years time. If you are making the next app, e.g. Instachat for Squirrels so they can find their nuts then yeah, go with the mountain of here today, gone tomorrow build tools. Otherwise, if you are primarily just writing stuff for people to read then all the assumptions of modern web development have to be questioned.

There is a movement out there to 'intrinsic design' and using what the browser does rather than reinventing the wheel. Part of this is to use the CSS Grid layout engine, the HTML5 inputs for validation and CSS variables to make everything responsive. Pages written this way are just plain quicker, easier to maintain and likely to last.

They're also quicker and simpler to develop! The principle of least power has always been one of the driving factors of *NIX backend software. It's present on the web as well, but I think there are a lot of cultural and institutional reasons why it is not as dominant as it is in the backend .

> There is a movement out there to 'intrinsic design' and using what the browser does rather than reinventing the wheel. Part of this is to use the CSS Grid layout engine, the HTML5 inputs for validation and CSS variables to make everything responsive. Pages written this way are just plain quicker, easier to maintain and likely to last.

This will only work when all browsers have feature parity.

Reply on news.ycombinator.com