zippy
commented
8 years ago Well, I've read lots of the intro/tutorial to ember, and indeed it looks very good. Most importantly I checked out the people behind it: main guy Yehuda Katz, who I remember from my Rails days. He hads done lots and lots of good and important stuff in that world, so I'm sure it's really well designed. I also caught myself up on embers use of ES6 (latest version of Javascript which includes some cool new syntax, plus Promises, and Modules) which I kind of like.
I'm game to use it for the first few apps we write to see how it goes, i.e for the tree-editor and especially for the compository-playground app, but I think we need to develop the basic tree renderer as a stand-alone js library that has as few external dependencies as possible.
Personally, I'm leaning toward Ember. Let me share the factors weighing in.
The most compelling for me is actually the license. Ember is open source and modular. They make a lot of freely shareable sub-libraries that they've assembled into one complete package for you.
React is a Facebook product where they grant you a conditional license they they can yank back for any reason, in particular, if you have any IP dispute with them (even if they're attacking you about unrelated issues). It would not surprise me if Facebook feels threatened by the Ceptr approach of you having a copy of your own info, and could challenge something at some point. If we've built our UI on tech which they can invalidate our use of, we're kind of screwed.
They're both under active development (with some Ember developers being sponsored by some of the big companies which use Ember: Yahoo, LinkedIn and others.)
React is more lightweight (@140k) but typically needs to be used with other parts of the Facebook engine suite (like Flux) because it is just a view rendering system.
Ember weighs in around 300k but includes the whole suite of tools.
Ember is not an MVC model, but rather a KVO (Key Value Observer) model so we can update the value of some keyed data instance or semantic value and it gets updated across all places it appears. In React you have to manually manage those things in a hierarchy of callbacks for keeping track of things that may be able to be updated (since React assumes immutability).
Given we're specifically looking at using things things for an EDITOR, using Ember which allows 2-way binding so that we can change the things in place and the changes update throughout the stack of their presence and React data is immutable and you have to manually manage layer of data callbacks for editability, it seems like we lose most of the sexiness of using the tools since we want mutability for editing.
I have to admit, I kind of like JSX in React in that it lets you write Javascript that is more like HTML and that kind of flows for me.
But I also like the {{curly brace}} handlebar substitution approach in Ember which is valid anywhere (in JS or HTML or whatever) because I'm already used to thinking of Wagn transclusions that way.
Ember used to be slower, but they released the Glimmer rendering engine a while back that makes it really fast and seems kind of compatible with our delta shipping way of thinking around synchronization, so we might be able to use delta shipping with our UI too.
Also, Ruby and Rails developers apparently feel at home with Ember quickly.
We can just jump in at the level of Ember 2.x.
I've come across a couple other JS frameworks which I might look into, but Ember seems worthwhile at this stage for our Tree Editor and maybe Receptor Layout Connector.
-art
P.S. I initially disqualified Angular because of its overly strict MVC approach which I think would require us to do a lot of maintenance in a non-Ceptr layer rather than carry through semantic hints about UI from Ceptr... but apparently Angular 2.0 has become more flexible and could be worth revisiting.