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.
Seems to be roughly inspired by a few different engines that came before it... it reminds me of Razor a little bit. I've been doing mostly react/pwa apps lately, but will have to try to remember this engine if it's well maintained the next time I need something more static.
In addition to service workers, you can do app manifests that will provide better caching/offline and is more broadly supported, even though deprecated in favor of service workers (which can do much more). If you're only looking for caching, that may be enough of a fallback.
Personally, I feel it really depends on your use case and needs... many more interactive applications (that work closer to traditional desktop applications) are better as a PWA... where if you just need some forms around mostly static data more traditional approaches with progressive enhancement is better.
Didn't watch the whole video, so not sure if this was mentioned, may come back later today to do that.
While I appreciate all efforts to make publishing for linux desktop better, really should include windows and mac in most deployment strategies if you're going that route, and are able to technically. The sad thing is it does usually wind up costing in one way or another (windows and mac build servers). But the fact is there are *SO* many more windows and mac users out there.
I'll often take it a step further than that... since I tend to break up my actioncreators and reducers by feature and that feature is within a redux subtree, I may
import { SAVE, SAVE_SUCCESS, SAVE_FAIL } from './constants'
but underneath it is likely...
export const SAVE = 'promise:feature/save';
export const SAVE_SUCCESS = 'resolve:feature/save';
export const SAVE_FAIL = 'reject:feature/save';
in this way I can have extensions in redux to handle 'promise:*', 'resolve:*' and 'reject:*' generically, in addition to or before the resolver.
Recently, I started a brand new React project, router v4 was near release, and a few other bits that were new (to me), using Webpack 2 for the first time, and a few other bits... to be honest, it was about as frustrating an experience as I've had in bootstrapping a new project. Now, it's not as frustrating, but it's really the first time I felt *that* frustrated, so I can feel the pain of a lot of others.
That said, I would never want to go back to the old days of manually bundling, or using script runners for bundle/reduce... Or doing manual namespacing in JS to avoid collisions in a large project. Modern ES6 (or node/cjs) modules are much cleaner, and you can take my Babel before browsers support all the current stage-2+ features I use from my cold dead fingers. It'll bee 3-4 years before that really happens. And it will be weird the transition from build/deploy bundling to JS modules from the browser, and HTTP2 server-push. I still prefer the way JS is written today vs any time before.
I use a lot of async functions, and some ES6 classes (sparingly) where needed. There are a lot of great things in writing modern JS. The flip side is evaluating modules in npm, and keeping up with some of the proliferation without falling into the trap before they're ready, or likely to take established roots.
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.I'll often take it a step further than that... since I tend to break up my actioncreators and reducers by feature and that feature is within a redux subtree, I may import { SAVE, SAVE_SUCCESS, SAVE_FAIL } from './constants' but underneath it is likely... export const SAVE = 'promise:feature/save'; export const SAVE_SUCCESS = 'resolve:feature/save'; export const SAVE_FAIL = 'reject:feature/save'; in this way I can have extensions in redux to handle 'promise:*', 'resolve:*' and 'reject:*' generically, in addition to or before the resolver.