Is there any good reason why Ember doesn’t use plain npm and bower packages and wrap those things instead? Isn’t the maintenance afford a real pain, because every time a new version of one of the dependencies is released the wrapper also needs to be updated?
eg. ember-cli-babel hadn’t been updated in 10 months. Since then lot’s of things have been added to babel-core, which users of ember can’t really enjoy. Some might argue: “It’s open source, you can always fork and fix it”, but if ember would just use the plain npm packages it would be much simpler to update dependencies. Just change version number in your package.json
In genral I understand the concept of wrapping dependencies and normally this really makes sense, but in the code I own and not a 3rd party library. Normally this wrapper in my code base is a simple module/class which delegates calls to the library, but for me an ember addon is not lightweigt as ember addon hello-world generates more than 40 files and downloads more than 240mb (npm3 140mb) of dependencies
Thanks in advance for explaining this design decision.
More often than not addons provide additional Ember-specific functionality, like components, Ember CLI-specific stuff, etc. that can be used out-of-the box.
could nearly be called “broccoli-browserify” and “broccoli-babel” (they’re really about the build cli build too, not the in-browser runtime framework).
So, if you consider the use cases:
expose generic JavaScript in a framework-specific way
wrap view libraries in a framework-specific way
wrap build tools in a build tool specific way
You’ll see this is no different than any other JavaScript tool out there. For example:
The goals of all of these libraries are the same: present a standard interface to the developer across a wide variety of source libraries with non-standard interfaces.
Wrapping libraries aren’t necessary in any framework: you can leave all the wires and circuits exposed if you really want. But you’ll end up wanting a standard interface, especially if you work on a project with a team size > 1, just to save headaches around bug fixes and code reviews. In the long run a standard way of writing code is always preferably to a “just type whatever as long as it works!” mentality.
The goals of all of these libraries are the same: present a standard interface to the developer across a wide variety of source libraries with non-standard interfaces.
I completely understand that people expect a plugable architecture from a framework, but for me and my coworkers npm modules are already pretty plugable. Just add a module to your package.json and require it in your code. For me there is no real need for another third party abstraction which we as a startup can’t control. In the end there is this little feature or bugfix which was already fixed in the original library, but the ember wrapper addon didn’t support this yet. That’s where I mostly waste my time, eg. I wanted to update ember-babel to 6.0. (Babel 6.0 · Issue #62 · emberjs/ember-cli-babel · GitHub created on Oct 30, 2015)
More often than not addons provide additional Ember-specific functionality, like components, Ember CLI-specific stuff, etc. that can be used out-of-the box.
My additional question then would be, why do you need this special ember functionality. Helpers in ember are as far as I understand it functions wrappers which can be called in handlebars. So instead of simply calling formatDate(date) we need to wrap this in a Handlebars helper. Maybe I’m a little bit biased from other but a helper in react is a simple function call.
But you’ll end up wanting a standard interface, especially if you work on a project with a team size > 1, just to save headaches around bug fixes and code reviews.
I think standard interfaces is something you should go for, but I realised after working with a small team of 4 on an ember application for more than 6 months we realised that some of the embers standard interfaces are sometimes to strict. Bypassing them caused us real headache. It could be that we just did things wrong but we had to make tradeoffs in order to please the framework instead of our customers.
In the long run a standard way of writing code is always preferably to a “just type whatever as long as it works!” mentality.
Code reviews are actually there to prevent a “just type whatever as long as it works!” mentality thats why we try to follow uncle bobs mentality: “We do not ship shit!”. You just need to be strict about this in your reviews.
Need? You don’t. Feel free to remove the addons and write the code yourself. You’ll have similar code to what is contained in the addon, except under your control and maintenance, which some people prefer.
Handlebars helpers are also just functions, they’re just functions with a specific standard interface. React does indeed allow you to bring in whatever libraries you want and have all their varied interfaces with a component’s code. Some teams prefer everyone needing to know how every library works, other teams prefer keeping this behind a standard interface to save time/mental effort the 95% of the time where you don’t need to know the specifics of a helper library.
This is just a preference.
What features of Babel 6 are you looking to add to your project?
