I used to think DI was a good idea, but as I've gotten more experience... I'm no longer convinced using a DI framework nets you huge wins relative to the added complexity. My hypothesis is that good design can remove the need for a DI framework in many cases, or at least that's been my experience so far. Maybe I just haven't worked in an application that's big and complicated enough to justify a DI framework.
Don't get me wrong, there's usually going to a few moving parts you'll wanna inject, in order to make testing easier. But you can just... do it manually.
Perhaps I'm wrong about this, but I get the impression DI tends to encourage people to obsess over unit testing and abuse mocks. While I certainly believe that unit tests add a lot of value, there's definitely a point where they start to add little to no value.
Anyway, with that being said... The framework looks very interesting. I love looking through frameworks like these and seeing how people decide to tackle certain problems.
Thank you for sharing!
var myLib;
if(process.env.NODE_ENV === "test") {
myLib = require("../test/my_test_lib")
} else {
myLib = require("./my_lib")
}
or similar (you can obviously tighten this code up, too; I'm just being very explicit). Tada, you're injecting your test stubs in place of the real library when running in test.For the actual production use that a DI framework gives you, you can do similar, or manually set things up, or create a layer of indirection yourself, that only applies where you need it (say an IIFE that has the logic to determine which implementation to pull in, and return that function/module as appropriate).
But this is, as you say, largely tangential.
The benefits of mocking are often understated - it is not only to isolate logic, but for longer term maintenance, it is for also easily being able to detect what change breaks what part of the code. When people write more integration tests than unit tests (I have found many developers guilty of this), what often ends up happening is that when someone breaks one of those tests due to having to change behavior of code from new business requirements or maintenance (i.e. abstracting out common behavior), it can become very tricky to untangle what exactly broke, and how to fix it. Not that there isn't value in those types of tests, but without being paired with more controlled unit tests, there is a huge con that hampers productivity of teams.
Ideally, one should have the ability to easily mock and make testing each piece painless & clear, so that finding bugs/breaking changes can be made clearly and consciously. Not all tests need to mock, but having that level of control greatly helps on stable & quick iteration of code.
And really, I want neither of them.
Adonis: posts () { return this.hasMany('App/Model/Post') }
The routes/middleware page seems even closer to laravel 5's, that's all I've looked through so far, but it does look interesting at least as far as frameworks go, though I'd wait a bit before putting anything into production on it, till it gains some more momentum.
I'd really like 2016 to be the year that everyone who thought of making another new JS framework decided to not do that and instead go fix bugs in one of the existing ones that people are already using.
I got fed up of constantly learning new frameworks searching for that One True Framework that would be expressive and powerful but without too much boilerplate and... well, you know the quest.
I gave up looking for the Holy Grail and settled on what seemed to be working for me at that point (like quite a few other devs I know). It just got too much, the constantly learning new apis in order to keep up.
hence "I'm done"... I'm going to go deep instead and really learn how to use a single environment properly, as in 10,000 hours properly.
The discussion in this ESDiscuss thread (https://esdiscuss.org/topic/does-async-await-solve-a-real-pr...) points to multiple advantages of embracing Async/Await over generators for asynchronous code.
Personally I would have still have gone Babel+* but a Babel transpilation pipeline adds a non-negligible level of complexity to a project, especially when it comes to debugging/performance optimisation.
Rails inspired ASP.net MVC inspired Laravel inspired Adonis
wrt.
Rails inspired Sails inspired Trails
Good to see the spirit of CoC and elegant pragmatism being carried forward.
A question for the JS experts: Between this and Trails(Sails) how does one make a choice?