I wonder how it'll stack up to React Fiber. I love when libraries compete on performance, since it can end up benefiting everyone.
React Fiber is currently just over 70k, and that's just the reconciler, not the complete React package. However, according to Dan Abramov[0] they have not yet focused on optimizing the bundle size either. And Fiber includes some prioritization features that we don't have in Glimmer yet.
In Ember's, there's typically one community-sanctioned library that solves a particular problem, whereas React's tends to have more competing libraries. Like the frameworks, it's a tradeoff betw. customization and strong conventions. Doesn't make sense to compare based on number of libraries. Both approaches are valuable.
TS already supports JSX.
How can this possibly be considered remotely lightweight, especially compared to something like Mithril? I count at least 12 repos on your github that seem to be integral components including a dedicated CLI!
When people say "lightweight" they mean small sizes over the wire. The final size of the production/deployment code. Not the development code.
In the screencast it shows that when you deploy you just get a javascript file for your components that should be super small.
One thing people really love about Ember is that the process for going from nothing to a working app is very streamlined. Typically, this is not the case with smaller component libraries. Personally, I think there's a market for opinionated tools on this side of the simplicity spectrum.
Another aspect of this is that more complex build tools can often do better analysis of your app and move more work to build time, improving the boot and/or runtime performance of your app. For me, I'll trade a longer npm install time if it leads to a better experience for users.
That said, all of the Glimmer packages are distributed as AMD, CommonJS and JavaScript modules on npm[0], with a `module` field and everything in their package.json. While it's not as turnkey as using Ember CLI, I hope people feel empowered to experiment with whatever their favorite build tools are.
Works well for us :)
And the lack of great tooling.
And the lack of a large ecosystem.
And the insane data model.
I regret every moment I used Polymer.
- Tooling is quite good, polymer-cli, gulp, grunt support to name the most common stuff.
- https://www.webcomponents.org/elements - Thats a vibrant ecosystem :-) Big enterprises like ING, IBM, USAToday participate and release their components. (7k developers on slack channel)
- Insane data model? I work with my polymer elements same as I do with angular and react components. If in doubt just use redux/uniflow-polymer.
I get that you might not like it, but the issues you raised here are hardly valid (unless you used 0.5 or fresh 1.0)