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

[knowThySelfx]

Is it bad to write without all these JS tools? We just use Visual Studio and include the standalone Vue.js file. We write plain css (no sass etc) and js with some occasional JQuery. We don't use Nodejs and its build tools (Kinda don't like the complexity all those tools bring. You are more worried about the tooling than the actual problem at hand). We use Ajaxmin and Httpcombiner. That's it for Frontend.

Vuejs is great. Found it to be easy and simple to understand. Big thumbs up for Evan You.

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