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.
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.
Perhaps webassembly doesn't change this either?
I hate the sheer number of files people create in projects. The worst one I've seen is a ".types.ts" file. Everywhere.
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.
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.
Styled-components solves all these problems, randomly generating CSS classes under the hood, while still creating CSS files for you. Check out https://www.styled-components.com/docs/basics#motivation.
I'm not sure I can be sympathetic to "the final HTML DOM output" matching your expectations here. Think about a Dropdown select. We still need to create a library with a bunch of absolutely positioned <div>s here because you literally can't build a good looking dropdown with normal HTML. It's really hard for me to think fondly of HTML/CSS when all they provide is assembly-code level specification. Flexbox and Grid are great counter-examples here. Still no nice looking dropdown.
I disagree. Build a drop down field using the normal form field elements; it is up to the browser to render them in a suitable way. (Which way is suitable may depend on details which the author is unaware of.)
> The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. ... I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector.
That I agree. Let the user to override/ignore the styles, or to use them without changing if that is what the user wish.
I want to push back against this in particular, not only because I think it does HTML/CSS a disservice, but because I've maintained codebases that took this approach and they're really bad to work with. You're trading a little bit of CSS annoyance for constant positioning/z-index errors -- and you'll need to update your positions whenever your page scrolls or a component grows... there are just so many ways for this to go wrong, and there's always an edge case that developers miss.
Nothing is absolute, but most of the time the proper way to do something like a custom dropdown selector or tooltip is to semantically group it with the component it's attached to, and then at most absolute-position one element to center it relative to its parent.
<div class="Input">
<input class="Input__Field">
<ul class="Input__Options Input__Options--hidden">
<li>Option One</li>
<li>Option Two</li>
</ul>
</div>
.Input { position: relative; }
.Input__Options { position: absolute; /* etc */ }
.Input__Options--hidden { display: none; }
I don't like everything about CSS, there are a number of problematic design choices in the language -- particularly specificity. I also wouldn't necessarily be against a new primitive for scoping CSS to specific DOM trees. But annoyances aside, overall CSS is pretty great, and on net the apps I maintain that make heavy use of CSS are easier to maintain and less buggy than the apps I work on that try to use JS code to accomplish the same tasks. Obviously that's anecdotal.Again, this doesn't mean you can't compose your CSS in JS. But separation of concerns is not for you. The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. When you spit out HTML and CSS, you are spitting out an application interface.
You're really worried about where you write your CSS, and I couldn't care less. I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector.