4 ms·

I certainly can appreciate most of this post. I've used so many different frontend (angular, polymer, ExtJS) and backend (express, hapi, restify) frameworks and

I certainly can appreciate most of this post. I've used so many different frontend (angular, polymer, ExtJS) and backend (express, hapi, restify) frameworks and the various common building tools (grunt, gulp) that it's almost impossible to become great at all of them and for a new comer who maybe only used one or two of those frameworks it can be painful getting started. I've started using less and less frameworks as I work on harder and more complex projects. Sometimes I worry I'm toeing the line at becoming the "old kook who hates new frameworks" but I like things to be explicit and simple; for example if I can write a plain script to handle my build process without integrating grunt or gulp I'm certainly going to do that. > Leverage folder & file-naming conventions for automatically discovering application-specific routes, actions, tests, and more. Not a fan of this. This is implicit behavior which is almost never intuitive until you're experienced in the tooling that has it. I'd much rather be a tiny bit explicit where there is a list somewhere and I edit that list with patterns or explicit file names. There is no reason there should be "discovery" of such things at _development time_.

isoos 11y ago
Similar to this note: I've done my fair share of using dependency injection frameworks in the Java backend world (e.g. Spring), just to develop a healthy dislike for every DI out there. The magic is nice and good, until it becomes a burden, and a constant question of where certain objects are coming from. It was a pain to see the same design pattern to emerge in the (compiled-to-)JS world, with all of the same problems and complexities. I wonder if any _good_ pattern had similar lifecycle, winning the minds and then spreading to different domains. To be fair: I do think DI has value, but I started to prefer explicit over implicit, and most DI stuff is focusing on implicit and magic.
- on_and_off 11y ago
  have you tried dagger 2 ? I think it makes a good job at dispelling the magic as much as possible.
Arnavion 11y ago
>for example if I can write a plain script to handle my build process without integrating grunt or gulp I'm certainly going to do that. I used to like gulp because it does give you something like that. It lets you write your custom build task with an arbitrary input->output transformation and gulp will just drive it. That said, it's quite... heavy... for what can be considered to be basically something that takes a list of tasks and their dependencies and runs them in the appropriate order. That's essentially the functionality of async.auto() from caolan/async, so for kicks I made my own build tool that wraps async.auto's functionality into a similar task() function. It's lightweight (only depends on caolan/async) and serves me quite well in the hobby project I use it in.
e12e 11y ago
I still refer back to this excellent post from 2014: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool... And the still active, linked, github repo: https://github.com/keithamus/npm-scripts-example https://github.com/keithamus/npm-scripts-example For playing with js/css(processors)/webpack things. I never quite understood the facination in the js community with build tools that don't quite replace npm. It just seems like an unwelcome source of extra clocs in the toolchain. I was also somewhat pleasantly surprised at the simplicity of the setup for the angular2 (beta) tutorial[a] -- even if it manages to pull down a 100mb of dev dependencies (dist dependencies are much more sane). And even if the particular tutorial stops (or did a few weeks ago) before it actually shows how to interact with any kind of external storage/db/api... [a] https://angular.io/docs/ts/latest/quickstart.html https://angular.io/docs/ts/latest/quickstart.html [ed: actually meant quickstart+: https://angular.io/docs/ts/latest/tutorial/ https://angular.io/docs/ts/latest/tutorial/ ]

isoos 11y ago

Similar to this note: I've done my fair share of using dependency injection frameworks in the Java backend world (e.g. Spring), just to develop a healthy dislike for every DI out there. The magic is nice and good, until it becomes a burden, and a constant question of where certain objects are coming from. It was a pain to see the same design pattern to emerge in the (compiled-to-)JS world, with all of the same problems and complexities. I wonder if any _good_ pattern had similar lifecycle, winning the minds and then spreading to different domains. To be fair: I do think DI has value, but I started to prefer explicit over implicit, and most DI stuff is focusing on implicit and magic.

on_and_off 11y ago
have you tried dagger 2 ? I think it makes a good job at dispelling the magic as much as possible.

Arnavion 11y ago

>for example if I can write a plain script to handle my build process without integrating grunt or gulp I'm certainly going to do that. I used to like gulp because it does give you something like that. It lets you write your custom build task with an arbitrary input->output transformation and gulp will just drive it. That said, it's quite... heavy... for what can be considered to be basically something that takes a list of tasks and their dependencies and runs them in the appropriate order. That's essentially the functionality of async.auto() from caolan/async, so for kicks I made my own build tool that wraps async.auto's functionality into a similar task() function. It's lightweight (only depends on caolan/async) and serves me quite well in the hobby project I use it in.

e12e 11y ago

I still refer back to this excellent post from 2014: http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/ http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool... And the still active, linked, github repo: https://github.com/keithamus/npm-scripts-example https://github.com/keithamus/npm-scripts-example For playing with js/css(processors)/webpack things. I never quite understood the facination in the js community with build tools that don't quite replace npm. It just seems like an unwelcome source of extra clocs in the toolchain. I was also somewhat pleasantly surprised at the simplicity of the setup for the angular2 (beta) tutorial[a] -- even if it manages to pull down a 100mb of dev dependencies (dist dependencies are much more sane). And even if the particular tutorial stops (or did a few weeks ago) before it actually shows how to interact with any kind of external storage/db/api... [a] https://angular.io/docs/ts/latest/quickstart.html https://angular.io/docs/ts/latest/quickstart.html [ed: actually meant quickstart+: https://angular.io/docs/ts/latest/tutorial/ https://angular.io/docs/ts/latest/tutorial/ ]