4 ms·

Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day. React.js has been the most significant J

Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day. React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard. We’re killing HTML templates and writing JSX. We’re killing CSS classes and building styled-components. It’s all compiling to HTML, CSS and JS in the end. We just get to do our jobs faster. Why people have a problem with that is beyond me.

worldsayshi 7y ago
As another react developer. The separation goes deeper than just having styles, logic and the dom in separate files. It's the underlying data structures that are important in the end. And in that regard react doesn't change the field. We still have the same essential structure and building blocks. Just a different way to reason and interact with it. Perhaps webassembly doesn't change this either?
- beaker52 7y ago
  If anything I'd prefer it if styles, logic and dom lived together in the same file. I hate the sheer number of files people create in projects. The worst one I've seen is a ".types.ts" file. Everywhere.
  - bitwize 7y ago
    So, .vue files then?
    - beaker52 7y ago
      That is one of the thing I like about vue.
deleted 7y ago
[deleted]
danShumway 7y ago
> It’s all compiling to HTML, CSS and JS in the end. I don't generally have a problem with this. I use JSX at work too. My take is it's just another templating system, I don't think it's special. I don't have anything against templating. To a certain extent, my point is that template systems are good -- put your two-way data bindings and special components in them. When I write JSX though, I make sure it renders out as semantic HTML. If your approach to JSX is, "I'm going to write my render code in JS and output HTML", I don't have a problem with you, you're doing great. If your approach to JSX is, "my interface is just Javascript, so it's fine to spit out poorly organized divs that are absolute-positioned everywhere", then I think you've missed the point of HTML. React isn't an antipattern. But React doesn't remove your need to think about the final HTML that your app is going to spit out. Apps like Youtube and Twitter are particularly bad at this -- Youtube's DOM is a horrifying mess, it's completely unreadable and way too difficult to work with or style. It's not because they're using a component system to build it, it's because they're fine treating the HTML as a non-readable render target. They don't care about HTML as a user interface. The broad mistake people make on the web is to look at HTML and say, "because I can't build a scalable app on JQuery and hand-coded HTML, therefore HTML is bad." Google's hot-take with HTML custom components is not that you could put your template logic inside your other component logic -- it's that the HTML layer shouldn't matter at all and you should stop thinking about it. Separation of concerns is for users, not for you. It's not about where you organize your logic, or even if you mix up your languages into the same file. It's about what gets spit out onto the final page. > We’re killing CSS classes and building styled-components. I would caution a bit against doing styles in JS -- not because adding a template layer or JS layer that generates CSS is bad, but because many codebases that I've worked with use CSS-in-JS as an excuse to rewrite basic CSS controls like hover effects in Javascript and inline the remaining styles. That doesn't mean you shouldn't do CSS in JS, it just means you should take the time to use a library that spits out actual CSS and that allows you to take advantage of native selectors and pseudo-elements. React does itself a disservice by using tutorials that teach people to apply styles directly to elements instead of pointing people towards any of the more decent companion libraries that will let you do styling correctly. Unless your engineering team is the size of Facebook's and you can't communicate about your components at all, you probably should still be using classes. Of course that doesn't mean you can't use JS to restrict class scope or template that CSS. I personally tend to be more of a proponent of BEM than I am of JS styles, but I'm not going to fight someone over that.
camgunz 7y ago
Hey, I'm a full stack eng and while I think React is net good, I don't think that's the same thing as "DOM/CSS is bad". Writing a web application is different than writing a web document (or set of documents). I think what people are anxious about here is that many, if not most, sites are documents or sets of documents, but FE trends are "everything is an app", which leads to difficult situations like "in order to talk to my mom on the Internet, I essentially have to buy into the surveillance state". We haven't done a good job at letting people do only what they want on the web, because so much of the web has been built by companies with ulterior motives. What people are worried about here--and this is true whether we're talking about WASM, Flash, Java Applets, Silverlight, etc.--is this is a giant leap down the road to a co-opted web, devoid of user choice and controlled entirely by moneyed or state interests. Personally I feel like this happened a long time ago, so WASM doesn't worry me any more than I already am. But I think it's important to keep in mind more is at stake here than CSS-in-JS, or any one FE's career.
bryanrasmussen 7y ago
The last decade? In 2009 JQuery ruled the world, the last 6 years definitely. they have a problem with it in that unless you are rendering server side your pages won't work for someone who does not want to enable JS. In the same way it goes against lots of ways the web has worked for 2 decades in regards to user customization, the ability to scrape content etc. so these things are irritating to anyone familiar with how "things used to be" in the same way that new freeway development destroying an ecosystem can be irritating to people familiar with the beauties of that ecosystem. For what it's worth I also make my living doing the same thing, but I can certainly see the benefits to the other way.
Hnrobert42 7y ago
Because I run noscript. Mostly, when a site requires javascript for static content, I just hit back and move on.

worldsayshi 7y ago

As another react developer. The separation goes deeper than just having styles, logic and the dom in separate files. It's the underlying data structures that are important in the end. And in that regard react doesn't change the field. We still have the same essential structure and building blocks. Just a different way to reason and interact with it. Perhaps webassembly doesn't change this either?

beaker52 7y ago
If anything I'd prefer it if styles, logic and dom lived together in the same file. I hate the sheer number of files people create in projects. The worst one I've seen is a ".types.ts" file. Everywhere.
- bitwize 7y ago
  So, .vue files then?
  - beaker52 7y ago
    That is one of the thing I like about vue.

deleted 7y ago

[deleted]

danShumway 7y ago

> It’s all compiling to HTML, CSS and JS in the end. I don't generally have a problem with this. I use JSX at work too. My take is it's just another templating system, I don't think it's special. I don't have anything against templating. To a certain extent, my point is that template systems are good -- put your two-way data bindings and special components in them. When I write JSX though, I make sure it renders out as semantic HTML. If your approach to JSX is, "I'm going to write my render code in JS and output HTML", I don't have a problem with you, you're doing great. If your approach to JSX is, "my interface is just Javascript, so it's fine to spit out poorly organized divs that are absolute-positioned everywhere", then I think you've missed the point of HTML. React isn't an antipattern. But React doesn't remove your need to think about the final HTML that your app is going to spit out. Apps like Youtube and Twitter are particularly bad at this -- Youtube's DOM is a horrifying mess, it's completely unreadable and way too difficult to work with or style. It's not because they're using a component system to build it, it's because they're fine treating the HTML as a non-readable render target. They don't care about HTML as a user interface. The broad mistake people make on the web is to look at HTML and say, "because I can't build a scalable app on JQuery and hand-coded HTML, therefore HTML is bad." Google's hot-take with HTML custom components is not that you could put your template logic inside your other component logic -- it's that the HTML layer shouldn't matter at all and you should stop thinking about it. Separation of concerns is for users, not for you. It's not about where you organize your logic, or even if you mix up your languages into the same file. It's about what gets spit out onto the final page. > We’re killing CSS classes and building styled-components. I would caution a bit against doing styles in JS -- not because adding a template layer or JS layer that generates CSS is bad, but because many codebases that I've worked with use CSS-in-JS as an excuse to rewrite basic CSS controls like hover effects in Javascript and inline the remaining styles. That doesn't mean you shouldn't do CSS in JS, it just means you should take the time to use a library that spits out actual CSS and that allows you to take advantage of native selectors and pseudo-elements. React does itself a disservice by using tutorials that teach people to apply styles directly to elements instead of pointing people towards any of the more decent companion libraries that will let you do styling correctly. Unless your engineering team is the size of Facebook's and you can't communicate about your components at all, you probably should still be using classes. Of course that doesn't mean you can't use JS to restrict class scope or template that CSS. I personally tend to be more of a proponent of BEM than I am of JS styles, but I'm not going to fight someone over that.

camgunz 7y ago

Hey, I'm a full stack eng and while I think React is net good, I don't think that's the same thing as "DOM/CSS is bad". Writing a web application is different than writing a web document (or set of documents). I think what people are anxious about here is that many, if not most, sites are documents or sets of documents, but FE trends are "everything is an app", which leads to difficult situations like "in order to talk to my mom on the Internet, I essentially have to buy into the surveillance state". We haven't done a good job at letting people do only what they want on the web, because so much of the web has been built by companies with ulterior motives. What people are worried about here--and this is true whether we're talking about WASM, Flash, Java Applets, Silverlight, etc.--is this is a giant leap down the road to a co-opted web, devoid of user choice and controlled entirely by moneyed or state interests. Personally I feel like this happened a long time ago, so WASM doesn't worry me any more than I already am. But I think it's important to keep in mind more is at stake here than CSS-in-JS, or any one FE's career.

bryanrasmussen 7y ago

The last decade? In 2009 JQuery ruled the world, the last 6 years definitely. they have a problem with it in that unless you are rendering server side your pages won't work for someone who does not want to enable JS. In the same way it goes against lots of ways the web has worked for 2 decades in regards to user customization, the ability to scrape content etc. so these things are irritating to anyone familiar with how "things used to be" in the same way that new freeway development destroying an ecosystem can be irritating to people familiar with the beauties of that ecosystem. For what it's worth I also make my living doing the same thing, but I can certainly see the benefits to the other way.

Hnrobert42 7y ago

Because I run noscript. Mostly, when a site requires javascript for static content, I just hit back and move on.