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

[shados]

It's not bad at all. You just have different requirements. I prefer React, but if the apps I was working on came to change in requirements, I'd be very happy to have Vue as an option. I don't think having 16 different major frameworks that overlap in functionality is healthy, but having a handful of fairly distinct ones that overlap on some points is just a good thing.

We have hundreds of full sized frontend applications, millions of lines of both javascript and scss. Thousands of extremely complex i/o operations and algorithms. We push the tools in the ecosystem to their limit and have to write our owns where they fail us.

And when I'm at home making a small app, create-react-app and VSCode, then npm install-ing styled-components, is all I need to replicate 80% of the above. It's all just JavaScript so all my tools just work the way I expect them to.

Not everyone needs (or want!) this. And that's okay.

[knowThySelfx]

Agreed. The webside ecosystem is in a high state of flux. It has to be streamlined somewhere. Does it need a fundamental architectural change? Would like to see things a bit more saner ;)