14 ms·
Choosing Ember over React in 2016
- jeanlucas 10y agoSeriously, 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.
- YCode 10y agoI'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.
- coltonv 10y agoI'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?
- YCode 10y agoIt's not a huge issue, but that you have to use some third party library for styling in a view framework just seems inadequate. Other comparable libraries include styling into their philosophy, but React is irritatingly unopinionated about it.
- coltonv 10y agoIsn'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.
- geebee 10y agoGreat write up. 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.
- tejinderss 10y agoThere's a hope in webassembly
- geebee 10y agoVery 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.
- spinlock 10y agoCan we admit that we hope wasm kills JavaScript yet?
- lightblade 10y agoThat'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.
- scottmf 10y ago500 combinations of what? Other platforms too have n languages and n frameworks and so on. We'll be fine. I'm quite sure it will catch on with Apple, Google, Mozilla and Microsoft working on it. I'm intrigued by the server side Swift frameworks coming out right now. If they could replace JS on the server and browser that could be interesting.
- leshow 10y agothe lesson here is not to choose a bunch of random libraries you have no experience with. there was likely no need for you to: 1. create your own build system when something like create-react-app exists 2. use something like redux-saga when promises and async/await would suffice 3. likely you probably didnt even need redux, the application looks fairly small and doesn't look like it has a lot of internal state. tl;dr you did it to yourself
- bryanlarsen 10y agoIt sounds like their biggest concern was the anxiety induced by the worry they chose the "wrong" libraries. You're just reinforcing those worries! But you're right, we should really emphasise that "none of the above" is very often the right answer when choosing libraries to build a React app.
- dasil003 10y agoHow do you get experience with a library if you never choose a library with which you have no experience?
- leshow 10y agoYou reach for a library because it solves some particular need that you have, not just because.
- jessepollak 10y agoHey 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!
- duderific 10y agoFTA: >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?
- jessepollak 10y agoAbsolutely! 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. Does that make sense?
- duderific 10y agoYes it does, thanks!
- kamyarg 10y agoHey, loved the article. I was wondering your views on angular2? Are you planning on writing a part 2 to explain ember over angular2 decision?
- andrewvijay 10y agoThe 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!
- jeanlucas 10y agoIf you try, send over the link for us to test.
- andrewvijay 10y agoOh sure.
- karmajunkie 10y agoThanks 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.)
- lossolo 10y ago> 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.
- evilduck 10y agoI 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.
- jurgenwerk 10y agoEmber 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.
- orf 10y ago> 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.
- spinlock 10y agoI 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.
- jeanlucas 10y agoDefinitely a lie. I took more time learning webpack to get started than to get started in Ember, just to point out one example.
- doingmyting 10y agoThat's not really saying much. Learning webpack definitely isn't a walk in the park.
- joshuahornby 10y agoI'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) Still a great framework for large web apps.
- bl4ckm0r3 10y agowhat do you mean it doesn't follow standard responses?
- pjungwir 10y agoI 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!
- kemenaran 10y ago> APIs that don't follow standard responses 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?
- hatsix 10y agoNot 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
- steveklabnik 10y agoSo happy to hear JSON API is working that well for you :)
- tptacek 10y agoI 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.
- gkop 10y ago> Of all of these things, to build a decent React app, you only need React. React on its own does not compare with Ember.
- jessepollak 10y agoI 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 :)
- mooreds 10y agoWow, 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. As the perlers wisely said: TMTOWTDI
- fooey 10y agoInstant2FA sounded like a great thing to pitch internally, then I saw they want 10 cents for every login, ouch
- jessepollak 10y agoShoot me an email at jesse@instant2fa.com — if you'd like to pitch it internally, I can work with you to find a price that works!
- traviscj 10y agoAssuming 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?
- svschannak 10y agoThere are a lot of people out there making such decisions every day. Does anyone know a guide for making the right technology decision?
- allendoerfer 10y agoI 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.
- Touche 10y agoNote 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 https://www.youtube.com/watch?v=4bZvq3nodf4
- tomdale 10y agoLinkedIn has actually done a ton of work optimizing Ember for mobile devices, and they've got code splitting (what we call lazy engines) in production already: https://twitter.com/trentmwillis/status/796748896659800064 https://twitter.com/trentmwillis/status/796748896659800064
- jamesmp98 10y agoI hear it's worst on Android.
- KnownSubset 10y agoActually they have a strategy for your problem by enabling server-side rendering: http://ember-fastboot.com/ http://ember-fastboot.com/
- codinghorror 10y agoIt 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. http://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on-android/6577/59 http://discuss.emberjs.com/t/why-is-ember-3x-5x-slower-on-an... It would be a bit more even if Apple wasn't delivering substantial speed improvements, year after year, consistently.
- babbeloski 10y agoI 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.
- hybridcivic182 10y agoagreed - checkout the official redux bindings for ember (a cargo cult of the connect api from react-redux) https://github.com/toranb/ember-redux https://github.com/toranb/ember-redux
- aarpmcgee 10y agoI 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.
- hybridcivic182 10y agomutable APIs are so 2015 - ember and redux for the best of both worlds https://github.com/toranb/ember-redux https://github.com/toranb/ember-redux
- kimshibal 10y agoYou are still using redux? Everyone is moving to mobx
- tsxxst 10y agoCould you elaborate on why mobx is better than redux other than "new and shiny"?
- Lazare 10y agoI 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).
- jamesmp98 10y agoEmber 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.
- mevile 10y agoI 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.
- shados 10y ago"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.
- lightblade 10y agoTo be honest, I really miss the good old flex + wsdl days. Component architecture, check. Two way binding, check. Optional type, check. IDE, check. My favorite, typed components, check.
- sriram_iyengar 10y agoEmber 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.
- iamleppert 10y agoI just took a look at the Instant 2FA app. 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.
- neikos 10y agoI 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.
- neikos 10y agoAs 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. [1]: https://allinthehead.com/retro/367/why-is-progressive-enhancement-so-unpopular https://allinthehead.com/retro/367/why-is-progressive-enhanc... [2]: https://github.com/jamesallardice/Progressive.js https://github.com/jamesallardice/Progressive.js
- msimpson 10y ago"...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.
- Touche 10y agoI 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.
- msimpson 10y agoYeah. Those sort of nuances can often be the hardest to discover and/or debug.
- delambo 10y agoIn 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]. [1] https://github.com/NYTimes/kyt https://github.com/NYTimes/kyt [2] https://github.com/facebookincubator/create-react-app#alternatives https://github.com/facebookincubator/create-react-app#altern...
- mklarmann 10y agoAs 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?