Step-by-step tutorial to build a modern JavaScript stack from scratch

I'd opt for flask if I were using python, but that's just me :)

the thing about the above-mentioned JS stack is that it's barely the tip of the iceberg. most of the dependencies in those python apps are built using standard libraries that simply don't exist in javascript. glazing over the whole "you're about to download a bunch of random stuff from npm that may be unmaintained or malicious" thing doesn't do a service to a junior dev.

it's also not a "modern" stack. gulp? webpack. npm? yarn. react? vue. and in another month it will be something else. what you would opt for in python, is well-established, built on libraries that are part of python's core, and maybe except for the testing stuff has been around for 100 javascript years.

I'm criticizing neither the article nor its author, simply remarking that javascript in 2016 is, in practice, completely fucking brutal.

> How did you manage your js files ? Did you put everything in a single file ? If not, what scheme did you take up on to split the files ?

Since I have the benefit of having all my customers' systems on chrome/ff (evergreen variety) I can use latest js features that are stable. So most of my main project (a CMS for schools to manage date sheet, exams, result, attendance, homework, assignments, etc) is divided into features/modules.

There are a few project wide classes (es6) that are all in one file /main.js (about 1000 line file, nothing outrageous). Then every feature can have any number of individual pages (mostly two). So for example attendance has two pages take.php and view.php. Each page with it's own js file, an average of 300-500 lines per page, though a couple js files go as far as 1500.

At the end most pages have about 2 or in some cases 3 js files that are included in the header. It used to be kind of a mess when I wasn't using classes but now it's all pretty much as good as it will get at my current skill level.

> What about minification and obfuscation of js ?

My overall static page load is about 30kb to 50kb on average (excluding api/json calls) so minification is not something that I had to look into but I can easily do it with a babel flag. I mentioned babel in my original comment because some of the site is also exposed to parents that can be from any device/browser. So I use babel to compile (and if I want, minify/obfuscate) some of my code as well.

> And since you are not using jquery, did you manually set event handlers (onclick, onchange) in the html ?

I think even in jquery you would have to set manual event handlers. But I have a `Node.prototype.on = (e, f) => this.addEventListener(n, f);` somewhere in main.js. So setting event handlers is not as verbose but I never needed anything more than that. Not sure what other advantage jquery provides over `node.on('click', e => {})`. Inline event handlers are yuck. My html/js/css are strictly segregated.

I mostly keep my interface simple and focused on one single task so I never needed frameworks like react either. I keep DOM interaction to minimum. Only place where I think something is left to be desired in my work flow is generating DOM nodes from my json api responses. I have it down to as simple as I can but it's still pretty verbose. But I don't want to include and figure out an entire framework just to do this one task that I am not completely satisfied with but isn't that big of a trouble either.

Whew that turned out to be longer than I expected.

There is no reason why npm couldn't have a lockfile, for example.

I think what sets many people off -- including myself -- is that the "recommended" libraries change so often. It's like a joke: "You're still using npm for installing packages? That's SO 2015! Of course you should be using Yarn."

After 21 years of JavaScript, one would expect a little more stability, so that the web app you build in 2016 with cutting-edge technology wouldn't be scoffed at in 2017 and obsolete by 2018.

> I develop with those users in mind

I also develop with users in mind, which is why I don't care how large my development environment is as long as it brings benefit to them. My original comment was a response to a person who rhetorically asked how big the node_modules folder was after installing a list of dev tools. I don't install my IDE on your phone/netbook, nor do I install my JS dev tools. Who cares how much disk space it eats up on my developer computer? I couldn't fill my disk space unless I spent a week downloading porn. My laptop cost comment was one about developer contributions, based on the belief that we were still talking about dev tools. I won't design my dev environment so that a developer with a 10 year old computer can work with me. Everything in here has been about developer workflow. The user isn't impacted by any of it. In fact, all it does is improve their experience. For an example, I have a hobby app I'm working on in node/angular2, which is an image editing platform.

  $ du -sh my_app/
  483MB my_app/
  $ cd my_app && npm run build
  $ du -sh my_app.tar.gz
  3.7MB my_app.tar.gz

It unzips to 24MB, 20MB of which are the few node modules that don't play nice with my build system. Spinning it up, it takes ups 62 MB of RAM. I'd hardly consider that earth shattering to a user (the user doesn't download it anyway, it's an api deployed on a server). When I run it in dev mode, it takes up 400MB of RAM. I don't care, because that's what this computer exists for.