Seriously, Ember philosophy of slowly aggregating what's good in web dev and even adopting early some things (like components, and cli) makes me feel very good using it in projects with teams. For solo projects I like to try what is new.
I'm a big fan of React, but I agree styling is a mess.
CSS in JS has many limitations and virtually every alternative adds either another library or some other convention/configuration overhead.
Other frameworks struggle with this as well but it feels like React really shrugs off styling as the community's problem and subsequently there's a hodgepodge of solutions that work in this or that scenario but no gold standard.
I've been doing SPA's in react for a while and have had 0 problems whatsoever with styling. As long as you stick to good standards and naming conventions and use SASS or Stylus or something to keep things organized.
What tends to give people so much trouble with styling?
Isn't that part of the React mantra? Everything is completely unopinionated except for rendering HTML based on data? Like it makes no opinion on how you should do state or HTTP requests as well as no opinion for styling, which is something I love since it avoids duplicating code or incompatibilities with standalone libraries.
It sounds like an interesting but probably relatively common situation these - relatively experienced developers, but inexperienced where it comes to the front end, who are accustomed to working in a non-javascript language. In this case, sounds like it's python.
Sounds like their senior developers, who previously worked in Python, will now be doing at least 50% of their work in javascript.
If you have to do this, it sounds from this article that Ember is a good way to go. On a related note: I'm so bummed that this is the trend in languages. Just so bummed. Python and Ruby are really nice languages. To have to switch from that to Javascript feels like a big step back in developer happiness.
Very interesting, I read a bit about it. Up to now, I was mainly watching systems like volt. A bit too cutting edge for me right now, but I love what they're doing. I'm hesitant to make tech predictions, since what usually happens is something you didn't see coming all, but I'm still figuring transpiled ruby/python/whateveryoulike to javascript will emerge.
I'll dig more into webassembly when I get the chance.
That'll probably never catch on. Front end dev already have 10 frameworks and 5 browsers to worry about. Let's not add 10 more languages for a total of 500 different combinations.
Make sure they are using Typescript/ES6. JavaScript still has some oddities in behavior but I actually prefer some aspects of the language design now compared to python.
It sounds like an interesting but probably relatively common situation these - relatively experienced developers, but inexperienced where it comes to the front end, who are accustomed to working in a non-javascript language. In this case, sounds like it's python.
I'm a very experienced Front-End developer and a lot of the tooling questions still hit us in the ass. A few years ago we switched from a Backbone framework to React based with Reflux and Browserify. Within 6-8 months the mindshare switched to Redux and Webpack and now we're on to those. But its days to weeks to gain full understanding of those (Webpack is a slog) Unless your constantly keeping up to date every time you start a new project right now you're back to the drawing board on the current state of the React ecosystem.
I love React, I'm bullish on React-Native as well for a lot of use cases. I'll be happier once the community starts to lock in a bit better on a more consistent stack and I'm totally okay with their choice of Ember (curious on why this over Angular if they're doing a follow up ;-)
If you started with React a few years ago, then React would have been brand spanking new, so change shouldn't have been too surprising then.
The question is, have things stabilized now? There's some evidence it has: Redux & Webpack have had the mindshare for almost 2 years now. But a lot of people now recommend mobx over redux, the redux plugin situation is still evolving, react-router seems to have finally got things right with version 4, et cetera.
That being said, I think the above sounds more pessimistic than it really is. For example, redux vs mobx is really two different use cases IMO.
I imagine packages that bridge react components with redux (react-redux, react-router-redux, redux-forms, redux-immutable). But I'm not sure to be honest.
> For example, redux vs mobx is really two different use cases IMO.
I wouldn't go that far, I'd say it's different ways of thinking about the same problem. Crucially, switching out your Redux stores/sagas for MobX stores should be a drop-in replacement for the most part. Actions are still actions, and stores are still stores. The only/main difference is that for MobX a reducer and an action are the same thing.
> To have to switch from that to Javascript feels like a big step back in developer happiness.
That's why we use TypeScript.
I've been using Python for well over a decade and despise Javascript. TypeScript is incredible. React is pure goodness. React + TypeScript is really cool to work with and doesn't feel like a step back in dev happiness.
Of course I miss the Python ecosystem there, but the JS ecosystem itself is improving thanks to Facebook mostly (yarn...). At this point the main complaint I have in that ecosystem is the three layers of transpiling which are causing backtraces to be unreadable.
Also, I'm unhappy about Python's half-assed move towards not-really-static typing. Optional typing is, and has always been, where it's at. Did I mention I love typescript?
> On a related note: I'm so bummed that this is the trend in languages. Just so bummed. Python and Ruby are really nice languages. To have to switch from that to Javascript feels like a big step back in developer happiness.
Speaking as a Python developer who needed to pick up JS and maintain two Ember codebases this year, getting to know JS has actually been a pleasure. I was dreading it and I cursed it for a while. But using ES6 with Ember has been... pretty nice. There are objectively bad parts of it - some that are historical baggage, others that are just unfortunate (undefined and null!!). Oddities aside, I find it nimble and fun. I like Douglas Crockford's characterization of JS as "a LISP in C's clothing".
Hey everyone - OP here! This was a really fun blog post to write and I think I learned a bunch in the process: if you have any questions, would be happy to answer!
FTA:
>When evaluating Ember, We were excited that with ember-data there were established patterns for how to do things — even if some of those patterns felt a little outdated.
Could you elaborate a bit on how the ember-data patterns felt outdated?
Absolutely! I would say that with Ember + ember-data, the framework conforms to a pattern where data is represented as models on the frontend, which can be updated and persisted to the server. These updates happen through a CRUD / REST API (in our case we conform to JSONAPI) and are generally triggered in a controller (or a route that contains logic and acts similar to a controller in a traditional MVC framework).
In the React ecosystem, I think there's been a pretty stark departure from that general pattern with things like redux and GraphQL, so while we love it, compared to what we'd been using , it felt a little behind.
The article should have been titled 'ember tooling vs react tooling' I guess. The explanation is only about the tooling rather than the framework. Good write up though. Intriguing to try Ember this weekend!
Thanks for an interesting writeup. Something I'm curious about for devs who've used ember on projects that had a maintenance period of 1-2 years: how do you feel about it as your app grows and changes over time?
With most kitchen-sink or CoC frameworks, this is kind of the achilles' heel. patterns get codified because they're easy and "good enough" but they DO NOT age well. How does Ember deal with this? Also, what about the ecosystem? Is Ember work driven almost entirely by the core framework, or is there a plugin ecosystem that attempts to have an answer for every problem? (yes Rails, I'm looking at you.)
> how do you feel about it as your app grows and changes over time?
There was a lot of breaking changes in Ember going from 1.x to 2.x but now api is stable mostly.
You need to remember that Ember is very opinionated, that's why maintainability is a lot easier over the time. There is only "Ember way" in most of the things (routes,templates,components etc). I have now around 130-150 files in my Ember app and what is a little iritatin is that routes, controllers and templates are in different files by default if you use ember-cli (you should with ember, it's great, really great tool, one of strengths of ember).
> Also, what about the ecosystem? Is Ember work driven almost entirely by the core framework, or is there a plugin ecosystem that attempts to have an answer for every problem?
You can build full app (with routing etc) without using any plugins at all. But there are a lot of plugins on github that you can use if you need something special.
I started on Ember around the 1.12 timeframe and left that job about a month ago and we were on 2.6. There were a couple hiccups going to 2.x but nothing more extreme than I've experienced with any other major version update. The Ember team also does a stellar job providing useful deprecation notices and not breaking any minor version update, i.e. if you're on 2.1, you can upgrade directly to 2.6 and be reasonably confident it'll still work. Your console might get flooded with deprecation warnings, but they helpfully link to the release docs for the change.
The only thing I'm not a huge fan of is their JSON-API as a default data adapter, since there's a ton of immature JSON-API server-side libraries with varying levels of spec compliance and completeness. If you're backed by Rails, you're in good shape. If you're backed by Java, you're fairly fucked.
I'm developing and maintaining an Ember app which is nearly 5 years old. Some of our app code dates back to 2011 (when Ember was still Amber.js).
Remember how much the Javascript ecosystem changed in 5 years? There is no way we could have maintained the same code base without Ember; we would have needed to rewrite the app once or twice by now. And with each rewrite small features, little subtleties would have been lost, replaced by some bike-shedding about how we should hand-compose an entirely new stack.
Instead, we upgraded quietly from time to time, and kept all our carefully tuned code and beloved UI tweaks with us. To be honest, the maintenance and version bumps took quite some work, and some early upgrades required heavy refactoring. Ember paradigms changed frequently during the pre-1.0 era, and later React clearly influenced the best practices recommended for Ember 2 (like Data-Down Actions-Up, etc).
But boy is it worth it. Ember-Data is neat, the testing tools are great, the Ember-Inspector add-on is a joy, and the CLI tools gets us so many free features. And we never could have maintained this product without a stable framework across all these years, and the friendly developers community.
Also, to answer your question about add-ons: they're great. Among the core team there is a nice commitment to make many new features available as add-ons (rather than baking them into the framework). And the community solves many common problems for you indeed.
I've been running a large ember app since the pre-1.0 days (2013). We made a few bad choices early on in how we structured our data models that were not the "ember way" and took a while to sort out, but overall it has been smooth sailing. The 1.13 -> 2.0 upgrade wasn't too bad, and the 2.x updates have been painless.
At this point they're pretty good about issuing deprecations a version before they make breaking changes, so upgrading just involves bumping the version and fixing any deprecations that come up, to prepare you for the next version.
They have been pretty aggressive about ensuring addons work with the latest version; you may have issues with newer addons if you're stuck on a very old ember for some reason. `ember-try` is great for running CI against all ember versions.
Have used Ember since early 2012 (just when it transitioned from SproutCore). Fairly large application (~80 routes, ~60 models).
## Stability
Overall very well, we've never done any rewrite (apart from a coffee-script -> JS conversion, but that had nothing to do with Ember).
## Updates
Upgrades has been easily, except for the early days. But since 1.5 or so it's worked really well.
## Addons
There is a lot of power in the Ember ecosystem, but it also stays away from some things (widgets etc) which I think is great. For, say, a date-picker you'd use an addon (https://www.emberaddons.com/?query=date) or build something yourself.
## Progress
Despite having used the framework for several years it's still very modern. Ember has done a good job of keeping up with new technologies without causing unnecessary pain for developers. ES6 modules, good alignment with web-components, ES6 classes, modern tooling etc. None of this wasn't in place in 2012, but Ember has managed to bring it all on board without causing upgrade issues or painful breaking changes.
Ember is a really good choice for running a feature-rich web app where you want to focus on business and features instead of solving issues about tooling and deciding on which pieces to bring into the bundle to make everything work. This is especially crucial for small teams on a budget. Also, upgrading to newer versions is incredibly easy, deprecations paths are very verbose and clear. I've been working in Ember for three years, and a few times in between I jumped into React. I adore React's ideas, and grasping its concepts made me a better Ember developer. It's just React tooling that's horrible, but I hear there are great improvements in that area.
> Ember is a really good choice for running a feature-rich web app where you want to focus on business and features instead of solving issues about tooling and deciding on which pieces to bring into the bundle to make everything work.
I came here to say exactly this. Ember is a fantastic choice and it doesn't seen enough love on hnews.
It's got a bit of a learning curve, but once you climb it then it's plain sailing.
I feel like the Ember learning curve is a lie these days. The documentation is so good that you really shouldn't have trouble with _Ember_. But, SPA's have a learning curve that you might not realize if you just create one React component.
The fun thing about Ember.js is not wasting time learning lots of tools :-) you can start on the guides [1], and if you have any problems get to #help channel on the Ember community Slack group[2].
Also checkout Ember twiddle [2] to play around first without installing a thing. You can add libraries and even other Ember adding through twiddle.json
I've been keeping an eye out for a project on which to use Ember. Unfortunately, I've been in that exact mode for literally years. I already trust that it's solid stuff from having learned a load about software development from Yehuda back in the jQuery days.
Three or four times I've been about to pull the trigger and every time the things that's stopped me is that when I go to look for a sample project to have a read of an actual app using it in anger it seems impossible to find one that meets my criteria: 1. Uses current version of Ember. 2. Uses idiomatic ember. 3. Big enough to not be a toy, ember-data, being the recommended way of doing things, I want to see how it's formatted.
Every time a look it seems like everyone is saying something along the lines of "Here's a good example project except it's N versions old." or "… except it doesn't use insert-feature-that-docs-heavily-recommend-using because that wasn't around when this project started" or "… it uses local storage in place of a database".
I've read the documentation end to end multiple times over the years. I'm not sure why that's not enough for me. I just assume I'll run into trouble and I'd like to see an application with routing, component composition, backend calls, and understand a bit about the recommended backend before diving in.
It helped a lot to see it in action. I got lot of help from the Ember Global Meetup[1] and live coding with buddies at the Ember Community Slack group.
Alternatively, go to ember observer [1] to checkout the demo page of some of the top rated add-ons. This works because it show cases the best stuffs in the ember ecosystem. Secondly, addons has to be kept up to date with latest Ember in order to attract more users.
I'm a big fan of Ember, although a word of warning: To get the most out of Ember you should follow the Ember way of doing things, we found our selfs wrestling with Ember data, and APIs that don't follow standard responses (this is to be expected mind)
I agree with this in principle, and I feel the same way about Rails (also heavily convention-over-configuration). But do you also dasherize the JSON keys in your server back-and-forth, as recommended by JSONAPI? That strikes me as such a strange recommendation. It is incompatible with Rails parameter handling, and it prevents them from being Javascript identifiers also. I don't get it!
Interesting. In my experience the clean separation of layers in Ember-Data (network, serialization, models) make it quite suited to non-standard APIs. I found writing a custom (de-)serializer for a non-standard API to be relatively easy.
Care to elaborate on what were your issues precisely?
Not OP, but it's possible to not write any ember-data code if a server implements json-api...
Otherwise, you have to write the same code that you have to write in other places... except that w/ Ember Data there are core patterns and its easy to add tests.
Writing Ember against an API that speaks json-api is a magical experience :-D
Also curious about this. For reasons that our team was personally against, we had to devote some serious upfront development work to building an integration with a WordPress backend and the rest of our Ember front-end (which consumed, thankfully, a JSON-API spec backend). We wrote custom adapter and serialization layers for this, which was trivial; the only exceptions to the ease of writing such code was when the WordPress developers would return bizarre status codes or missed root objects or some other such nonsense.
I don't think I have a strong opinion about Ember, though you can take the React rendering model away from me when you pry it out of my cold dead hands. But I think I object a little bit to the way they complexify the React stack:
* ES6
* React
* redux and redux-saga
* react-router
* fetch
* lodash
* webpack
* post-css
* karma/mocha/sinon/chai
Of all of these things, to build a decent React app, you only need React.
It seems chintzy to bill React for the cost of webpack/browserify. I understand why someone would: it's the worst part about working in modern Javascript environments. But it's a build tool, not a library.
You Don't Need Redux. Most applications that use redux (or any other Flux library) probably shouldn't. Even redux's author has been taking pains to point out how overused redux is.
You definitely don't need react-router, which is an inner-platform disaster.
Billing React for fetch and lodash also feels chintzy (especially when you try to add a surcharge for switching from underscore to lodash).
I'm also not clear on how ES6 is somehow React's problem. Ember developers use ES6 too. Because ES6 is better than ES5.
I'm not saying the Clef team is wrong. If they're happy with Ember, God bless them! I'm just wary of tech advocacy articles that try to make these kinds of stack complexity comparison arguments; I usually find them to be pretty dubious.
I think this is a fair criticism and I agree that I might have used this comparison in a simplified way to make my point, but I think the primary thesis still holds: when building a React app, you necessarily need to make a very large number of choices that you don't need to make when building Ember.
This isn't because React is bad, it's because React is just the view layer! If we look at it this way, we can re-examine that list as:
* language
* view
* data modeling
* routing
* network connections
* functional utilities
* build
* styling
* testing
And, with React, when you have just a view layer, if you want to build an advanced application, you likely need to add on a bunch of other layers to get everything working. I hear you about being able to "just use React", but I also think that's a an oversimplification the other way: how many applications on the web today are built with only the view layer and none of the others?
After evaluating all the decisions we made in the past when building a React app, we decide to trust someone else to make them for us :)
p.s. the original title was "Choosing Ember of the React ecosystem in 2016" but I ended up shortening it :)
Ok, and fair enough, but a simple question as a response: am I required to buy into the idea that I need a library to cover all of these cases?
Any attribute of constructing an application you break out, people will build libraries for. But are they necessary? In some of the cases we're talking about --- routing and network connections, for instance --- the answer seems to be a clear "no".
Right there with you on this, love react's rendering model. Redux seems to get all the hype but I'm sort of beginning to suspect it might be mostly the wrong way to do things. It reminds me of TDD, most of the benefits seem to be moral in character rather than concrete.
I've been using Redux for the first time lately. It may be conceptually elegant but in practice it's really a mess. In order to do any real work with it you have to pull in something like redux-thunk and then all your fancy state management tricks go out the window. I would go so far as to say I consider it an anti pattern outside of some very specific use cases.
I intend to try Mobx sometime soon but I've also found you can go very far using stateful vanilla React components and no third party state libraries at all.
Wow, this is great. It's good to hear an considered opinion piece that lays out good and bad points of the technology, especially from someone versed in a different space.
Assuming 1 login/day and 85k/year annual employee cost (practically a joke, especially in the Bay Area) and 250 work days/year, it comes out under 3 bps (0.03%) of the employee cost. Probably not crazy for two factor, vs distracting yourself from your actual business goals?
I like the author's focus on results and team productivity. Standardized tools are key for that. This is also my main concern, when it comes to JavaScript frameworks and libraries. While Ember seems very good at that front, when talking about a single project or multiple very similar projects, I would like to add another point:
As soon as you are working with different platforms (the author mentioned WordPress), you should not necessarily integrate everything all the way up. Because now you have your Ember based build process and maybe something gulp-based for WordPress.
I always try to find frameworks, which has all the things only concerning itself integrated into (say server-side rendering etc.) but then stops there and makes use of preferably the two or three leading tools (e.g. grunt/gulp plugin) for all the other concerns.
That way you can choose a standard stack and only consider new frameworks if they work reasonably well with it.
Note that you should not choose Ember if you are creating an app intended to be used on mobile, as it doesn't yet have code-splitting. This talk explains about why this is a hard requirement: https://www.youtube.com/watch?v=4bZvq3nodf4
That doesn't help much. Server rendering means the user can see something, but if the browser is executing a 2mb blob of JS and it takes 3 seconds to do so you get major jank.
It isn't just worse on Android it is BRUTAL on Android.
I was deeply unhappy with the 3x-5x widening iOS and Android JavaScript perf gaps through 2014 and 2015 (TL;DR Qualcomm has completely lost the plot) but in 2016, it's.. even worse.
The good news is, Ember 2.10 looks like a major speed improvement! The bad news is, Android is still 10x slower with Ember.
I cut my teeth on Ember at a marketing company in 2013, and actually found my current job through acquaintances made by attending a weeklong Ember training session in Boston (led by yehuda and tom). It had been a great fit for me at the marketing company because the apps I was developing were more restful oriented crud apps. apps with a lot of routes that were more or less their own thing (not too much shared state).
The company that I joined was using Ember, but their app was more of an analytic dashboard and it didn't really have more than a handful of routes. the amount of views and logic and state that lived on each route / controller was insane. Also, between the few routes you really needed to share state and things got very messy. I'm still with the company today, and the app's routing is still controlled by ember, but we have switched entirely to react + redux and are a lot closer to being off ember completely.
The real boon for us has been the single source of truth and the connect function from react-redux. Basically any component can just declare the data it relies on via store query functions e.g. getLabelsForUser(state, userId), which breaks you free from the uber painful process of passing properties down the entire view tree to child nodes.
I also got a lot better at developing when I started developing for react, because I was no longer writing framework code, I was writing and utilizing my own functions and abstractions.
I'm not saying ember is inferior, but of course there are trade offs to both. I absolutely love yehuda and tom, they are so prolific, but I would be interested in seeing how ember apps fair when there are only a couple of routes but a ton of view logic and state; where does the state live and how is it coordinated. How do you coordinate data across the app hierarchy? Asking because I really failed at that 2 years ago and ended up with a mess, it definitely felt like uncharted territory. Would totally accept developer error.
I have a pretty fair amount of experience with both Ember and React (along with Ember Data, Redux, Redux-Saga, React Native, webpack, etc etc).
My opinion, for whatever it is worth, is that Ember might be good for smaller companies and smaller codebases. The cognitive overhead of using Ember is massive for me and several people on my team. I find that I have to store the contents of many files in my head at once to understand how a given component is being rendered and how it is receiving its data it requires. Your view code is implicitly coupled to promises all over the place which can really bite you in the ass. Mutable APIs abound and it is an extremely unpredictable and volatile way to develop web applications at our scale.
My personal, largely unfounded belief (based both on intuition and anger from dealing with Ember) is that the supposed gains from Ember's severe convention-over-configuration ideology don't pay off nearly as much as is advertised.
I never want to work on an Ember project ever again.
I grumpily ignored the comments about mobx for a while, then finally broke and used it on a small side project. The results were...
...disheartening. Because (at least for my team and the specific projects we do), mobx was much much better.
(Disclaimer: We use React to incrementally replace/upgrade pages and panels in a very large admin console. So we have a ton of very small apps that share a lot of concepts, but are still distinct apps. Obviously this multiplies the amount of boilerplate we have to deal with compared to if we were using a single "monolithic" SPA.)
Key advantages:
1) Way, way, way less boilerplate. With redux you soon grow used to the dance of adding a new sub-reducer, a new batch of constants, a new batch of action creators, then wiring up the new action creators to your container, wiring up the new state sub-trees to your container, and boom, now you've got some props that represent your data, and some functions you can call to change that date.
With mobx, you add some new observers and (optionally) some actions to change those observers and...you're done. It feels odd at first; when you're used to redux you're used to setting up a new app (or coming to grips with an old one you haven't touched in a while) as a very elaborate process. With mobx the "skeleton" is done before you even really start. It's almost worrying.
2) Redux has some very specific ways it wants you to structure your project, and some of them are quite good. A junior dev might struggle to grasp what's required to set it up from scratch, but I think for an intermediate dev it can be quite helpful. It strongly forces you to make some good choices about data flow, seperation of concerns, logging, etc. But for a senior dev it can be a little...limiting. I actually know what I'm doing, and sometimes the right answer doesn't 100% fit into the Redux way of doing things, even if the "redux way" is great 95% of the time.
Mobx allows a lot more flexibility. I suspect that could be a drawback in some cases too, but for this particular case, it's quite nice. You can actually implement a number of different patterns on top of mobx, including a redux style state tree, or (as we've done) some Backbone/ActiveRecord style models. Which obviously have a lot of limitations and are great for everything, but are really great for our specific use case.
3) On a related note, redux really needs data to be normalized; you end up devoting a remarkable amount of time to normalizing data (using normalizr or whatever) and then de-normalizing it in your components to handel relations properly, and then figuring out how to modify your normalized state tree in your reducers based on actions triggered in your denormalized component tree. Totally doable, but a pain.
Mobx makes it easy to use references, avoiding the entire issue.
4) Closely related to the last two points, components written with redux in mind often end up with very extensive lists of props, because they end up needing a little bit of data from six different reducers, plus a dozen action creators. It works. It's fine! But...
...with mobx, at least the way I'm using it, you can generally get away with just passing in the relevant model, You keep ending up with situations where you pass your ProductList model into your ProductList component, which maps over the Product models it contains and passes them into a component called Product. Your actions are just methods on the model class. Components with 1-2 props are easier to reason about and (in my experience) easier to test.
All of which is basically just 4 different ways of saying that for me, it lets me type a lot less (which is good), but most of all it lets me think more about the problem I'm trying to solve, and less about the libraries I'm using (which is key).
Thanks for the taking the time to write this up. I'm using redux for the first time and I really hate it. It may be the least DRY state management approach I've ever seen. This will be helpful in convincing my colleagues to give mobx a try on our next project.
What do you hate about Redux? I went from Flux to Reflux to Redux and it really makes state management easy from my experience. You should give the idiomatic redux videos at egghead.io a try: https://egghead.io/courses/building-react-applications-with-...
I looked at mobx, but it did not appeal to me at all. Lots of ceremony (observables) to eliminate a small amount of typing. The power of Redux is that it works in an extremely simple way and you can hold the operation of the framework in your head along with your app.
Redux is just a big switch statement that ingests plain action objects and outputs a modified state object, along with a connect function to bring parts of the state object into your components. Mobx looks quite baroque in comparison.
I've worked on 2 production Ember apps. The first was a nightmare because there were 2 way bindings and the team that built it didn't know how to use the router.
The second was a dream because we built it after a couple of years dealign with the fallout from a bad ember app (plus "data down - actions up" was now the prescription).
Ember can be really nice if you follow the happy path.
I completely echo this sentiment. I like Ember, but have found that the learning curve of a React/Redux app is significantly smaller than that of a similar Ember app.
Small sample size for me (2 Ember projects, 6+ React projects), but the entry level engineers to the senior level engineers seem to grasp React/Redux MUCH faster than Ember.
Care to elaborate what that scale is? We're using ember for a new app that expects very large traffic volumes on continual basis with realtime components etc... I've worked with ember for the past few years and opted to use it but always interested in hearing other viewpoints esp for "high scale"
Parent may not be talking about scale in terms of Traffic but big project code-base where you and team have a hard time keeping something in head and how something is being rendered.
Ember seems really cool, but I've never had anything big enough I've wanted to use it on. In fact, I have not used a JavaScript framework for a while (unless you count an Ionic app a few months back. Ember's learning curve seems a bit steep too.
I don't have much experience with Ember, but I have a spent a lot of professional time with React development, well over a year now. Initially I quite loved it but that love affair is over.
My problem with React aren't complaints about front-end tooling and build systems. My problem with React is its emphasis on a tree like relationship among components. This is an unnatural paradigm for application development. Certainly user interfaces can be thought of in the form of a tree, but another way to think about application development is to consider the view a canvas, with areas to fill in.
React's strong tree type architecture makes some forms of common user interface development feel unnatural and ungainly, things like modals, toasts, or things that just don't fit into a neat little area of the screen in a sibling child parent relationship. Also anything that happens after a render, like animation, also has the same kind of unnatural cludgy development process and I often have found myself fighting what to render when with shouldComponentUpdate.
I'm not saying these things are impossible or even hard, it's that they're unnecessarily ungainly when those things should be simple. I've also think in practice that components far down the React tree become second class citizens, the source of bugs, less well designed and often quite dependent and highly coupled with parent elements.
Another problem I have is tooling related, it's the wave updates that you have to deal with whenever React updates. React and many well maintained libraries do this really well but there's always some bad actor in the ecosystem that makes it a pain and frankly I never look forward to a new React version. Again I understand that all these things are problems that can be overcome and I have, but I'm frankly over it.
I know I'll probably be writing React based applications for an employer for a very long time, but I would no longer recommend it. I think vue.js is a promising new library. I think there are things to be said about how React is very good about enforcing modular component development and I quite like flux and redux, but React in general. React is just not great.
"things like modals, toasts, or things that just don't fit into a neat little area of the screen in a sibling child parent relationship"
That's actually where React is very strong compared to other functional-style UI frameworks (eg: Elm's). Portals in React are really elegant and makes dealing with modals and toasts (or anything that doesn't fit in this model) quite nice.
I was working today with someone who was making a browser extension to inject stuff in host pages (think something like LastPass or those rulers for designers).
We made a set of components that create arbitrary elements at arbitrary locations, or highjack existing ones, and from there you get to manipulate things like you would any other functional-style UI. It's quite lovely (all thanks to the lifecycle hooks and React's ability to render subtrees anywhere on the screen). Very few tools do it as well as React does, otherwise I'd be writing Elm all day instead of JavaScript.
You're achieving that with separate calls to render. In an ideal React application you only have a single render call. So no, you're not demonstrating a good use of React and you're certainly not showing this to be a strength in React. Imagine, you wouldn't call react.render from inside an existing React component. That's ridiculous.
Ember is an excellent choice.
We use it in a real large scale project and really love the 'addon' way of managing modules. Its simple and comes straight out of the box. Our teams follow BEM for css and maintain 1:1 for a component/route and css file.
What exactly about this thing warrants the use of a behemoth of a framework like Ember?
The entire app looks like an optimization of a poor experience in another web service. I'll conserve my cynicism for their actual app, which could have been implemented without even the need of a framework.
What is exactly complicated about a few different screens? I fail to see the need for even a web app here.
Also, I'm not sure I understand any of their arguments. Does it really take days to setup a test harness in anything?
Also, the bit about progressive enhancement -- are we really talking about this still? When using a single page application framework? For an app that does two factor auth. I'd also be concerned about the security surface area for an app like this that pulls in a dependency like Ember, on a third party site during the login/auth experience. It's bad enough that we have third parties pulling in react to display some simple forms and buttons.
I also find it annoying that it seems people have transitioned from progressive enhancement meaning 'detect if we can use JS' to 'detect which features of JS to use' to 'detect how much processing power we can abuse without the user noticing'.
As someone who really enjoys his <0.3s page loads (that is fully fetched & rendered, less when from cache) even on mobile it feels annoying to not have a 'middleground'.
For example my current project, which is basically a small website where people can upload artwork, does not need to be a SPA. However, I'd like to integrate some interactivity to make browsing easier. Like a 'browser' view when you click a picture, or in place reloads (so the CSS doesn't need to be reloaded, nor perhaps the JS. However there doesn't seem to be a library for that to my knowledge. All I know are either on the jQuery level where you have small seperated pieces, or the React/Ember/Angular level where you have to write all or nothing in that language.
I wonder if it is even possible to have an 'augmenter' library that just makes existing HTML better (Perhaps with some hints in the 'data-' attributes), or maybe my google-fu is just bad.
As a followup I don't seem to be the only one thinking like this [1].
[2] comes close to what I'd like, but the last update is from 2012 and the author doesn't seem to have done a lot lately.
"...the thought of Ember making all these decisions for us — enforcing a convention over configuration — was very alluring"
Alluring, yes. Good? You shall see. When you embark on using an opinionated framework development can, at first, seem easy. It's when those opinions change that you can easily get hurt, however.
I find that convention over configuration often is trying to solve the wrong thing. It puts a tremendous burden on the user to know all of these conventions when being simple and direct usually works just fine.
One example is an Ember RFC I read recently about the required folder structure of Ember projects. It wasn't clear to me at all why they were even doing this. Like, what were the gains? It turns out the entire point is some magic auto-discovery of things like Handlebars helpers.
In the React ecosystem, there are several really good tools for managing build, deploy, and test harnesses. See kyt [1] for example, or the list of Create React App Alternatives [2].
As I do understand, conventions manifest often in the setting of defaults for configurations. These defaults are inherently opinionated, and therefor hinder the free development of innovation in a open source community. As it will always favor a specific solution over another.
Conventions over configurations comes to the benefit for small team, beginners and is in general more fun to code with. But it comes at the cost of being much slower in adopting new patterns and innovations. As there is currently so much speed in javascript development happening, I wonder if for now configuration do outpace conventions, until the battle field has settled.
React has acknowledged the situation and tries to get the best of both world with its quest for a React CLI. Did they know about it at the time of writing?
reply