The only other thing I like is CSS scoping, though. I think that CSS scoping is a problem in React, and current ideas on how to implement that in React are absolutely horrible IMHO.
Two-way binding is a step back I think, I don't love the name (lots of people will judge a new technology by its name), and the thought of introducing yet another framework is a nightmare.
I'd personally go with Polymer if you like scoped CSS, since it's already established and it's a good project.
I wonder if these ideas can be somehow applied to React, doing precompiling on React components, so that one can continue taking advantage of all freely available React components out there, and keep using Redux.
You don't have to use it – its effects are restricted to the subtree where you've explicitly opted in to it. I've personally found it to be a huge timesaver, and would never go back to a world where I didn't have the option of using it. But you're in no way forced into it.
> I wonder if these ideas can be somehow applied to React
A lot of people have wondered that, including me. Unfortunately, a compiler wouldn't be able to generate a good picture of the structure of a JSX component – because it's 'just JS' it resists the kind of meaningful static analysis that Svelte can take advantage of. I'd love to be proven wrong, but sadly I just don't think any JSX-based framework will ever be able to fully embrace these techniques.
Got it. I've been reading the guide, it looks good.
You did an awesome job.
I'm really scared about trying out yet another framework since I've tried pretty much all of them before settling on React, (and I guess a lot of people will be, too, since there's a new one every couple of months) but I'll try this weekend.
> Unfortunately, a compiler wouldn't be able to generate a good picture of the structure of a JSX component – because it's 'just JS' it resists the kind of meaningful static analysis that Svelte can take advantage of.
Can you elaborate more on this? It seems like passing the compiled JS through Esprima and checking the call graph would give you a fairly detailed structural representation of a JSX UI. You may need to do some graph stitching across module boundaries, haven't tried this myself.
Look at css-module-values [0]. It's not perfect, but it lets you share values between JS and CSS. All values in the file are visible on the imported module.
I think the name will work out just fine (witness MySQL and PostgreSQL).
From looking at the docs, the two-way binding seems entirely optional and I can't find anything that would prevent a developer from using a redux model of state management.
I've got framework fatigue, too, but on the surface this project seems to embody the best of what I love: a tiny API, little magic, and getting out of the way.
Yes, I was thinking whether it would be possible to use Redux. You would need to add some code to hook that up to the components, though.
As for the name sure, but now there's a lot of competition between frameworks, and you want to get all help you can marketing-wise. I might be shallow, but I've not looked at projects a lot of times just because I didn't like the name. I just have no time to make informed decisions, there's too much stuff to look at. I'll see if besides the concept/purpose I like the logo and name a lot of times.
The only other thing I like is CSS scoping, though. I think that CSS scoping is a problem in React, and current ideas on how to implement that in React are absolutely horrible IMHO.
Two-way binding is a step back I think, I don't love the name (lots of people will judge a new technology by its name), and the thought of introducing yet another framework is a nightmare.
I'd personally go with Polymer if you like scoped CSS, since it's already established and it's a good project.
I wonder if these ideas can be somehow applied to React, doing precompiling on React components, so that one can continue taking advantage of all freely available React components out there, and keep using Redux.