6 ms·

React is, in my opinion, a big step forward in reclaiming the front end as a mature UI environment. I have also found that CSS becomes a lot more tolerable wit

React is, in my opinion, a big step forward in reclaiming the front end as a mature UI environment. I have also found that CSS becomes a lot more tolerable with CSS Modules, in combination with React, which allows you to write CSS that targets one component and only that component. By eschewing cascading, you can finally write modular, reusable CSS that avoids side effects and still allows fine-tuning (overriding) by the component user.

niccaluim 10y ago
I agree—I loathe frontend development, but React made it tolerable to do for limited periods—but it's still a hack on a teetering Jenga tower of hacks.
- dcposch 10y ago
  The really funny thing is that the OS runs a simple event + render loop, then the browser implements a wildly complex stateful/declarative structure on top of that (the DOM), then React apps create a simple event + render loop again, this time with special diffing logic to update the underlying DOM as little as possible
  - jacobush 10y ago
    And no doubt this layering will continue... "Look how I easily render this document decription into react primitives".
    - sotojuan 10y ago
      https://news.ycombinator.com/item?id=12473549 https://news.ycombinator.com/item?id=12473549 I made this comment in another thread, but it fits right into this one too.
    - tempodox 10y ago
      Yes, we write web browsers in JS, simply because our browsers let us write nested browsers in JS. I'm only waiting for an OS written in JS so we can use its editor to write an OS in JS.
      - marxidad 10y ago
        Gary Bernhardt mentions an OS written in JS in his video: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
      - dcposch 10y ago
        http://bellard.org/jslinux/ http://bellard.org/jslinux/ also http://www.windows93.net http://www.windows93.net
  - jakobloekke 10y ago
    Brilliant observation. That actually never occured to me.
  - Bartweiss 10y ago
    This is a great insight. I'd never noticed this about browser stuff, but it's definitely a major issue in video game development. Like, most game dev frameworks (especially for mobile) leave you with device-level looping, under language-level looping, under framework-level looping, under code-level looping. This, obviously, is hell. The result is that something as simple as "play this sound file, looping when finished" ranges from awkward to literally impossible. Memory access, garbage collection, and framework timing all collide and leave you with mysterious multi-second gaps while everything tries to sync up. And so everyone building something serious has to dive down past LibGDX into awful, ground-level things like Hammer or un-frameworked C++/Java/etc. I'm not sure what the cure is - unlike a AAA game, there's room for a tiny bit of inefficiency in a webpage. 0.1-0.5 second loads are reasonable, instead of 0.01 second frame renders. But right now the endless layers are spitting out far too many 10 second load times, and no one even seems to notice the redundancy.
- webXL 10y ago
  loathe? I loathe public speaking and flossing, but these things are good for me, and I'm sure you wouldn't be doing frontend dev if there wasn't a big upside that it made possible. > teetering Jenga tower of hacks? How is any programming language not capable of being brittle?
  - niccaluim 10y ago
    This isn't about a language. It's about the whole stack. I've been programming since before the web was invented. The web, as a development platform, is the worst layer-cake of kludges I've ever seen.
    - webXL 10y ago
      Fine. Name a better stack then and suggest ways this one can improve.
breatheoften 10y ago
I echo -- this is good advice. Pick the minimal set of tools you need to use react and css modules (this probably means banging your head against something like webpack for more time than you can possibly enjoy) - but with those pieces alone as starting point, you don't really need a lot of additional library support to build applications that run in browsers ... and your code should start to seem understandable/predictable -- in a manner reminiscent of using better native frameworks of the past. Unlike many other web programming approaches -- this stack should help avoid the need to invent new hacks for every new feature or slightly different situation ...
flukus 10y ago
IMO react is a big step backwards. Adding an abstraction layer almost never produces a better result, it just makes things more complicated.
- axlprose 10y ago
  abstraction isn't inherently a bad thing, it's what gives us the tools to reason at a higher level. It's leaky abstractions that are the problem. Proper abstractions are supposed to compress large bundles of information into a smaller set of [broad] concepts, which then imply all the large sets of details they're abstracting away. High level languages are pretty good abstractions on top of raw assembly code for example, because you don't have to think about what the assembly for your java code is going to look like, it's already implied that it's going to work. As for react, I'm also not a huge fan, but that's because it's still a relatively leaky abstraction that comes with a lot of the same baggage as plain js+html+css. Especially when compared to a fuller abstraction like Elm[0]. But even that's still lacking a complete abstraction of html/css stuff. And that's not even taking the leaky abstractions on the backend side of the equation into account: http://haskell-web.blogspot.com/2014/04/towards-deeper-integration-web-language.html http://haskell-web.blogspot.com/2014/04/towards-deeper-integ... [0] http://elm-lang.org/ http://elm-lang.org/
  - evolve2k 10y ago
    I think where a key abstraction was lost was when JavaScript became the language you had to compile to if you wanted to do web development. Biggest hope I see on the horizon is WebAssembly, which has support of many big players but I've heard very little on it recently. Ref: https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6#.958p781v9 https://medium.com/javascript-scene/what-is-webassembly-the-...
    - tezza 10y ago
      But then you still have the following hack offenders: * DOM, * HTML Layout, * CSS, * A small variety of crappy events ( onDomLoaded ), * a fairly rubbish heavyweight communication layer ( AJAX ) * Keyboard bindings that never work cross app, never cross platform * Accessibility ?? * No idea of the energy impact of your code * No ability to do queries on important device metrics ( energy consumption, clipboard, user presence, login / logoff, single sign on ) * History management and back button mess
reitanqild 10y ago
Maybe for web applications. There should be something in the license of JavaScript frameworks & libraries to prevent them from being used in blogs, newspapers, trade publications etc :-/ For now all innovations in JS just seems to provide us with even heavier web sites for no real benefits. I feel I'm starting to dislike JS the way I disliked Flash which would be quite a feat.
- RussianCow 10y ago
  I think it's completely fine to write a website/blog/newspaper in React, provided you make it isomorphic and keep it as light as possible. Then you get all of the advantages of using React with almost none of the disadvantages. Of course, nobody does this in practice.
  - douche 10y ago
    If your blog/newspaper/text+images website requires JS or it is not readable, you failed.
    - asolove 10y ago
      The two of you are agreeing: "isomorphic" in this context means "the server can render it to html and serve it like a normal webpage".
  - reitanqild 10y ago
    For those who like videos(unlike me) and Java (like me), this was a topic for one of the talks at JavaZone in Oslo last week and I watched that one on my way home today: https://vimeo.com/181925279 https://vimeo.com/181925279 (Oh, BTW, JavaZone 2016 was Oracle-free and all talks seems to have been uploaded to vimeo with no restrictions on downloading.)
aclsid 10y ago
From a javascript point of view, React is great, but I wholeheartedly disagree on the CSS modules. What React did here breaks the whole purpose of CSS, even if it is messy, not to mention that now designers need to have help from programmers to do their job. IMHO, it is much better to user Sass to make CSS sane, and just do whatever makes life easier on the frontend. I feel something light like Backbone.Native with a Shadow/Virtual DOM system is a superior system in this sense.
- lobster_johnson 10y ago
  I'm not very impressed with "the whole purpose of CSS". CSS made a ton of design mistakes which we're still living with today. A big design mistake was the global cascading/inheritance system. It's a huge pain to write CSS that doesn't leak into nooks and crannies where it shouldn't. CSS is supposed to be modular, but you can't just import someone's stylesheet (e.g. for embedding something in your page, like a video player) and trust that it won't override everything around you, intentionally or accidentally. More than that, CSS was designed for "styling documents" — the idea being that you could display the same document with different stylesheets, sort of like themes, and so the stylesheet obviously had to be separate from the document. But almost nobody who uses CSS these days do it to "style" anything, let alone "documents". One particularly egregious issue coming from this design is the attempt to separate layout from content, when in truth layout is content, and for pretty much any application today, the style is also content. We're well beyond the point where an HTML document can be "semantic". Shadow DOM may be the way forward in the future, but CSS Modules is a nice stopgap solution, at least, and you can use them with React + PostCSS (+ SASS) + Webpack in a nicely seamless way, without requiring any browser support.
  - goatlover 10y ago
    What about full on web components? Then the designers can just target components, and leave the programming to the component makers.
    - lobster_johnson 10y ago

niccaluim 10y ago

I agree—I loathe frontend development, but React made it tolerable to do for limited periods—but it's still a hack on a teetering Jenga tower of hacks.

dcposch 10y ago
The really funny thing is that the OS runs a simple event + render loop, then the browser implements a wildly complex stateful/declarative structure on top of that (the DOM), then React apps create a simple event + render loop again, this time with special diffing logic to update the underlying DOM as little as possible
- jacobush 10y ago
  And no doubt this layering will continue... "Look how I easily render this document decription into react primitives".
  - sotojuan 10y ago
    https://news.ycombinator.com/item?id=12473549 https://news.ycombinator.com/item?id=12473549 I made this comment in another thread, but it fits right into this one too.
  - tempodox 10y ago
    Yes, we write web browsers in JS, simply because our browsers let us write nested browsers in JS. I'm only waiting for an OS written in JS so we can use its editor to write an OS in JS.
    - marxidad 10y ago
      Gary Bernhardt mentions an OS written in JS in his video: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
    - dcposch 10y ago
      http://bellard.org/jslinux/ http://bellard.org/jslinux/ also http://www.windows93.net http://www.windows93.net
- jakobloekke 10y ago
  Brilliant observation. That actually never occured to me.
- Bartweiss 10y ago
  This is a great insight. I'd never noticed this about browser stuff, but it's definitely a major issue in video game development. Like, most game dev frameworks (especially for mobile) leave you with device-level looping, under language-level looping, under framework-level looping, under code-level looping. This, obviously, is hell. The result is that something as simple as "play this sound file, looping when finished" ranges from awkward to literally impossible. Memory access, garbage collection, and framework timing all collide and leave you with mysterious multi-second gaps while everything tries to sync up. And so everyone building something serious has to dive down past LibGDX into awful, ground-level things like Hammer or un-frameworked C++/Java/etc. I'm not sure what the cure is - unlike a AAA game, there's room for a tiny bit of inefficiency in a webpage. 0.1-0.5 second loads are reasonable, instead of 0.01 second frame renders. But right now the endless layers are spitting out far too many 10 second load times, and no one even seems to notice the redundancy.
webXL 10y ago
loathe? I loathe public speaking and flossing, but these things are good for me, and I'm sure you wouldn't be doing frontend dev if there wasn't a big upside that it made possible. > teetering Jenga tower of hacks? How is any programming language not capable of being brittle?
- niccaluim 10y ago
  This isn't about a language. It's about the whole stack. I've been programming since before the web was invented. The web, as a development platform, is the worst layer-cake of kludges I've ever seen.
  - webXL 10y ago
    Fine. Name a better stack then and suggest ways this one can improve.

breatheoften 10y ago

I echo -- this is good advice. Pick the minimal set of tools you need to use react and css modules (this probably means banging your head against something like webpack for more time than you can possibly enjoy) - but with those pieces alone as starting point, you don't really need a lot of additional library support to build applications that run in browsers ... and your code should start to seem understandable/predictable -- in a manner reminiscent of using better native frameworks of the past. Unlike many other web programming approaches -- this stack should help avoid the need to invent new hacks for every new feature or slightly different situation ...

flukus 10y ago

IMO react is a big step backwards. Adding an abstraction layer almost never produces a better result, it just makes things more complicated.

axlprose 10y ago
abstraction isn't inherently a bad thing, it's what gives us the tools to reason at a higher level. It's leaky abstractions that are the problem. Proper abstractions are supposed to compress large bundles of information into a smaller set of [broad] concepts, which then imply all the large sets of details they're abstracting away. High level languages are pretty good abstractions on top of raw assembly code for example, because you don't have to think about what the assembly for your java code is going to look like, it's already implied that it's going to work. As for react, I'm also not a huge fan, but that's because it's still a relatively leaky abstraction that comes with a lot of the same baggage as plain js+html+css. Especially when compared to a fuller abstraction like Elm[0]. But even that's still lacking a complete abstraction of html/css stuff. And that's not even taking the leaky abstractions on the backend side of the equation into account: http://haskell-web.blogspot.com/2014/04/towards-deeper-integration-web-language.html http://haskell-web.blogspot.com/2014/04/towards-deeper-integ... [0] http://elm-lang.org/ http://elm-lang.org/
- evolve2k 10y ago
  I think where a key abstraction was lost was when JavaScript became the language you had to compile to if you wanted to do web development. Biggest hope I see on the horizon is WebAssembly, which has support of many big players but I've heard very little on it recently. Ref: https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6#.958p781v9 https://medium.com/javascript-scene/what-is-webassembly-the-...
  - tezza 10y ago
    But then you still have the following hack offenders: * DOM, * HTML Layout, * CSS, * A small variety of crappy events ( onDomLoaded ), * a fairly rubbish heavyweight communication layer ( AJAX ) * Keyboard bindings that never work cross app, never cross platform * Accessibility ?? * No idea of the energy impact of your code * No ability to do queries on important device metrics ( energy consumption, clipboard, user presence, login / logoff, single sign on ) * History management and back button mess

reitanqild 10y ago

Maybe for web applications. There should be something in the license of JavaScript frameworks & libraries to prevent them from being used in blogs, newspapers, trade publications etc :-/ For now all innovations in JS just seems to provide us with even heavier web sites for no real benefits. I feel I'm starting to dislike JS the way I disliked Flash which would be quite a feat.

RussianCow 10y ago
I think it's completely fine to write a website/blog/newspaper in React, provided you make it isomorphic and keep it as light as possible. Then you get all of the advantages of using React with almost none of the disadvantages. Of course, nobody does this in practice.
- douche 10y ago
  If your blog/newspaper/text+images website requires JS or it is not readable, you failed.
  - asolove 10y ago
    The two of you are agreeing: "isomorphic" in this context means "the server can render it to html and serve it like a normal webpage".
- reitanqild 10y ago
  For those who like videos(unlike me) and Java (like me), this was a topic for one of the talks at JavaZone in Oslo last week and I watched that one on my way home today: https://vimeo.com/181925279 https://vimeo.com/181925279 (Oh, BTW, JavaZone 2016 was Oracle-free and all talks seems to have been uploaded to vimeo with no restrictions on downloading.)

aclsid 10y ago

From a javascript point of view, React is great, but I wholeheartedly disagree on the CSS modules. What React did here breaks the whole purpose of CSS, even if it is messy, not to mention that now designers need to have help from programmers to do their job. IMHO, it is much better to user Sass to make CSS sane, and just do whatever makes life easier on the frontend. I feel something light like Backbone.Native with a Shadow/Virtual DOM system is a superior system in this sense.

lobster_johnson 10y ago
I'm not very impressed with "the whole purpose of CSS". CSS made a ton of design mistakes which we're still living with today. A big design mistake was the global cascading/inheritance system. It's a huge pain to write CSS that doesn't leak into nooks and crannies where it shouldn't. CSS is supposed to be modular, but you can't just import someone's stylesheet (e.g. for embedding something in your page, like a video player) and trust that it won't override everything around you, intentionally or accidentally. More than that, CSS was designed for "styling documents" — the idea being that you could display the same document with different stylesheets, sort of like themes, and so the stylesheet obviously had to be separate from the document. But almost nobody who uses CSS these days do it to "style" anything, let alone "documents". One particularly egregious issue coming from this design is the attempt to separate layout from content, when in truth layout is content, and for pretty much any application today, the style is also content. We're well beyond the point where an HTML document can be "semantic". Shadow DOM may be the way forward in the future, but CSS Modules is a nice stopgap solution, at least, and you can use them with React + PostCSS (+ SASS) + Webpack in a nicely seamless way, without requiring any browser support.
- goatlover 10y ago
  What about full on web components? Then the designers can just target components, and leave the programming to the component makers.
  - lobster_johnson 10y ago