Glimmer is smaller and faster than React, with TypeScript supported natively. This is a game-changer for people who are looking for a lightweight rendering library that ships with great tooling support and a larger framework ecosystem behind it.
The Glimmer runtime is under 30k, and we have not done much bundle optimization yet so hopefully this should go down a little bit even further.
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.
I think Glimmer/Ember have lost already. React is fast enough for most things and then there is Infernfo and Preact that are faster right now.
If you mean a larger ecosystem as in number of libraries I would guess that the react ecosystem is 10x the size of Embers.
From my experience, the ecosystems are qualitatively different.
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.
React-lite is 25kb, it gets there by stripping off proptypes and some other things without, sacrificing functionality, so it can always be applied as a production alias. Things like Preact and Inferno compat go even further, you can bring React down to 5kb or less. With React Fiber it will be easier to create modular packages that contain specifically what the app needs.
The install parameter you provide already requires yarn and the rather large ember-cli, in addition to requiring my app to be built on top of glimmer instead of with it.
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!
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.
You shouldn't be deploying a CLI into production. While I haven't looked closely at this particular system, guaranteed you are not deploying the CLI. Just using the CLI to create deployable code.
When people say "lightweight" they mean small sizes over the wire. The final size of the production/deployment code. Not the development code.
TheAceOfHearts|9 years ago
I wonder how it'll stack up to React Fiber. I love when libraries compete on performance, since it can end up benefiting everyone.
tomdale|9 years ago
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.
https://twitter.com/dan_abramov/status/844223224732958721
jbergens|9 years ago
maxkwallace|9 years ago
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.
mlsarecmg|9 years ago
TS already supports JSX.
vorpalhex|9 years ago
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!
tomdale|9 years ago
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.
[0]: https://www.npmjs.com/org/glimmer
nkristoffersen|9 years ago
When people say "lightweight" they mean small sizes over the wire. The final size of the production/deployment code. Not the development code.
EvilTrout|9 years ago
In the screencast it shows that when you deploy you just get a javascript file for your components that should be super small.
lyime|9 years ago
boubiyeah|9 years ago
Works well for us :)
ergo14|9 years ago
JeremyBanks|9 years ago
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.