3 ms·

This doesn't even get to the overall design of css in the first place and the problems it has... http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.

This doesn't even get to the overall design of css in the first place and the problems it has... http://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html http://blog.vjeux.com/2014/javascript/react-css-in-js-nation...

Turing_Machine 11y ago
The whole idea of using (at least) three separate languages (HTML, JavaScript, CSS) would seem weird if it were proposed de novo. Consider that LaTeX manages to carry out all of those functions (layout, styling, and computation) using only one language.
- stream_fusion 11y ago
  React and jsx constructed dom using inline-styles brings the disparate technologies together in a composable way.
  - Touche 11y ago
    But without cascading, the whole point of css.
- wodenokoto 11y ago
  In your latex equation, you are missing where the data goes. The idea for html/css/js is that data goes into the html, layout and styling into CDs and interactivity is defined in JavaScript. That makes sense. The problem is that we never got anything close to that.
  - TheOtherHobbes 11y ago
    The problem is it doesn't really make sense in 2015. Or rather, it only makes sense if you accept the technical debt inherited from HTML, which is itself the simplified stepchild of SGML, which was a 1960s idea and firmly rooted in paper publishing. Separating content and presentation isn't a bad idea. The badness happened because JavaScript - or some other web programming language - didn't appear until HTML was established. So instead of a generic object model, with tagged content containers linked to an updatable library of presentation and layout code that could be standardised and refined continuously, some semi-standard version of a sort-of-working layout library was pre-compiled into browsers and accessed through a not very coherent DSL. This made it fast enough to be usable - a very good thing, given 1990s processing speeds - but it also made it much harder to develop and fix. In 2015 CSS shouldn't really be necessary. So much layout and presentation is done with JavaScript anyway that it would make just as much sense to get rid of CSS and extend and standardise on something like jQuery-but-better to create an evolving cacheable layout library that bypasses browser quirks and uses exactly one common versioned codebase. This might seem ambitious, but writing good code that works across all common browsers now is such a nightmare for everyone that too many devs are either not bothering, or their bosses are telling them not to bother because it's too expensive. As a user, I keep finding sites that simply don't work in Chrome or Safari or IE or whatever. That's not good, especially when there's a business at the other end trying to sell things. I don't doubt the web will creak along, and some people will do amazing things. But it's still frustrating when it could be simpler, more standardised, more consistent, and much more reliable.
    - gopowerranger 11y ago
      As a web dev of 11 years, I don't find writing cross browser code a nightmare. And any web site that doesn't work cross browser is by amateurs at best. I don't know what web sites you visit where you have such issues but I haven't seen them in years except for the occasional goofball site.
      - Ygg2 11y ago
        As someone that had to support IE6 and Chrome at same time, I can't agree with this statement.
        gopowerranger 11y ago
        Are you seriously trying to throw IE6 into this to attempt to prove your point? We aren't talking about antiquated browsers no one should be using today.
        Ygg2 11y ago
        Are you seriously trying to deny IE6 isn't there in the wild? It was a job I had to do. I was paid to do it. It was awful. This happened circa 2013. For contrast I now support IE8 and IE9. Without jQuery. It's bad. Really, really bad. Like, there isn't indexOf on Array and asking for polyfill is forbidden.
        gopowerranger 11y ago
        You're one-off job is nothing to be holding up as an example of current web development. My company has 23 active clients and I can't tell you the last time, many years ago, we saw IE8 in the visitors logs much less anything less than that.
        Ygg2 11y ago
        I wasn't holding it as example of current web development. I was holding it as a sample of web development that happened semi recently. It is also why web dev can be a nightmare - Legacy systems and browser incompatibility. It's great if you never had to deal with them, but that doesn't mean it won't happen. Note: It wasn't a one-off job either. There were multiple jobs, government sector.
  - Turing_Machine 11y ago
    Hmm... I don't see any conceptual reason why separating those things should require completely different languages, though.
    - wodenokoto 11y ago
      Nobody bats an eye when you use Python for logic, sql for querying your database and regex for searching text. Unlike the front end, there are ample opportunities for "uniting" the backend in one language, yet nobody really seems to bother. I speculate that it's because these languages are better at certain things, just like having a non-executable language for data, helps keep the data, data only (cue angry lispers), and facilitates easier writing of prose in a mark-up language than a real programming language could facilitate. Just look at markdown. More over, we invented JSON, rather than just sending JS files between browser and server.
      - afarrell 11y ago
        > Nobody really seems to bother I prefer writing queries using Django's ORM even though it is underpowered.
        wodenokoto 11y ago
        Yeah, I guess I as a little hyperbolic :)
  - h1762581 11y ago
    >that data goes into the html It's more like static content goes into the html, dynamic content goes into JSON.
- afarrell 11y ago
  Although LaTeX needs much better error messages.
- A_COMPUTER 11y ago
  XML to the rescue! The alternate future of the web! XML + XSLT (stylesheet)-> XSL:FO (intermediate XML language for formatting) -> FOP (program to convert formatting objects to output) -> rendered format. XML all the way down! (One mistake, zero output.)
- TabAtkins 11y ago
  As a very busy CSSWG member... I agree. There are a number of benefits to the current structure, but I highly suspect that if the web were invented today, styling would a JS-mediated aspect of the DOM, not something fully separate like it is today.
davidkpiano 11y ago
Those aren't problems with CSS - those are problems with how Facebook architected _their_ CSS. A lot of those don't apply to well-architected projects.
olavk 11y ago
These seem to be problems with Facebooks architecture rather than general CSS problems. For example they claim you have to use "global variables" like in the selector ".button-depressed". But you could just use ".button.depressed", thereby scoping the depressed-class.

Turing_Machine 11y ago

The whole idea of using (at least) three separate languages (HTML, JavaScript, CSS) would seem weird if it were proposed de novo. Consider that LaTeX manages to carry out all of those functions (layout, styling, and computation) using only one language.

stream_fusion 11y ago
React and jsx constructed dom using inline-styles brings the disparate technologies together in a composable way.
- Touche 11y ago
  But without cascading, the whole point of css.
wodenokoto 11y ago
In your latex equation, you are missing where the data goes. The idea for html/css/js is that data goes into the html, layout and styling into CDs and interactivity is defined in JavaScript. That makes sense. The problem is that we never got anything close to that.
- TheOtherHobbes 11y ago
  The problem is it doesn't really make sense in 2015. Or rather, it only makes sense if you accept the technical debt inherited from HTML, which is itself the simplified stepchild of SGML, which was a 1960s idea and firmly rooted in paper publishing. Separating content and presentation isn't a bad idea. The badness happened because JavaScript - or some other web programming language - didn't appear until HTML was established. So instead of a generic object model, with tagged content containers linked to an updatable library of presentation and layout code that could be standardised and refined continuously, some semi-standard version of a sort-of-working layout library was pre-compiled into browsers and accessed through a not very coherent DSL. This made it fast enough to be usable - a very good thing, given 1990s processing speeds - but it also made it much harder to develop and fix. In 2015 CSS shouldn't really be necessary. So much layout and presentation is done with JavaScript anyway that it would make just as much sense to get rid of CSS and extend and standardise on something like jQuery-but-better to create an evolving cacheable layout library that bypasses browser quirks and uses exactly one common versioned codebase. This might seem ambitious, but writing good code that works across all common browsers now is such a nightmare for everyone that too many devs are either not bothering, or their bosses are telling them not to bother because it's too expensive. As a user, I keep finding sites that simply don't work in Chrome or Safari or IE or whatever. That's not good, especially when there's a business at the other end trying to sell things. I don't doubt the web will creak along, and some people will do amazing things. But it's still frustrating when it could be simpler, more standardised, more consistent, and much more reliable.
  - gopowerranger 11y ago
    As a web dev of 11 years, I don't find writing cross browser code a nightmare. And any web site that doesn't work cross browser is by amateurs at best. I don't know what web sites you visit where you have such issues but I haven't seen them in years except for the occasional goofball site.
    - Ygg2 11y ago
      As someone that had to support IE6 and Chrome at same time, I can't agree with this statement.
      - gopowerranger 11y ago
        Are you seriously trying to throw IE6 into this to attempt to prove your point? We aren't talking about antiquated browsers no one should be using today.
        Ygg2 11y ago
        Are you seriously trying to deny IE6 isn't there in the wild? It was a job I had to do. I was paid to do it. It was awful. This happened circa 2013. For contrast I now support IE8 and IE9. Without jQuery. It's bad. Really, really bad. Like, there isn't indexOf on Array and asking for polyfill is forbidden.
        gopowerranger 11y ago
        You're one-off job is nothing to be holding up as an example of current web development. My company has 23 active clients and I can't tell you the last time, many years ago, we saw IE8 in the visitors logs much less anything less than that.
        Ygg2 11y ago
        I wasn't holding it as example of current web development. I was holding it as a sample of web development that happened semi recently. It is also why web dev can be a nightmare - Legacy systems and browser incompatibility. It's great if you never had to deal with them, but that doesn't mean it won't happen. Note: It wasn't a one-off job either. There were multiple jobs, government sector.
- Turing_Machine 11y ago
  Hmm... I don't see any conceptual reason why separating those things should require completely different languages, though.
  - wodenokoto 11y ago
    Nobody bats an eye when you use Python for logic, sql for querying your database and regex for searching text. Unlike the front end, there are ample opportunities for "uniting" the backend in one language, yet nobody really seems to bother. I speculate that it's because these languages are better at certain things, just like having a non-executable language for data, helps keep the data, data only (cue angry lispers), and facilitates easier writing of prose in a mark-up language than a real programming language could facilitate. Just look at markdown. More over, we invented JSON, rather than just sending JS files between browser and server.
    - afarrell 11y ago
      > Nobody really seems to bother I prefer writing queries using Django's ORM even though it is underpowered.
      - wodenokoto 11y ago
        Yeah, I guess I as a little hyperbolic :)
- h1762581 11y ago
  >that data goes into the html It's more like static content goes into the html, dynamic content goes into JSON.
afarrell 11y ago
Although LaTeX needs much better error messages.
A_COMPUTER 11y ago
XML to the rescue! The alternate future of the web! XML + XSLT (stylesheet)-> XSL:FO (intermediate XML language for formatting) -> FOP (program to convert formatting objects to output) -> rendered format. XML all the way down! (One mistake, zero output.)
TabAtkins 11y ago
As a very busy CSSWG member... I agree. There are a number of benefits to the current structure, but I highly suspect that if the web were invented today, styling would a JS-mediated aspect of the DOM, not something fully separate like it is today.

davidkpiano 11y ago

Those aren't problems with CSS - those are problems with how Facebook architected _their_ CSS. A lot of those don't apply to well-architected projects.

olavk 11y ago

These seem to be problems with Facebooks architecture rather than general CSS problems. For example they claim you have to use "global variables" like in the selector ".button-depressed". But you could just use ".button.depressed", thereby scoping the depressed-class.