How does it compare with vue.js? I never worked with any modern JS framework like this but on paper I did not like writing CSS in javascript and vue.js had a normal way to write CSS and to me it looked superior in other ways as well.
Edit: for the record there's nothing stopping you from using CSS files with classnames on your tags as usual, but libraries like styled-components allow you to easily scope and collocate your CSS with your components.
What was your objection to writing CSS in JS? It would seem like a fairly trivial syntactic transition to go from one to the other? It's just selectors with a dictionary of properties right?
Writing CSS in Javascript brings back memories of pre-2000 web development, table based layouts and more horribly inline styles inside HTML tags. CSS was a breath of fresh air, it meant separation of concerns.. HTML the content and CSS the visual representation. With the advent of jQuery it allowed separation of behavior as well.
With frameworks like React these days, content+behavior is in JavaScript already, and with writing CSS in JavaScript, we've gone back 1.5 decades I think.
I had this same initial reaction, but concluded as others have that this architectural approach was not actually a separation of concerns but merely an unwieldy separation of technologies: http://blog.andrewray.me/youre-missing-the-point-of-jsx/
When you start thinking in components it becomes much nicer to have the styling, logic and layout all in one file, isolated from the rest of the application and easy to edit, move around and apply to any page.
The previous 'best practice' of having these coupled aspects in separate files now seems quaint and tedious.
There are of course trade-offs, and CSS-in-JS has not triumphed yet, but if you've held off from considering this approach simply because you've had 'separation of technologies' drummed into you in the past you might be missing out.
CSS isn't separation of concerns, it's just separation of filetypes. The problem with inline styles was that you had to repeat them all over the place. This is not the case with Javascript, since it's a programming language and it has an import system. I feel like the sentiment that JSX and JS CSS break separation of concerns is cargo-culting what separation of concerns is all about and why it's useful.
My objection is. I already learned how to write less and then later switched to SCSS. I like the syntax because its basically CSS and I do even avoid heavy nesting taking bootstrap as a good example. I use atom and scss-lint (now deprecated but still works great) to live lint my SCSS in Atom and spot errors and that includes order! Can I do this in CSS that is embedded into stupid react files that mix JS logic with the visuals? My guess is there is probably something out there where I can do something very basic but not even close to real feature complete linting. And yes, I don't think style and logic should be mixed together. What about autoprefixer ... how do I do all my SCSS/CSS processing if my CSS sits in JS files?
The style I like to use is the css/scss webpack loader.
Basically, you import a .scss file into your .jsx.
The scss is compiled and at the same time imported into .jsx as a hashmap where the key is your scss class-name & the value is the compiled class-name. I think this sounds like what you're looking for since it keeps jsx & css in their respective files but still being coupled into their own component which is easier to reason about.
Vue is much, much faster to load; it is possible to use vue applications over 3G where React apps choke. Vue is also, in my experience, much easier for back-end developers to contribute to without making app-braking performance mistakes. It has a canonical event-driven store, Vuex, with much nicer debugging tools than any of the flux frameworks (it includes getter values, for example). I have also found the error messages more meaningful across the ecosystem; React can sometimes produce very unhelpful errors.
What it lacks is some of the maturity. For example, dynamic loading of assets only works if they are static and the cli isn't trivially deplorable. It is also less standard among front-end developers, which mostly comes through in the selection of libraries available (Vue is close enough to vanilla templating that the learning curve is shallow.)
>I have also found the error messages more meaningful across the ecosystem; React can sometimes produce very unhelpful errors.
Can you file an issue next time? We're happy to fix confusing errors.
>much, much faster to load
I would love to see some data backing it up. I thought they are roughly in the same ballpark with Vue having slightly more built-in APIs but I might be wrong!
I haven't profiled vue and react on this particular benchmark, but I have done so for some of the other implementations. Baring anything exotic during startup, the 'startup time' benchmark comes down to package size. It takes time to fetch, parse, compile and load javascript. React is just a bigger package.
All disclaimers about benchmarks, microbenchmarks, n=1, YMMV, etc apply.
I switched my complex app from React to Vue and the speed difference wasn't really noticable. Also, React had far better error messages. Vue's are often useless. This is actually the only thing I miss about React. Vue has been a better experience in every other way.
What I don't like about Vue is that it still has a clumsy templating pseudolang, whereas JSX lets you do what you need to do with inline JS statements.
