undefined | Better HN

0 pointsdanShumway6y ago0 comments

> 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.

0 comments

lsalvatore6y ago

CSS files are in a league in their own for how badly they represent the state of my app. In no other data structure would we say "oh sure, lets arbitrarily name groups of key/value pairs in a nested hierarchy that may or may not match where they are applied. Also, its a global namespace so let's preface every name with our application name". At scale, CSS classes are really difficult to find when looking at your component and have ambiguous naming and nesting patterns. They shouldn't exist.

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.

zzo38computer6y ago

> because you literally can't build a good looking dropdown with normal HTML.

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.

danShumwayOP6y ago

> because you literally can't build a good looking dropdown with normal HTML.

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.

j / k navigate · click thread line to collapse

0 comments

lsalvatore6y ago

zzo38computer6y ago

> because you literally can't build a good looking dropdown with normal HTML.

That I agree. Let the user to override/ignore the styles, or to use them without changing if that is what the user wish.

danShumwayOP6y ago

> because you literally can't build a good looking dropdown with normal HTML.

  <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; }

j / k navigate · click thread line to collapse