Adonis.js v2 released – Laravel for Node.js

Agree. Especially in a language like Javascript. For testing -

  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.

Disagree with the DI/IoC comments - for more complex projects, it allows dependencies to be pulled in in a nice terse and readable fashion. Runtime complexity also can be harder to manage, as it often ends up in a spaghetti of knowledge in scattered code. DI isn't a particularly complex construct to grasp.

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.

What is DI?

I can't speak for the author, but it may be for simplicity's sake.

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.

I'm not sure what you're looking at... but it does resemble laravel quite a bit to me.. the way relations are setup is almost identical laravel: public function resources(){ return $this->belongsToMany('App\Resource'); }

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.

It is interesting comparing the divergent chains of evolution:

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.

What do you like to use?

Yes. Laravel is very coherent php framework. But it seems there is no need php in future since ES6