As a developer you shouldn’t use ember-cli unless you actually know how to run most of the build steps manually
I find it pretty irresponsible that developers don’t understand and can (if needed0 implement every layer of abstraction there work rests on.
I mean, can you honestly feel like a professional if you don’t know the potential voltage between two transistors while your program adds two numbers? Or even at a high level, what machine code V8/JSC/SpiderMonkey/Chakra spit out on a given platform for that function you just wrote?
It seems pretty insane to rest on abstractions…
It doesn’t seem like any one bothered to explain that.
Nor does the manual of your new MacBook explain to you the details of system boot. And I suspect you are fine with that.
If you want the information the source is available. I recommend starting at the executable → https://github.com/stefanpenner/ember-cli/blob/master/bin/ember and following the paths.
We have had ~129 brave souls venture into the bowls of ember-cli and return with successful contributions. It would be great to increase this number.
Of course It would be nice if more of these details where in literature. There is an ongoing effort to maintain https://github.com/stefanpenner/ember-cli/blob/master/ARCHITECTURE.md but time isn’t always on our side. Maybe you are the one to help improve it today!
(eval’d) This code is intended to be used in production -
incorrect, when you build a production build of your application there are no eval statements. This is merely a short term development nice-thing to enable file level source maps until we migrate to the new es6-transpiler.
ember build --env production # then inspect the output in dist/
see: https://github.com/stefanpenner/ember-cli/blob/master/lib/broccoli/ember-app.js#L76
Ember community should reverse this process and aspire running development code with almost no build process at all.
Fun Fact, not only is this possible but this is how many ember applications where built for quite literally years. Lessons learned from this lead to the need for modules, build steps and finally ember-cli.
Now no longer does each team need to re-invent the wheel they can instead collaborate with a community, share the burden and fix each others problems. In addition this abstraction has also enabled a whole new and easy way to share add ons between any ember-cli app.
Ember Cli is making you stupid
Ember CLI makes you smart
There is clearly a cost to abstraction learning and this cost is only amplified by mis-aligned or leaky abstractions. As this project matures (and as we have proven already) we constantly remove these leaks. So whats the value in these abstractions? We as a community can do the right thing, we can learn and improve, we can fix incorrect assumptions and the next time you upgrade your apps you will benefit from this team effort without needing to invest the time yourself.
This is the value of software.
Example:
Do you implement CSP in your app? You should, it mitigates a whole category of XSS attacks. But guess what, we are all developers that have real deadlines and we can’t just stop ever time we have a good idea, we would likely never ship anything.
So wouldn’t it be nice if one or two community members could invest the time, and the rest of us just “Get it” when we upgrade? With ember-cli this is in-fact the case and thanks to @rwjblue → Use the content security policy addon for new applications. by rwjblue · Pull Request #2065 · ember-cli/ember-cli · GitHub the next version of ember-cli will transition everyones to be CSP compatible.