Live data from Hacker News

The Debate Around “Do We Even Need CSS Anymore?”

css-tricks.com

61–67 of 67 posts

Re: The Debate Around “Do We Even Need CSS Anymore?”

#61
post #25

Earlier quoted context omitted.

There's still some key differences between what this new JSON declared and Javascript distributed stylesheets would work. Mainly is that there is no more CSS Selector madness. You no longer need to have concepts such as selector specificity, nor the entire syntax around grabbing the correct selectors. Also you could then be able to logically follow the flow using traditional debugging methods rather than this mess wh…

Here's an example of a JS application that dynamically animates DOM properties using requestAnimationFrame: http://www.elevatesoft.com:8081/panels/panels.html It's a little slow on mobile, but pretty good on desktops, and could probably use some optimizations. The DOM transitions are animated at the of end of each change management cycle for a given UI element. That allows for layout management that occurs independen…

That's pretty cool. Performance on mobile is of course important, but perhaps it can be improved.

I like CSS, but I also like having other options and ideas available. As others have said, for special one page web apps, the scripted layout might be a good choice.

And then we have CSS grids coming soon too. Choice is good!

Re: The Debate Around “Do We Even Need CSS Anymore?”

#62
post #40

I'd propose the following distinction, especially for React users: If your components will only ever be used by you or a small, internal team of programmers, then inline styles can work. If, however, your components are meant to be re-usable, public and accessible then CSS is still a must. To pick on one project react-datagrid is a super useful, public component for displaying data, but they use inline styles, which…

How about if you design the styles so you can pass in a styles object via the parent element, and the style-elemnt gets merged in to overwrite the defaults? is there a reason this wouldn't work?

They tried that in react-datagrid, but they forgot to expose a bunch. It's easy to use inline styles and hard to go back and add the layers of exposed properties you need to make sure they are accessible.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#63
post #61

Earlier quoted context omitted.

Here's an example of a JS application that dynamically animates DOM properties using requestAnimationFrame: http://www.elevatesoft.com:8081/panels/panels.html It's a little slow on mobile, but pretty good on desktops, and could probably use some optimizations. The DOM transitions are animated at the of end of each change management cycle for a given UI element. That allows for layout management that occurs independen…

That's pretty cool. Performance on mobile is of course important, but perhaps it can be improved. I like CSS, but I also like having other options and ideas available. As others have said, for special one page web apps, the scripted layout might be a good choice. And then we have CSS grids coming soon too. Choice is good!

Mobile is a tough nut to crack, due to some hard constraints on the CPU/power consumption, but it's getting better. A new iPhone 5s does a pretty good job with something like that app I linked to, whereas an older Samsung Galaxy Tab 2 does not. A lot also depends upon the browser, since there is a big difference between the JS engines in Chrome (best, by far) and FF/IE when it comes to things like requestAnimationFrame() execution performance. The linked-to example is a dog when run on IE 11/Windows 8 on a practically-new Dell laptop/tablet convertible with an i3, but works nicely in Chrome on the same device.

Re: CSS grids - totally agree. But, what I've learned over the last 4 years of developing a web application IDE is this: CSS is great if you want to set the layout and leave it alone (for the most part). In other words, when the JS is decorative, things are great. When the JS becomes the primary actor, things start to break down due to lack of control over how/when the reflows/repaints occur.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#64
post #47

Representing styles as executable code is a very poor idea. Suddenly you go from data you can inspect and play with to something you can just execute and take what you are given. The principle of least power is an incredibly important axiom of the web's architecture, and when people break it, lots of things become more difficult or impossible. If you don't like CSS, then by all means, propose a replacement – but plea…

Check out the format for an inline style: { background: "red", fontWeight: "bold" } It's just a Javascript mapping from strings to strings. That's a very un-powerful language, and that's what React consumes. Sure, you could generate this mapping with all sorts of arbitrary code, just like how you could generate CSS with all sorts of arbitrary code. But that doesn't make the style declaration itself any more powerful,…

There is a difference, though. The above code is still executable in that it renders the proper styling via JS at run-time, rather than at "compile" time (i.e. when it is preprocessed).

Re: The Debate Around “Do We Even Need CSS Anymore?”

#65
post #8

CSS preprocessors are fine. Processors only understand binary but noone programs in binary today. If CSS become the binary of tomorrow, it's fine. Inlining CSS is stupid, it makes your page bigger, less flexible, doesn't use browser caching technics, and didn't solve the problem at all (or make it worse...). CSS with Javascript is even worse, as it will be slow as fuck, hard to maintain, and equivalent to directly wr…

So many wrong statements. The performance differences, between CSS styles applied from a JS file and a CSS file are very small on modern browsers, with JS being faster sometime. JS files are cached. Preprocessors are not fine, they complicate and slow down the development process. Inlining CSS is not stupid, OP discusses the numerous advantages it brings...

> The performance differences, between CSS styles applied from a JS file and a CSS file are very small on modern browsers, with JS being faster sometime.

False, JS have to be interpreted and you have issue with document not being fully loaded. And CSS is easy to parse, faster to parse and "run" than JS. No, saying that JS is faster than CSS is just false.

> JS files are cached.

CSS too, and even can be prerendered. And CSS works when JS is disabled.

> Preprocessors are not fine, they complicate and slow down the development process.

That's not an argument at all because with the right tool its just like using a compiler. See "make" for example. Also you have to see how much you gain with the preprocessor, maybe loosing 0.01ms per "make" is worse it since you write code 1.2 times faster...

> Inlining CSS is not stupid, OP discusses the numerous advantages it brings...

And do not highlight the obvious disadvantages.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#66
post #65

Earlier quoted context omitted.

So many wrong statements. The performance differences, between CSS styles applied from a JS file and a CSS file are very small on modern browsers, with JS being faster sometime. JS files are cached. Preprocessors are not fine, they complicate and slow down the development process. Inlining CSS is not stupid, OP discusses the numerous advantages it brings...

> The performance differences, between CSS styles applied from a JS file and a CSS file are very small on modern browsers, with JS being faster sometime. False, JS have to be interpreted and you have issue with document not being fully loaded. And CSS is easy to parse, faster to parse and "run" than JS. No, saying that JS is faster than CSS is just false. > JS files are cached. CSS too, and even can be prerendered. A…

You have NO idea what you're talking about.

>> JS have to be interpreted

Yeah, because the Bible, the Quaran and the Declaration of Independence say so ...

Re: The Debate Around “Do We Even Need CSS Anymore?”

#67
post #47

Earlier quoted context omitted.

Check out the format for an inline style: { background: "red", fontWeight: "bold" } It's just a Javascript mapping from strings to strings. That's a very un-powerful language, and that's what React consumes. Sure, you could generate this mapping with all sorts of arbitrary code, just like how you could generate CSS with all sorts of arbitrary code. But that doesn't make the style declaration itself any more powerful,…

There is a difference, though. The above code is still executable in that it renders the proper styling via JS at run-time, rather than at "compile" time (i.e. when it is preprocessed).

That's true, but I don't feel like it's relevant.

React's inline styles API satisfies the principle of least power: you can only pass to it a mapping from string keys to string/number values.

It's possible that the input data might be compiled from some other more powerful format, and it's possible to argue that this compilation step is a violation of the principle of least power, but that feels like a separate issue. It's very possible to use inline styles without adding unnecessary power to the declaration language - heck, you could declare them in JSON and load them during the build step if you want. How you use inline styles is your decision.

Post reply on HN