Even when using gulp, browserify, webpack, etc, I still recommend that people setup their actual task list in package.json so it's more consistently discoverable.
I think it might have been better to specify npm tasks in package.json, then have the pom.xml reference `npm run build` etc, instead of gulp directly. This could emphasize the separation of the node/js world to the app and beyond this, it would allow the client portion of the project to work as so many other projects do in the client-side space today.
Shouts to @nodeaz and the #gulpjs guys.
I've gotten into pushing my eslint and babel configs into package.json ... I know it bloats it a bit, but then there's one non-hidden file to edit.
Also, env already includes the es2015 bits, so don't need them as a separate module.. just env + anything that isn't in the spec yet.
No IE10-11 support should probably be spelled out on the homepage (per your observable dependency)... as many will be severely surprised when they find that out.
How does this perform with *very* large state trees and modifying smaller points? It seems to me that the performance for comparing changes, or tracking changes would either mean a lot more memory usage, or be significantly slower with very large state trees.
I'm definitely glad they decided to delay, looking forward as what's in channel for the V8 changes it absolutely makes more since going this route. Especially how long some organizations have been holding on to older node versions without updating their codebases.
I'm also more than happy to see as many ES features enabled in the box and less need for babel as a build step for server-side code (though it isn't going anywhere for a while).
One thing I do, as I don't develop in Linux, regarding packaging dependencies, is I'll write modern syntax (babel, env, etc) and output to dist, with a package.json with a build date and only the dependencies needed to run... then I'll use docker to get the packages for a linux env, and zip the results... IIRC, my command line for docker is as follows, may not be exact, I'm not at work.
docker -i -v "${PWD}/dist":/app -w /app node:6.10 npm i
This is in my build script (shell.js) and after that I use infozip to zip that directory into `builds/${}package.name}-${package.version}-${package.build}.zip` ... the build date is `new Date().toJSON().replace(/\D/g, '').substr(0, 14)`.
I do similar for my Elastic Beanstalk output, but that will put the dockerfile (FROM node:6.10-onbuild) into dist, and zip that into a bundle without the npm install. It winds up working very well for publishing to AWS.
Cool start... one suggestion in the nearer future would be automatic support for Let's Encrypt. Also, if you're interested in this space, may also want to look at Caddy server.
Like all things, test and create metrics against your use case... If your application works well enough for your users, worry more about features and less about bare-bones performance. If you're working in node, maybe consider both. If you're writing a game library, or game, then the constraints are tighter.
Most applications are not games and perform well enough for most users (beyond initial download size. Caching techniques would be a better impact for most. Beyond that on the server (node), you're better off concentrating on eliminating bottlenecks, and designing for horizontal scaling.
It really depends on your use case... I recently rewrote part of an application that needed to run in an AWS Lambda, processing 1M CSV records into SQS requests in the lambda window of 5 minutes... the prior method could only hit about half the desired. The rewrite can now do about 1.5-2M records in the window (110-180 seconds for 1M). Good enough, though wouldn't mind if I could hit more. Some of the checks for legacy processing have some overhead, but in general, I wasn't able to get any more requests into SQS, it tops out around 150-200 simultaneous connections to SQS in flight.
It comes down to knowing where your bottlenecks are, designing appropriately and refactoring appropriately. Sometimes the next largest blocker isn't what you might think it is.
One thing I do, as I don't develop in Linux, regarding packaging dependencies, is I'll write modern syntax (babel, env, etc) and output to dist, with a package.json with a build date and only the dependencies needed to run... then I'll use docker to get the packages for a linux env, and zip the results... IIRC, my command line for docker is as follows, may not be exact, I'm not at work. docker -i -v "${PWD}/dist":/app -w /app node:6.10 npm i This is in my build script (shell.js) and after that I use infozip to zip that directory into `builds/${}package.name}-${package.version}-${package.build}.zip` ... the build date is `new Date().toJSON().replace(/\D/g, '').substr(0, 14)`. I do similar for my Elastic Beanstalk output, but that will put the dockerfile (FROM node:6.10-onbuild) into dist, and zip that into a bundle without the npm install. It winds up working very well for publishing to AWS.