[giantsloth]

I agree that single file components are awesome. I wish you had been introduced to styled components in react:

  import styled from 'styled-components'

  const Container = styled.div`
    padding: 10px;
    background: ${
      ({ isHovered }) => isHovered ?
        'green' :
        'red'
    };
  `

  const H1 = styled.h1`
    font-size: 15px;
  `

  const P = styled.p`
    font-size: 10px;
  `

  const MyComponent = ({ isHovered }) => {
    return (
      <Container
        isHovered={isHovered}
      >
        <H1> Hello <H1>
        <P> This is a thing </P>
      </Container>
    )
  }

[untog]

That really doesn't work well with:

> Our designer could churn out neat html/css, but was a beginner in Javascript.

I write JS every day, and frankly that code looks like an unholy mess to me, so I can't imagine what it looks like to a beginner. Is "styled.div``" a function call? It's not self-evident. How do you do inheritance? Is that a template string with functions inside it? Would that CSS autocomplete?

That code looks very much like it sacrifices ease of writing CSS for ease of writing JSX. That isn't the correct tradeoff for everyone.

[giantsloth]

Interesting critique. I would highly suggest checking out template literals: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Yeah styled.div is a function as you can check out in the mdn docs I linked, it's really cool stuff.

Inheritance is done like:

  const List = styled.ul`
    li {
      padding: 10px;
    }
  `

  const HeavyPaddedList = styled(List)`
    li {
      padding: 20px;
    }
  `

If you wanted to just change the li you'd have to:

  const ListItem = styled.li`
    padding: 10px;
  `
  
  const HeavilyPaddedListItem = styled(ListItem)`
    padding: 20px;
  `

You're writing scss within the text blocks. You're correct that you need some understanding of JS.

I've never worked with designers that wrote css, I'd also probably not trust them to do so (my own failings).

I don't agree that it looks like an unholy mess (hyperbole may be lost on me), but I can see how it could be jarring at first look. I had a similar reaction when I looked at Relay (https://facebook.github.io/relay/), when they used literals for data fetching.

[untog]

> You're writing scss within the text blocks.

So, yeah, you lose all the syntax highlighting etc. that comes with just writing normal CSS. I don't think it's unreasonable for a designer to object to that - how would you feel if you were presented with a build system that required you to write all your JavaScript inside one big string statement?

Maybe it's just me, but I don't find it intuitive at all. `styled` has properties for, I assume, every HTML tag? But it can also be called as a function for inheritance purposes? And that inherited call appears to use the same tag as its parent... but what if I want to reuse styles across different tags? How could I define some shared CSS properties I'd use across different elements?

Don't get me wrong, it is cool stuff. But it also feels far too much like hand-wavey magic stuff. I've literally never used Vue before, but looking at this page:

https://vuejs.org/v2/guide/single-file-components.html

I have zero confusion about how to write styles for it. And I really don't understand why styled-components would be worth the extra effort by comparison. What does it bring to the table? It's different without a compelling reason for being different.

[shados]

> So, yeah, you lose all the syntax highlighting etc. that comes with just writing normal CSS

Except you don't. Editor support is quite good, and syntax highlighting, syntax validation, auto-completion, etc all work.

I mean, same way with Vue really. If the editor didn't know wtf a Vue file is, you'd lose all the integration too.

[untog]

> I mean, same way with Vue really. If the editor didn't know wtf a Vue file is, you'd lose all the integration too.

In a way, that's fair. In another way, the example single component Vue file I linked to is an HTML file. It has a <script> tag and a <style> tag. Just associate .vue with HTML and you're done.

That gets to my broader point as well - styled-components reinvents the way you declare styles and the way you apply styles, and requires the entire thing to be written as a JS file. And for what? I still don't understand what the advantage is over a syntax everyone already knows (and has validators for already!)

[shados]

If you remove styled-component specific tooling from the equation to simplify the argument and just use Glamorous instead of styled-components (which are very close to the same thing except the later is just JS), then it's exactly because of tooling.

The reality is that tooling for templates (even Angular or Mustache style) is pretty terrible. Tooling for CSS is just as terrible. Static analysis or doing simple things like interpolation of data is pretty darn bad.

But JavaScript tooling isn't half bad. It's not the best there is, but its still reasonably advanced. Thus you have React, which is basically just JavaScript and objects. Sure JSX, but when used in React, it's just sugar to define those objects (hyperscript would work just fine too if you don't want to use a compiler, and early on in React's life just creating the objects from factories was just fine. Certainly better than weird templates with bad tooling).

Once it's all javascript, everything works: my linter works (and is certainly more advanced than css linters), both major type systems work, my refactoring tools work, and I have all the language at my disposal without learning anything new to do stuff like conditionally showing or hiding things. No need for an ng-if, v-if or whatever.

The same logic keeps going with styled-components. Associate the styles with a plain old JavaScript object, using javascript constructs (in this case, template strings), and all the tooling to manipulate them, interpolate them, or type check them just works (eg: TypeScript isn't bad at typing interpolations in template strings). And if that's not good enough, Glamorous is just objects so it's even easier.

Now I mentioned both styled-components and glamorous...normally this logic would heavily favor the later, but for some reason, tooling for styled-components have gone above and beyond to make up for the shortcomings of template strings, so it ends up working better for me.

Maybe someday some very motivated people will make tooling for the non-JS parts of ecosystems that are not "all JS", and this point will be moot, but right now the React ecosystem is the one that lets you most heavily lean on tools.

It's probably why it doesn't look so great from a newcomer perspective though: if you're not at a point where you're trying to squeeze every last bits of power from the tooling ecosystem, then it's just overhead and a waste of time.

[threatofrain]

I would argue that the right boundary for designers to be working with front-end people is via central company style assets, and not at the component level where ad-hoc styles should be stored.

It seems a little odd that the front-end designer, who is in our hypothetical not comfortable enough to actually work on component themselves, would be brought in to tag-team with someone else who also doesn't feel comfortable enough to do the work themselves.

[sametmax]

God this is horrible. It's ugly. Hard to read. Things are scattered all over the code. And where is my sass ?

[mottomotto]

I much prefer putting the styles in a separate {componentName}.scss file, import'ing that into the component and using the Webpack Extract Text Plugin:

https://github.com/webpack-contrib/extract-text-webpack-plug...

I guess now you have two files per component but to me, it's well worth it.

[onenite]

You can work with two files per component if you must truly put the styling in another file.

One of the boons of react is that you can create a set of reusable base components that can be built upon throughout your app.

If you can code-split the app, lazy-loading components as needed, and if you can cache all of the static app anyway, why does it matter if the presentation is tied to the logic?

The same can be said for vue.js. :)

The two languages have many merits and they both make their own sacrifices. But they are ultimately two peas of a pod.

Like Thor and Loki. But who is Thor and who is Loki? ;)

[giantsloth]

It doesn't support sass, but it does support scss.

[allover]

To all intents and purposes, when people say Sass, they mean Scss.

[jrobn]

Code like parent comment is why I use Intercooler.js [1].

[1] http://intercoolerjs.org

[agumonkey]

Cute ideas in there. Much appreciated

[NumberCruncher]

It is a good example for solving problems without overengineering them.

[snarkyturtle]

There is the Vue equivalent though: https://github.com/styled-components/vue-styled-components

[nikcub]

Why do packages like this need to be ported or re-implemented for Vue rather than referenced? That package hasn't been updated since August while the root styled-components library has ~700 closed issues and 11,300 watchers

I've seen it with other stacks as well with almost complete re-implementations, a lot of duplicated effort and it feels like it goes against the packaging philosophy for javascript

[kimjongman]

ugly piece of code