Step-by-step tutorial to build a modern JavaScript stack from scratch | Hacker News Reader

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

github.com

366 pointslobo_tuerto192 comments

I feel like the people complaining about how many libraries there are in this stack don't know what these tools do. Most are small tools that do one thing very well.

Yarn installs packages, much like Gem, NuGet, whatever. Pretty standard.

React is a frontend framework. Not surprising that you'd use one. I suppose you could opt to write a giant pile of vanilla JavaScript instead (I'm assuming you're not using this kit for a simple webpage, which would be silly. We're building a web app, right?)

I'd dare to compare Gulp + Webpack + Babel to your "compiler" in a way. I'm a little lost at why we're using both Webpack and Gulp though. Babel is a necessary evil to ensure we're "cross-platform" in a manner of speaking. These are probably your most "unnecessarily complicated" tools.

ESLint and Flow check your code for obvious mistakes. Reminds me of IntelliSense and compiler warnings. Again, pretty standard stuff.

Mocha is a test runner and Chai is an "assertion library". Chai isn't a big deal: expect(foo).to.equal('bar'); Simple stuff.

Feel free to scoff at Redux and Immutable if you'd like. Probably unnecessary.

Am I the only one that likes this ecosystem? I feel like it follows the Unix philosophy of "Make each program do one thing well". You need almost all these tools in other environments -- they're just typically chosen for you in advanced.

I think the reason most of us dislike the ecosystem isn't because therre are many libraries and tools in the stack. In the C-world, every time you type 'make' I am probably executing two dozen different programs, so we are very comfortable with "Make each program do one thing well".

The problem that most of us dislike the javascript/web ecosystem is that those set of libraries and tools keep changing every couple years. As someone who doesn't do this as a full time job but once in a while has to poke his head out to the other side, it's really hard to keep up with even the acronyms. For example, I know that we are using npm, but now you say we should use yarn?!

I don't buy that either. The youngest thing on that list is yarn, but aside from that everything is a few years old at least.

And nobody is saying you need to use anything. Npm works fine, bower still works fine, hell pulling down tarballs still works fine. You don't need to use the newest thing if you don't have the problems it's trying to solve.

Yeah, from the outside I can understand the "everything keeps changing!!" complaint, but having been involved in JS for a few years, every single tool that got replaced was replaced for completely valid reasons, that couldn't have been solved incrementally by improving what was already there.

    Grunt > Gulp > Webpack
    manual polyfills > 6to5 > Babel
    script tags > bower > NPM > Yarn
    nothing > Flow/Typescript

All of these were significant improvements upon the status quo. If you don't understand why, that's fine! Keep using what you know.

As an outsider my question would be why can't the existing tools update and adopt instead of being replaced?

Because that's what leads to monumentally difficult to use tools.

Instead of choosing between gulp or grunt, you'd need to choose which config flags you want for this hypothetical "gunt". So instead of having simple to use tools (but a bunch of them), you have a few tools which take weeks of learning before you can even scratch the surface on them. And it leads to tools that have settings that nobody knows about because nobody uses them, and weird security holes and issues because of legacy support for an option that was added 3 years ago which when combined with a new flag causes everything to break...

Gulp is very simple, it's like 4 functions, and like 3 or 4 "conventions" you need to learn. There is no config, there are no settings, and there isn't any baggage. And that's the theme with JS tools. Rather than bloating current tools, you make a new one. Switching between them is easy, as they are all very trivial in nature. The power comes from combining those trivial tools.

Even if that were the case I would think learning powerful tools over the span of a few weeks would be worth the effort if you had the reliability that these tools would exist for years to come.

It seems like the rapid change and throw-away-ability of the tool ecosystem reflects the final product as well -- and maybe that's the large difference which is emergent from web technology? What is the average lifespan of a web application?

I don't think the past few years will be representative of web development in the future. The community has had a lot of churn because basic questions (How do I ensure my code has what it needs to run? How do I include dependencies? How do I efficiently deliver my code?) weren't answered, but now those questions have robust, widely used solutions, we don't have everyone figuring that out for themselves (and writing throwaway tools).

I think most of the current crop of tools that are in vogue will stick around for a while. There have been a few challengers to Webpack offering feature improvements (Rollup, Broccoli), but the ideas they introduced were added to Webpack, rather than replacing it.

"rather than bloating the current tools, you.." just bloat the whole stack.

How so?

I use maybe 3 main tools for my build system. Gulp, webpack, and babel. And I only use gulp because it is a bit easier to read than just putting stuff in a makefile (which is replacing one tool with another), or just using bash scripts.

If we were going with the "add options instead of adding tools" way of doing things, I might have one tool, but 100 flags and settings that I would need to manage and change, and you can't ignore the flags and settings just because you want defaults, because the defaults would work in a way that's out of date, or there might no be defaults at all.

Just because there are tools out there, doesn't mean you need to use them all. You can ignore everything you don't need in your project. And that includes ignoring the downsides, bugs, security issues, breaking changes, and baggage that comes along with them.

In half the cases parent presented, there were no "existing tools" to update(manual polyfills -> modernizr/6to5, script tags -> package managers like bower/npm, nothing -> eslint/type checkers, writing ad-hoc scripts for your own os -> grunt/gulp).

The rest of the examples are cases of merging two large ecosystems(web development and nodejs) together - that spawned browserify/webpack for bundling, npm for package management.

Many of these tools did try to update and adopt the new schemes. The grunt developers spent a lot of time optimizing their architecture in order to achieve the same speeds that gulp had. NPM has not stopped evolving - major version 3 tries to address a lot of the problems that yarn tackles. Babel evolves to adopt new javascript features.

I see the churn in development tools as a very natural progression, but that might be because I've been following it for a while and have seen and felt the pain points that each of these tools try to solve. I see a lot of effort within the javascript community to remain "compatible" wherever possible - for example, there are tons of guides how to migrate from grunt to gulp, there are matching tasks to ease your migration, etc. Library developers often release both on npm and bower, and craft elaborate "UMD loaders" for their libraries to allow for commonjs/AMD to exist side by side.

All in all, I find living with "javascript fatigue" to not be very exhausting. In our company, we have a wide variety of projects - some use literally no tooling, some use just bower, some use grunt, some use gulp, and our latest ones use the "modern stack" with webpack, etc. All of these projects are still actively maintained and their respective tooling stacks work and provide the benefit they were added for.

The problems the "newer" tools try to solve may not even be problems your development process has. If you've never really suffered performance problems working with grunt, then perhaps you've never felt an urge to migrate to gulp. Maybe you've never been bitten by npm's non-deterministic installations and poor download performance(I really haven't, so I haven't migrated to yarn, for example).

The magnitude of web development projects has ballooned in the last couple of years, and the tools are racing to handle it. It's not surprising that tools that are fit for a large web application with tons of code and a large team aren't really fit for a few javascript files to decorate a mostly static site built by a single developer. The churn is there, if you need it, but you don't have to use any of the newer libraries or tools.

The thing is, in other languages, frameworks and libraries can evolve without being replaced. It's called version 2. I can't help but think that in the JS world, you are more likely to ditch the old project because JS code is more difficult to read and maintain than languages that have more static typing, a somewhat higher entry bar, and a culture that values stability.

In other words, this is the consequence of optimizing for new entrants and writability versus readability and maintainability. It also becomes much harder to funnel talented people into being contributors to existing projects rather than starting their own.

In other languages there are very large projects that are heavily refactored and improved to support new patterns and use cases with regularity. Just yesterday I was using Antlr 4, which has been around for 25 years. But it's been updated many times. Maven was started in 2002, and maven 3 in 2008. It's stable and production quality. The openssl library goes back to 1998. Vim goes back to 1988 -- also rock solid and reliable. We're using a networking stack that is pretty damn old. But in the JS world, I can't help but think they would never be able produce anything that reliable because 6 years later they would be on their 6th re-write of Vim. And no, it's not (IMO) because other languages have corporate sponsors.

Javascript came out of the webspace which (was) primarily throwaway code. It was a bad thing to have an old website. They prioritized rapid prototyping, which was appropriate for that business case. However as Javascript is maturing and branching out to server-side programming and at the same time the client side becomes more complex, you can't keep re-writing all your tools every couple of years, or even every 5 years. You need tools that last decades, even as they are incrementally improved. If you don't have that, you are going to be subject to increasing exponential costs that are going to weigh very heavily on the language. Soon, you'll need to spend almost all your resources just re-writing stuff. It's no different than the developer that builds non-sustainable housing that has to be torn down every 10 years but is really cheap to build. Long term, a city built that way will necessarily be smaller in size and more expensive to maintain than a city built with housing that is more expensive to build up front but lasts a lot longer. Exponential decay is going to catch up to languages that like to keep re-writing all their libraries.

More importantly, I don't see an awareness on the part of the JS community that this is a serious problem that they need to tackle. They look at all the new libraries and the fact that they have the most code on github as a good thing, instead of as a warning side that they are already spending way too much time re-writing stuff.

So when there is announcement -- here is your standard webstack and it contains a tool less than a year old, a lot of people are gonna say "WTF", and explaining to them that Yarn has some new feature that NPM doesn't kinda misses the point. Of course it has some new features -- but still -- "WTF"?

> However as Javascript is maturing and branching out to server-side programming and at the same time the client side becomes more complex, you can't keep re-writing all your tools every couple of years, or even every 5 years.

The client side becoming more complex is the reason why new tools keep being developed.

> If you don't have that, you are going to be subject to increasing exponential costs that are going to weigh very heavily on the language. Soon, you'll need to spend almost all your resources just re-writing stuff.

No one is forced to rewrite their code when a new tool is released.

> the reason new tools keep getting developed

That's a bad reason.

There's a solidly developed C library for dealing with HTTP, which is mature.

libcurl.

HTTP is developing, with WebSockets and the rest of the 2 spec.

C developers didn't immediately ditch what they use and fragment the ecosystem.

Curl got updated.

Python has a mature library, which is much younger than curl, called requests.

Python didn't fragment, they updated requests.

Here's where I have the biggest issue:

* Advice for C on which library to use, is probably still up to date 10 years later.

* Advice for Python on which library to use, is probably still up to date 5 years later.

* Advice for JavaScript on which library to use, is probably out of date 1 year later.

> They look at all the new libraries and the fact that they have the most code on github as a good thing, instead of as a warning side that they are already spending way too much time re-writing stuff.

There is a post, somewhere around here, that characterizes the JS culture as being one where shipping is the win condition. And I think this reflects what you describe better than the idea that other cultures merely value stability; JavaScript seems to value Github stars. And, as you say, that leads to a desire to rip out, rewrite, and own things, even if it doesn't necessarily make sense.

I'd say tools change every couple of days and often introduce breaking changes.

Just google "yarn vs npm" and you'll know the answer...

the tools change because the technology is evolving, despite node the front end is still the driver, and mobile phones / browsers / etc are constantly being improved and evolved, and the ecosystem keeps up with it. Would you rather it all stayed static like in the C world and then you program a 2016 smartphone with a 2006 stack?

The answer to your question is yes. I would rather the stack, or at least most of it, stayed stable for 10 years. The problem seems to be that the JS community keeps re-discovering the wheel at every step, instead of actually looking at other ecosystems and learning from them.

How log did it take for a sane build system to show up? Or a sane package manager (with dependency resolution, upgrades, checksums, signature verification, etc.)? Why is Grunt/Gulp a thing when we have thinks like make/CMake?

The technology is not changing, in the sense that the state of the art is not really changing. In the past 15 years the biggest paradigm shift has really been towards single page apps, ES6-7, and TDD. The rest has existed as state of the art in many other ecosystems, but the JS community is notorious for having a bad case of NIH syndrome, so it's taking forever to get to the state of the art.

The good news is that it will slow down at some point. The bad news is that it probably won't be for a few years.

> Why is Grunt/Gulp a thing when we have thinks like make/CMake?

What a ridiculous statement. It's like asking why .NET doesn't use the JVM or why Haskell doesn't use the C compiler. Grunt/Gulp solve web dev specific problems, make is a different kettle of fish.

No, the problem is never improving the existing software but rewriting a new solution from scratch every 3 months [1][2], that, while it solves the shortcomings of the previous tool, now introduces a complete set of new problems. And people that actually have stuff to deliver are always playing catch up and fighting the bugs of alpha quality software.

I feel strongly about this, especially when reading a step-by-step tutorial, that's most probably intended at frontend "newbies", that for example is pushing Yarn: I played with it the other day on a working VueJS application, and got hit by a bug, causing yarn to delete important files in node_modules. My code wouldn't work anymore. Really sorry that I can't find the bug report anymore to prove my point. The workaround was going back to npm.

Teaching people alpha quality software is irresponsible. If you want to teach, or have stuff to deliver, use the battle tested tech. Experiment when you know how the pieces work together and have lots of free time.

1: https://www.jwz.org/doc/cadt.html

2: EDIT: this is a big problem of our industry, it happens in all environments, but the JS community is the worst IMO. Desktop Linux is the second worst offender.

The problem with continuously changing technologies is that it doesn't allow you to become a master of that stack, so your constantly relearning how to accomplish the same thing. It's inefficient. If I build my applications with well established technologies, then I can do it quickly and accurately. Sure, I might miss out on some cutting edge benefits, but my shit works, always.

However, if i switch to JS, I feel like I will have to not only relearn how to do things I already know how to do, but I will be stuck in a cycle of continuing education and won't ever be able to expand my skillset beyond those things.

That's the state of the computing industry. 80% of the continuing education is about learning to do what you already knew how to do in a newer, hotter stack (but not necessarily better). 20% is about learning new paradigms. And I'm being too generous. It's probably about 5%.

Suddenly being a medical doctor sounds much less stressful. I really feel some of us chose the wrong career path. Imagine having high social status, having almost always some meaningful work, all for debugging meat machines that have lots of failure modes, but most of them well understood?

Having experience in both worlds, I can assure you medicine isn't what you seem to think it is. Social status, and income aren't so grand these days, and working conditions are bad for a lot of practitioners. And "debugging meat machines" is anything but well-understood in the majority of serious cases.

I know working with Javascript can be an annoying proposition. I'm maintaining a web app I wrote a couple of years ago in vanilla JS and gotten to be kind of a hairy beast. Probably would be better to rewrite it, but it works and for all the warts at least I know where they are. Maybe I'm just too lazy to take the time and effort to recreate from scratch. I figure by the time I got it working, I'd always be lagging the newer, "better" stuff anyway.

Interestingly, your comments about education have a parallel in CME (continuing medical education). There are real paradigm switches that appear from time to time, but not as much as you'd think. Most changes have to do with small refinements like new medicines that are variations on the current ones, theoretical or research findings, administrative or procedural issues.

So yeah, the really important information approximates the 5% figure you cite, and a significant amount of "updated" info is only marginally different or new, more or less equivalent to the "newer, hotter stack" idea you mention. Sure seems all that greener grass still needs to be mowed about the same way.

I like it too. People vastly over-estimate the complexity of these tools.

As a freelancer, I start a new project every other week or so. It's really not hard to get up and running with these tools. They're also incrementally adoptable: since most of them are loosely coupled, you can get started with a new one without rewriting your whole stack (for example, I first used React with Gulp+Browserify, not I've switched to Webpack).

The complexity of the tools isn't the problem.

It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last.

So for those us who don't do front end development we come back and suddenly have to learn 20 new tools.

> It's the fact that the entire Javascript community seems to suffer from ADHD and is constantly inventing a new tool that is marginally better than the last.

If you assume that the entire Javascript community was one person or one coherent group, then yes. But it is not like that at all. You state this as if a single organization made grunt, then made gulp, then made webpack. This is nearly as absurd as saying "The entire programming community seems to suffer from ADHD and is constantly inventing new languages". People who are using grunt didn't pack-up their bags and move to gulp, then pack up their bags and move to webpack. Rewriting your front-end in a new webframework every 6 weeks isn't a thing that actually happens. That's as absurd as suggesting that after leaving ruby for node, your team left node for golang, then left golang for rust, then finally rewrote their application in elixir.

All these different tools solve different problems, or solve them under different constraints, or solve them in ways that better match their backend languages. There isn't some magical tool that everyone needs to jump to.

Probably a better term than inventing is "standardizing". The community as a single general entity, is constantly changing what they accept is the "standard stack". I don't get to have my safe goto stack of LAMP for twenty years, and then swap out alternatives after research and my needs; the goto stack is radically different every year.

And ofc there's a big push for frameworks and languages over libraries, and libraries get coupled to frameworks, so anytime you do want to "upgrade" to the new thing, _everything_ goes with it.

> The community as a single general entity, is constantly changing what they accept is the "standard stack".

You're operating on a false premise, the community is not a single entity. You don't oversimplify Javascript and pick the "standard stack", you have to do some basic research first. Maybe you need jQuery, maybe you need React. It would be pretty stupid to assume that all web development problems are nails then also assume the latest popular bleeding edge tool is a hammer.

> And ofc there's a big push for frameworks and languages over libraries, and libraries get coupled to frameworks

I don't see any evidence of this. If anything, the source of most people's complaints is that the JavaScript community heavily prefers libraries over frameworks, which means you need to pick several libraries to build a project instead of

Are you sure you have any clue what you're talking about? I regularly "upgrade" parts of my stack without changing "everything." It's a huge part of why libraries like React are awesome.

Rewriting your front-end in a new webframework every 6 weeks isn't a thing that actually happens

I don't think any sane person would rewrite their apps everytime a new flavor of the month tool came out, but all this technical churn must make maintenance a nightmare.

It doesn't make any additional maintenance unless you chose to rewrite your pre-existing projects when any new random thing comes out.

"the entire Javascript community seems to suffer from ADHD"

^^^ THIS ^^^

Coming back to my project from 6 months ago and upgrading dependencies and finding out nothing my tooling is obsolete os awful.

Maybe that's part of the problem. Most people don't start a new project every week, so we get to know the same tools pretty well for a year or two or longer.

"As a freelancer, I start a new project every other week or so."

Yeah - I'm not sure if this is representative.

Moroever, if you're staring a project every other week, you may not be working at the scale/resiliency that most entities need, not even considering legacy etc..

The toolchain churn in JS is too much, especially relative to other platforms.

I like it as well. I have yet to see tech stack that has comparable potential but is less complicated and can be stripped down as low as the web stack if your requirements permit it.

I mean yeah, if you have a big app, complex requirements, there is a bunch of stuff you need to take care of.

However, I would like to see the tech stack that allows you to do the same with less complexity.

It's not like Android (gradle?!, java 6?!, the android api!?) or iOS development is a walk in the park if you want to do anything with production quality.

I'm usually one of those "JS frontend ecosystem is too complex" guys, but I found this tutorial to be quite approachable. Maybe the format of introducing one thing in each section helps?

There was a similar but much more complicated tutorial on HN a while back that I didn't get at all. Most of the explanation was handwavy - "just do this, trust me" - and the entire tutorial was dumped on a single page. Just looking at the scrollbar discouraged me!

I'm kind of surprised to see Yarn in a tutorial already. Welcome to the fast-moving world of JS, I guess?

Many people feel "JS frontend ecosystem is too complex". All of this is usually because of the horizontal complexity than the vertical horizontal complexity. There are just so many tools one should know. As nulagrithom said, all these do their job best ! And if you want to have a good project, you will be better with these tools :) And once you know what they do, they are pretty easy to work with.

Unix philosophy is "Make each program do one thing well", but they've made them once, many decades ago and haven't change them much since. The problem here IMHO is the speed at which it all evolves, and even more the speed at which the old tools become obsolete. You start a new project with the current 'cutting-edge' stack, and within the 6 months everyone switched to something else. It's become a full-time job just to stay up to date with everything that's going on, and that means making architecture decisions is a lot harder. Also, I personally dislike the fact that it forces one to pick a niche. For decades you could say "I'm good in front-end dev" and really mean it, and now it's not possible anymore to be truly proficient in all that's going on, you just have to specialize.

How big is the nodemodules dir after installing these 12 "small tools" ?

Who cares? This is 2016, memory footprint hasn't been relevant in years.

This attitude is precisely why so many software projects nowadays are memory hogs. Not everyone has an i7-powered Macbook with 8+ GB of RAM.

It took my 2 minutes to find a laptop under $500 with 8GB of RAM. My 2011 asus laptop has 8GB RAM. I'm not going to build software with my 2005 Inspiron in mind. Don't expect people to cater to 10 year old machines.

Not everyone has $500 of disposable income, either. Not to mention that very few phones and netbooks (like Chromebooks) have more than 4GB of RAM (in fact, I'm not aware of any in either category except for the Chromebook Pixel line). Lots of people in the real world are stuck with hardware with 2GB of RAM (or less!).

I develop with those users in mind. I don't expect the average HN-reading programmer to do the same (I've long given up on that), but that doesn't mean it ain't a problem.

> 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.

Memory is still the number 1 limit I have to deal with, every day. Both on my laptop, and on the server side. It remains highyl relevant exactly because of that kind of attitude.

> Memory is still the number 1 limit I have to deal with, every day

My raspberry pi has a node server deployed on it. I'm confident you can figure out how to manage it.

> on the server side

These are dev dependencies. If they are making it to your server, memory isn't the issue.

The issue isn't a single tool. It is when you have a lot of them, and it all starts adding up.

> These are dev dependencies. If they are making it to your server, memory isn't the issue.

Yet you above suggested deploying them somewhere else. Which is exactly what I do because otherwise my laptop is constrained by the heap of bloated tools I depend on.

Not just memory footprint (which is still at least somewhat relevant, and if you've never tried to delete a node_modules folder from Windows explorer you're in for a treat. More Microsoft's fault, but still annoying), but the sheer amount of trust required for all the dependencies. Only one of those tons of dependencies needs to be subverted to do something awful to you. The attack surface is much larger than it is in other environments.

Do you happen to be born after 1996?

No. Is there something you are trying to imply that I'm missing?

This is 2016 and devices have more memory, that's true. But ignoring memory efficiency is ignoring the basic principle of engineering and I see younger folks tend to ignore that more than olders. Having more memory available does not mean that reduced footprints are not better.

Sure, but I'm also not going to optimize dev dependencies. I care about the prod environment, but when one window of my IDE takes up 4x the memory of the app I'm actually developing, I just fail to find a reason to care about my local environment.

Do you happen to work on the Slack Client? (scnr)

Webpack + Typescript works as a replacement (without Gulp, Babel, eslint, or flow) if you are interested in giving typescript a go.

I love this ecosystem.

It's living, it's thriving.

I love the fact that tons of great engineers are coming up with new ideas everyday to make my life as a developer easier.

I love hearing a developer at a daily stand-up meeting saying he's been up all night trying out a new shiny thing and concluding by saying it also solves a big issue we had in our product and here's the pull request (timestamp 4am).

The hype is here for a reason. Hype is nothing bad, being excited about your tools makes your days happier.

I love the fact that JS people are never going to take "No" for an answer, constantly pushing the boundaries of what's possible, and making the web standards improve. I love the rise of functional programming. JS is a playground where mathematical theory and all of its beauty meets practice and the real world. It attracts talented people who bring a new perspective to our field. I love the fact that now I have theorems that ensure my login button will work.

> I'm a little lost at why we're using both Webpack and Gulp though.

Same here. I think one of the huge benefits of webpack is that it actually kills a lot of complexity by allowing you to skip gulp/grunt in most cases.

I think most people do not realize that the JS ecosystem is actually removing complexity.

Most people think the JS ecosystem is overly complicated, when in fact, it's just that in JS the complexity is exposed. This allows us to focus on reducing it. In order to address an issue, you must first make it visible.

Nowadays the trend in JS is to use multiple small tools that solve specific issues very well. We have a complexity in setup in exchange for less complexity in development. I argue this is a good thing, because setup is easy to document and only happens once in a project. Whereas you face development complexity every day.

This part from the tutorial is very significant to me:

> I recommend writing everything from scratch yourself

Yes! Yes! Yes! That's the heart of the JS philosophy: the ecosystem is trying very hard to make you understand what you are doing and why. It's giving you the keys to question what you're told and improve it. It's also why there's so much trolling. It's a good thing, question what seems too complex so that people can tackle the issue.

Please, do keep saying JS sucks, it's exactly what makes it so strong.

Do not use a framework, wire-up things yourself so that tomorrow you can repair it or upgrade it easily.

Do not write your router from scratch. But do connect the standard-issue router to your business logic yourself. Don't let someone else plug it in for you. It'll fit, but it won't look as good as if it were custom-made by a great tailor.

Finally, I love the config files. I hear a lot of trolling about all the config files, but I love the fact that I don't need to tell both webpack and mocha how to transpile JS and can just let the .babelrc tell them and everyone else. It's amazing that you can just git clone something and have all your environment setup as the author intended: language variant, linting... with .eslintrc developers using IntelliJ and atom both see the same messages.

Long live JS, or whatever comes next as we improve it!

"I love hearing a developer at a daily stand-up meeting saying he's been up all night..."

A phrase I heard from a much older, wiser developer: "heroism doesn't scale." If you encourage workaholic behavior don't be surprised if the team starts falling apart, or worse if their families suffer.

What exactly makes them "great engineers" other than they are visible? Great engineers are folks like Woz, Cutler, and Linus.

Apparently, the fact that they work until 4am?

So, i'm someone that uses gulp and webpack together. But probably not in the way you think.

Webpack is great as a compiler, but it's not great at being "make". It still needs something to kick it off. And something to setup the environment correctly, run the tests, do the commit for the deploy, run the db migrations, clean the build directory, etc...

So a little bit ago I wrote a tool called `gulp-run-command`[0] that basically turns gulp into a command-line task runner, and it works great.

Gulp sets up the task dependency list for me, most things are command-line tools, and every now and then I use a gulp-plugin (like with mocha) rather than the CLI because it adds some feature over using the tool standalone.

[0] https://github.com/Klathmon/gulp-run-command

If you have worked in JS for some time, and have an idea what all these tools do, This comment is probably the best tl;dr of what you are going to learn ! Pretty balanced, Just to the point.

I havn't read the tutorial, but looks promising !. Will sure checkout this weekend :)

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.

"You need almost all these tools in other environments -- they're just typically chosen for you in advanced."

+ I don't think anyone is complaining about what the tools do, or necessarily their quality.

The fundamental complain is 'churn'. The stack you see today may be replaced in a year - moreover - it's really hard to tell where the community is going. There are few resources (or rather too many) that can tell you what 'works and what doesn't' etc..

Also - many of these problems should not exist in the first place, and kind of illustrate the underlying failures of the web-browser platform in the first place.

Again - great stack. But it won't last long, and it's very expensive to churn.

Recent comment at a JS meetup form some guy: "I just left a startup where I was the key Angular guy, it was all in Angular 1 - I have no idea who's going to support that now that I'm going considering everything is Angular 2 now".

Reasonable assertion.

Also - I'm not so sure the 'do one thing and do it well' theory is always an advantage. There are many solid platforms where things are really well curated by company ABC. I'd suggest that if they do their jobs well, it's better than a community approach.

Obviously - community vs. monolith is not black and white, and there are advantages to each side, but it would be unwise I think to ignore the problems of constant churn.

Another example - just at MS HQ in Montreal for a preso on React. 100 devs in the room were not particularly excited. They seemed more resigned to it than anything. The consensus was 'yet another thing'? I think there is really a big gap between those pro-shops on the cutting edge - and 'everyone else'. And React is by no means trivial.

Did you not read the memo? "the javascript ecosystem is a mess!!111" etc

From section 1 of the tutorial:

> Since it came out in October 2016, [Yarn] received a very quick adoption and is becoming the new package manager of choice of the JavaScript community. We are going to use Yarn in this tutorial.

It's October 2016 as I write. Tell me this tutorial is satire. Please.

Yarn solve some problems that the npm folks were unwilling / unable to solve, and is backed by Facebook + Google (+ others) so it's likely to be here to stay. Unless npm wake up and smell the coffee and implement some of it themselves, but experience shows they are quite opinionated and not in a good way.

IIRC the yarn developers worked with NPM to get it out.

It's not a lack of will or ability on the part of NPM that it can't be "fixed", it's that NPM has just so much baggage. They can't change how things are installed, because that would mean getting rid of features that many people rely on. For a while they didn't even have any documentation on how NPM worked, it was a bit tautological (npm worked in the way that npm worked...).

And rather than add flags or settings to NPM to support yarn's use cases which would bloat the code, add a pretty sizable increase to maintenance and support, and would really be a mess, they decided to create their own tool which is similar enough to make it easy to switch, but without any of the legacy baggage that NPM needs to support.

It's a perfect example of the unix philosophy at work ("Don't hesitate to throw away the clumsy parts and rebuild them."), and just about everyone (including NPM) is happy with the work they are doing.

I honestly don't know that part of the Unix philosophy. And it starkly contrasts with my experience related to Unix, where most of the time we throw nothing away.

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

I think it is the worst/best kind of satire: The kind that is completely indistinguishable from how large groups of people actually operate.

Yarn is essentially a layer on top of NPM which was already the standard, hence the quick adoption.

That aside god forbid anything get better quickly. Javascript developers should suffer like anyone else.

It's definitely an extreme position to take.

A lot of people on HN seem to confuse the introduction of new tools with a necessity for you to constantly rewrite your app. There's nothing saying you need to adopt the new tools as soon as they come out.

Personally, I like to give things a good while to work out the kinks and see if they're actually any good (Bower failed this test, for example, so I've never used it). In the meantime, my "old" tools still work fine. Despite all the talk of churn, the last time I actually added a new major tool to my stack was GraphQL this spring.

Welcome to front end development. :)

The thing is, Yarn is likely to supersede npm at the command line so this is really future-proof.

Until next month, when Flamphf replaces Yarn.

Except Facebook is behind yarn. I'm about as worried about Flamphf replacing yarn as I am about Flamphf replacing React.

Step up your game.

Ridicule me all you guys want but I still write using just html/css/js and sublime text (no jquery either). And I have written a 30k line project using just that and php.

Being a filthy casual has it's upsides. I can do whatever I want insanely quick. Moving projects from machine to machine is quick as well. Only time I use command line is for git. I do have the advantage of having all my customers on a modern browser. But if that were not the case, only thing extra that I would need is babel. None of what OP mentions is "needed" to create a "modern" web app. Far from it.

Exactly. It seems the less people know about web tech, the more third party stuff the add to a website. And then they wonder why the visitors drop off and hate the sites. Some website got so bad, that they crash mobile browsers due excessive CPU/memory usage. As you mentioned server side generated code with eg PHP and HTML5, CSS3 and JS5+ is in many cases all you need to know.

Lately I've been seeing this as part of the problem in web dev. When you start a new project - let's say something like an employee management system that tracks schedules, locations, reviews, etc. - one of the early things you do is probably grab a framework for the back-end; maybe Laravel or Symfony or Zend - or maybe you roll your own (router, controllers, models, views, whatever). You mentally conceptualize and visualize the entire project in terms of delivering "views" to the browser (something not helped by the inaccurate terminology used in most back-end "MVC" frameworks).

Why don't we see the front-end in the exact same way? I have a list of requirements that the interface needs to accomplish - why don't I use a front-end framework (which can actually be a real MVC framework)? Why do we consider all these things for the back-end, but then write just one or two Javascript files for the front-end and add a few libraries like jQuery and/or Modernizr? Where's the consistency? Why do we just throw all our JS code into a single file? Our contemporaries would ridicule us if we did that with our PHP files.

Up until, like, Thursday, I thought this way as well.

I guarantee my next big project (after a few small practice projects) will place the "views" and "controllers" where they belong, completely within the browser. This is where the user interaction happens, and there's no need for a server round-trip every time something gets clicked. The "model" is the data store (i.e. the back-end server) - all the client needs is an interface to it. The back-end will be nothing more than the "model" layer, though it will necessarily have it's own routing and controllers (after all, business logic still belongs on the server where the user can't mess with it). Access is through a REST API, and it delivers nothing but data and URLs for static/generated assets.

Is this more difficult? Definitely. Requires more tooling on both ends? Absolutely. Lets me properly architect and visualize the entire project from front to back without any inconsistencies in perception? Yes. This is not MVC, this is VC/MC.

So just curious here -

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 ?

What about minification and obfuscation of js ? And since you are not using jquery, did you manually set event handlers (onclick, onchange) in the html ?

From my personal experience, I had once did a pretty big JS project without using the ES6, webpack flow. And beyond a point of time, it got pretty much out of control. In hindsight, using classes, require directives would have made life so much easier to understand.

> 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.

I appreciate the effort, certainly do. But, and this a big but: the amount of tooling, libraries, complexity and systems needed for a "modern" web app is almost comical at this point.

The create-react-app tool from Facebook lets you create a "modern" (air quotes yours) web app with one development dependency and zero configuration.

https://facebook.github.io/react/blog/2016/07/22/create-apps...

It's surprisingly full featured. Testing, ES6, CSS, live reload dev server, building for production ... everything you need for the majority of React based web app builds. Literally up and running in minutes. Also you can just offload all of the cognitive burden of selecting tools to people much more qualified.

Judge the whole scene by one GitHub project if you will, but the "boo hoo web development is too complicated" meme is getting a bit old now. It's mainly coming from a place of ignorance. Yes it's been a journey for web development over the past few years, but there are powerful and simple tools available now that other platforms and communities could learn from, rather than just disparage.

I'll add a second vote for create-react-app; it's a great tool.

It gets a project up-and-running fast and contains basically all you need. It's not a "boilerplate" that dictates which libraries you use (in terms of Redux, Router, HTTP, etc.).

So here's the interesting part: it basically turns your build into a dependency, with all the pros and cons that entails.

CRA is regularly updated so if you choose to, you can keep your project in sync with the latest fads/features in builds -- snapshot testing, minified production build, hot module reloading (coming soon), etc. Of course, like any dependency, there's the risk of breaking changes.

It's a tradeoff, but a pretty good one in my opinion. Having been part of a couple projects that started in Grunt, then moved to Gulp as the Grunt build was getting slower... it's painful to have to retool the build system, basically ever. "Set it and forget it" works great for a few months, but there always seems to be some new trick to make things faster/better/etc that your tool can't do.

I really like the "build as dependency" idea.

Say create-react-app stops being updated / maintained in a year or so, how hard would it be to "untangle" my project from it? With Javascript communities moving so fast, I worry about being left behind, or not being able to update when I need to (or the inverse, not being able to stay on a stable version)

Just one command to decouple your project: "eject"

https://github.com/facebookincubator/create-react-app#conver...

It's funny, but if some of these people griping about web development tried to unpack their favorite enterprise framework, like Spring MVC or whatever J2EE/.NET architecture they are running, there would be way more packages and bundles wrapped up together. It's just the web is finally getting to a good place.

Yeah, difference is between a "standard library" with a million components, and a million independently distributed components. With the usual tradeoffs between centralization and competition.

How do you think you get to a standard library? How do you package the best tools when you don't know what the best tools are?

How long do you think something like that should take? It's already been 25 years... I think it says something about the browser ecosystem and the language itself.

The entire WPF ecosystem for example was developed and refined in a fraction of this period. Heck even .NET itself is only 14 years old.

I don't think that's really a fair comparison. I would argue that you should start counting from the adoption of UMD modules and npm for package management, since a universal package format and dependency management are requisite for an ecosystem to get of the ground.

Languages with one single corporate implementor obviously will centralize and standardize their library. Languages with a bunch of competing implementors stay fragmented. JavaScript is a lot like C++ in this regard.

Javascript development as you see it today started budding with Mootools, Prototype, jQuery, YUI, etc. Wasn't until the early 2000s that the concept of unobtrusive javascript was even a thing. Then bundling assets came, asset pipeline concept from the rails world got popular in javascript land, then you had all the grunt, gulps, webpacks come into the picture -- Point being .NET came out in what, 01? So Javascript has a few more years, I think we will be in a good place in a couple of years. Besides that point, how much work behind the scenes before .NET was even ever released to us was going on? How many man hours of development was put before that first public release? My guess is a lot more than we think.

The "one dependency" quoted is "react-scripts"[0], which just acts as an effective meta-package for auto-including 45 other dependencies.

That said, treehau5 has a point. This shouldn't inherently be an issue in devDependencies, unless there are individual problems. The end product is what's important.

[0] https://www.npmjs.com/package/react-scripts

Of course it's coming from a place of ignorance - that's where all new devs start, right? This one is perpetuated by the fact that whenever a dev pokes his head into the web dev world, the tools are different than the last time they checked.

Not that I'm not using JavaScript to do things, it was never meant to do, but I don't know, using "modern" or "comprehensible" in same sentence with "JavaScript" always makes me giggle.

There's nothing modern about a website that does nothing without JavaScript

https://nolanlawson.com/2016/10/13/progressive-enhancement-i...

Describing that collection of tools as "minimalistic" was indeed a touch of irony.

Angular (1.x) might not be "cool" anymore, but it can be pretty darn "minimal" to set up: https://github.com/roboprog/ang-prog-enh

(above not quite done, it's for a presentation I'm going to do in December, but it's pretty close)

React works better for many things - server side rendering for SEO; endless scrawling wall of chunks of more-of-the-same (social media...) - but it's not "simple".

...and I'm just sitting here, using jQuery..

And that works well for some use-cases, as well.

E.g. - I (only) want to read some hidden link data in the original page DOM, then load some page fragments that are taking longer to generate.

I guess I should have said it is helpful that somebody is putting together a tutorial for what they feel is a useful path to a certain destination.

BUT, the author might want to address the "elephant in the room" that there is a certain amount of necessary complexity if you want to meet certain goals.

Yeah that's awesome! I still reference the Angular seed project whenever doing a quick front-end for a prototype.

Are you sure it doesn't seem that way to you because you're less familiar with the ecosystem? Compare it to a Java backend. You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that to be radically less complex than the front-end stack proposed here -- but it just seems that way because a lot of those are "de facto" tools.

  > You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc.

I would pick maven, and add the rest as dependencies inside the pom.xml file (the only configuration file I need to worry about). It would take me about 5 minutes and then I could import the project into IntelliJ IDEA and hack away. I can write a tutorial about it in a single blog post, together with the necessary commands to build, test and deploy the artifact.

With javascript, I need: webpack.conf, package.json, .babelrc and god knows what else. Seems like every piece of technology around javascript (transpilers, packers, dependency managers) requires another layer of configuration, another set of CLI commands, and another waste of time trying to figure out why it doesn't work.

Java is no less complex indeed. I'm just starting to use its ecosystem and I definitely think it has a lot of complexity.

But there are other tools that are much simpler. One example is the Dart programming language. I know it's not very popular here in HN land, but the experience is really really nice. You have a fast, powerful, concise, sane and optionally static typed language with awesome tooling (debugging, introspection, profiling, package management) and great support from Google. All this comes in a single easy to use installer. The only extra thing that you might need to download is a plugin for your favorite editor or IDE. Dart, of course, doesn't enjoy all the hype that the JS ecosystem has, but the barrier of entry is really low, and the tools are extremely polished, stable and very production ready. I recommend anyone who is not scared of leaving the hype train to give it a try.

> Compare it to a Java backend. You might pick Ant, Ivy, Docker, Dropwizard, Guice, Jersey, Jackson, Mockito, JUnit, etc. I don't consider that to be radically less complex than the front-end stack proposed here -- but it just seems that way because a lot of those are "de facto" tools.

For the benefit of folks unfamiliar with Java, Docker is not necessary nor tied in any way to Java. The majority of Java is not deployed on Docker, and Docker is written in Go. In fact, the Java mantra "write once, run anywhere" is accomplished by the JVM, so you don't need Docker. You would need it for other languages not on the JVM.

Also, Dropwizard is just a bundle of libraries (most of those you mentioned), so you don't need to include both Dropwizard and a list of libraries that it includes.

Oh sure, let's pick on the fat kid :-)

Yeah, there's a lot of evil lurking in Java-land, but that doesn't stop people from having to use all those things, either.

A more realistic list would be:

Maven, Dropwizard, Guava, Guice, JUnit, Mockito.

(Jersey and Jackson too, but those are included in Dropwizard so ideally you don't need to care about them) Also, ideally, installing dropwizard, guava, guice, junit and mockito consist of just adding 5 lines of XML to the pom.xml file for each - no configuration needed.

Of course if you fall out of the ideal world, things can get ugly. The horrors if two dependencies insist of using incompatible versions of Jackson but Maven insists that you can only use one version of it in your project at a time...

The thing is - other platforms have a 'happy path' that covers a lot of use cases and is straightforward to setup and use. JS, similar to C++, does not have this.

It depends on what you're building. I think Java really shines better in the backend long-lived services realm. If you're just writing something that doesn't need any fancy "web" layers plain Java in a plain Eclipse project is all you need to get going. Nothing more. You just need to know how to type and what you're trying to do and most things you want to do are very easy to accomplish.

You can replace java with javascript and your sentence is still 100% true.

And I think that's the point many are trying to make. It's not overly complicated, it's just that people are trying to use every tool they read about without understanding it or why it was created.

If you are making a website for your restaurant, you don't need react, webpack, babel, sass, etc... You need a few hundred lines of html and like 20 of javascript and you are good to go. But if you are building a video streaming platform, then the extra complexity will most likely pay off.

Javascript is a scripting language for the browsers. Its original purpose was to make dynamic webpages by allowing browsers to modify their content according to some basic scripts.

If I replace "Java" with "javascript" I get:

  > Javascript really shines better in the backend long-lived services realm.

You realize how ironic that sounds, right? No matter how many language improvements, transpilers, builders, etc. you throw at it, javascript will always remain, at its core, a dumb scripting language for browsers.

Well I can't say I agree in the slightest.

If you treat JS like a toy, it's gonna act like a toy.

Treating it as something else won't make it something else. It will just require a "minimal" stack of 10 other technologies.

Again, you don't need to believe me, but shoving your head in the sand and pretending it's not useful isn't going to do you any good.

Tons of companies are very successfully using javascript for long-running processes on the server side. And it's not exactly showing any signs of slowing down.

Mhm, they have been.

Then they rewrote everything from scratch because as it turns out, javascript on the server side is still pretty damn awful performance wise.

Beats the hell out of Python or Ruby in that department. But regardless, absolute speed isn't the bottleneck in most situations, and in those cases trying to force JS will end you in a world of hurt.

Like most things in life, use it in moderation, and you'll end up much happier. But if you take absolute stances on things, you are only hurting yourself.

I've never been a front-end guy, and now the barrier grows with all these frameworks to make amazing applications still holding me back. Plus the fact that if I have NoScript installed, all my work is now pointless. I hate going to websites that literally don't work @ all if I have no JavaScript enabled, with the exception of HN and those rare sites that have minimal JavaScript in use.

> I hate going to websites that literally don't work @ all if I have no JavaScript enabled

It is no surprise that businesses don't want to spend an extra 20% development time supporting 0.5% of web users. At some point, it becomes a problem for the user - you cannot support everyone.

Progressive enhancement isn't about people with JS turned off. It's about resiliency to failures. That might be network congestion, it might be a mistake in your code, or something else.

Except they could spare 200% development time with only HTML+CSS. Many times the real motivation is monetization. Simple sites like HN that don't get revenue from readership don't need Javascript.

Agreed. Why spend more effort making sites less usable for everyone? If you keep things small and simple, you spend less time developing and they are more resilient

In fairness you definitely do not need everything listed here to have a perfectly fine web app. I think it's more beneficial to add in things when you find a use case for it. You probably don't need 3 unit testing libraries, you don't need Redux to use React, nor do you need Immutable to use Redux.

What's comical (or sad, really) that things built with this often are not even web apps.

I agree, all you really need is webpack and vuejs

Once you get an application set up for the first time you don't really have to change it much, unless you want to take advantage of new features in the browser or Node.

As a back-ender looking to dabble with modern front-end development best practices, I'm encouraged to find guides like this one. Even if the array of available packages and tools appears dizzying, and often times faddish, it's nice to see the many options laid out rather concisely.

I have a decent handle on React and some of its immediately related tools, which has greatly improved my fluency with contemporary front end work. I may not ever use all these tools, but again it's helpful to see their setup illustrated in an easy fashion.

Apart from React, what would be the next most important tool to pickup?

The good news is that it can all be broken down into view library, state management, transpiler, build tools, and test framework. Almost all of these tools fit one or more of these categories. If you pick the one or two most popular libraries from each of these categories and build a toy app using them, you'll be 90% of the way there. The stack listed in this article is the current vogue.

If you're not already using webpack with react, I would recommend putting the time in to learning that. It's a beast and the documentation leaves a lot to be desired, so you'll have to supplement your education with a lot of google searches, but it's quite powerful and flexible.

React has come to dominate the ecosystem so rapidly that for the medium term you're probably fine just sticking with that, and learning complementary tools like various flux or relay/graphQL implementations. Angular is the only other tool I regularly run into as a freelancer, but this is less and less often. Almost all the clients I've worked for in the last six months have wanted react. Of course there are many more exotic stacks that some people swear by, but if your goal is to cover the largest percentage of the job market possible, react and angular will get you there with a minimum of effort.

I would look at adding SCSS to your workflow. It makes writing maintainable stylesheets much easier. The two biggest wins from using SCSS, in my opinion, are the variables and the ability to nest selectors.

The node-sass package (on NPM) comes with a command line tool, so you don't even need to add a separate build tool.

I have an NPM script that executes:

    node-sass -w styles/app.scss -o dist/

The -w flag tells the tool to stay in "watch" mode, such that it will auto recompile your SCSS code into CSS whenever a change is made.

define:irony - a state of affairs or an event that seems deliberately contrary to what one expects and is often amusing as a result.

example: This is a minimalistic and straight to the point guide to assembling a JavaScript stack.

It teaches you how to set up ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow. It

Exactly. I clicked on the link and when I saw the list of libraries alongside the word 'simple', I immediately thought it was a parody or satire site. I kept reading, looking for the joke and wondering why I didn't 'get' it?!?

You don't need ES6, Babel, Gulp, Immutable or Flow.

Now it's just React, Redux, Webpack, and a testing suite.

This is exactly why I don't do frontend development anymore. The number of tools needed to get an app up and running is ridiculous. Add in cross browser compatibility and it's all just one big headache.

You don't need all of these tools to get an app up and running even though reading the tech blogs may make it seem like you do. Frontend dev isn't really that difficult if you focus only on what is really needed for your app at hand.

It's just tiring though. I want to make a simple website. But in order to do it "right" or "optimally" or whatever, I need to flush all the old stuff I know down the toilet (jQuery, etc.) and learn a mountain of new stuff.

Who are you trying to make it "right" or "optimally" for? The developer community or the end user?

Unless your end user is the developer community, I doubt they give a crud if you are using jQuery or all of this stuff. As long as your app is doing what they want it to do and doing it well, that is what matters most.

If you want to make a simple website, all of this is way over-kill. That is one of the downsides with these discussions. People are lead to believe that all of this is needed to "make a simple website".

I am not at all opposed to learning new stuff especially if it is going to make your job easier, but don't feel you have to abandon your current toolbox and buy into a new one every few months just to keep up. That imo is madness and will only hold you back from getting stuff done.

At my current gig we maintain two stacks:

1. Angular-based template generator for "I'm a backend dev but my manager assigned me to build a front-end, just tell me how to do it"

2. React/Webpack/Babel/etc. stack for the front-end folks who really care about customization and control.

If you don't need to build complex, maintainable web applications for your job this toolset probably comprises more reading/setup than you'd want to do. For me they're a life saver.

Cross-browser compatibility? That is mostly moot with modern browsers. You really do not know how bad it was in the IE5/IE6 days. Browser compatibility is positively dreamy these days. It is getting better.

> Add in cross browser compatibility and it's all just one big headache.

Cross browser compatibility is one of the reasons why these tools exist.

I would give up Immutable because of it's bad performance and often confusing api.

Also I'd give up Mocha, Chai & Sinon for tape, which is way simpler and more than enough:

https://medium.com/javascript-scene/why-i-use-tape-instead-o...

I don't think 'bad performance' is a fair characterisation of Immutable.js. If you're calling .toJS() all over the place it will be doing a lot of redundant work. However there should be no need to do that, if you just pass the data structures around and access their fields directly.

That's not to say that you should necessarily use Immutable.js; if you don't understand the use case where structural sharing in persistent immutable data structures is useful and require it for your application then you should probably just leave this tool on the shelf.

However, if, for example, you are maintaining maps containing many items which are updated frequently, then you may benefit from the time and space complexity of structurally shared maps (Immutable.js) rather than creating a full copy on each mutation (plain JS objects).

> if you don't understand the use case where structural sharing in persistent immutable data structures is useful

No need to insinuate that I don't understand. I've used it extensively in production and I think most code-bases are better off without Immutable.

> However, if, for example, you are maintaining maps containing many items which are updated frequently, then you may benefit from the time and space complexity of structurally shared maps (Immutable.js) rather than creating a full copy on each mutation (plain JS objects).

It was exactly this situation, maintaining maps with thousands of GeoJSON features and working on these items, where I found Immutable to fall short. The parsing/building of the data-structure alone took, If I recall correctly, about 50 times longer than with normal JS-objects.

Gulp is obviously not needed as well. That's the most confusing dependency in this stack imo.

Care to provide sources for Immutable's bad performance?

There is some overhead to its use, both conceptually and with actual performance. I wrote a comment a while back describing some concerns with using it [0]. I also have some links relating to potential performance issues as part of my React/Redux links list [1].

[0]: https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra...

[1]: https://github.com/markerikson/react-redux-links/blob/master...

haven't tried out Tape but if I could get rid of 2 libs and just use one then that's great.

FYI: if somebody doesn't want to wire everything, there's a pretty good solution: https://github.com/facebookincubator/create-react-app

EDIT: just to be clear, I think that the tutorial itself is valuable and I appreciate it. I just wanted to post the link to CRA before somebody will come here complaining about "JS fatigue". I use most of the tools that tutorial describes and will use it to learn more about wiring testing-related tools. So yeah - thanks for posting the link and for the author(s) for taking the time to create such resource.

I would suggest to the author to put a "This is not satire" disclaimer at the top of article to discourage users from leaving.

> It teaches you how to set up ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow.

Stopped reading right here.

Am I the only one who thought the title meant actually rebuilding some of these tools from the ground up? Building a stack and using / leveraging a stack is significantly different.

Alternative stack that gets you much of the same stuff with less:

TypeScript, React, Redux, Webpack, Immutable, Ava

- TypeScript covers much of the benefit of es6/babel/eslint/flow, Ava covers chai/mocha, and webpack can cover most of what gulp provides

Yeah ultimately what all this is trying to achieve is to make JavaScript have the basic properties and benefits of many other languages. Unlike other languages, JavaScript was developed in 10 days in 1995 and was never intended to be used as heavily as it is today, hence the gargantuan amount of packages and modules to rectify it's shortcomings.

There are many alternatives to chai/mocha. Ava, Jest and Tape.

I wouldn't consider Webpack an alternative to Gulp. Gulp is more generic. But if you use Webpack you can replace to task-runner part with a few scripts.

When using ES6 or TypeScript I'd also consider Immutable to be optional, because of "const" and "Object.assign()/Spread-Operator".

Also, React & Redux can be replaced with 1 thing, when you use a framework that bundles view components and state management.

Webpack is weird in that it's lumped with task runners/"Make"-like programs but it actually it's a configurable and hackable version of the browser asset pipeline.

Nit: not sure why you mention const. It does not provide any kind of immutability assurance.

I just use const instead of var/let all the time and it prevented me from overriding the variable later, which forced me to write my code a bit more functional then before I used it.

I know that I can still change indirect references or override valueOf() etc.

You probably know this, but for anyone else reading, the problem is that if you assign an object or array using const, the object/array members are still mutable. If you have a tree structure, you have to recursively Object.freeze the entire tree to get immutability, which AFAIK is basically what immutable.js does for you. I also use const by default, but I find that more often than not my variables are trees and lists.

I'm only half kidding but how complex does modern js have to get before it is easier to code business apps in something like unity3d?

This is exactly why asm.js and WASM exist: to enable frontend code to be written in something that's not JS.

good to know. I had heard of this stuff before but just assumed it was yet another framework.

At one extreme, one can build a modern app from scratch with no libraries. At the other, you can over-engineer it with far more libraries than you need. Somewhere in the middle lies the correct answer.

So the key is not necessarily to have a set boilerplate to start from. It is to understand what each tool offers, and why/when it is better then not having that tool. So you can look at a project, and make an informed decision of what stack to build.

Yarn came out this month

To me, Yarn seems like the least troublesome new thing. Is it new and redundant? Yeah, but it's also a drop in AND drop out replacement for NPM.

Many of the other "modern touches" would require you to rewrite your whole app if you concluded something was more trouble than it was worth.

Come Nov 1st, it will be so last month.

Don't forget that next month someone will pull down his trivial package doing uppercase or something and the whole stack (of cards) will come crashing down. Lately there was some great post here on hn mocking all that js framework lunacy. But i guess that joke is old now as well...

But seriously does someone use this to do proper work? And if so does this person expect this to be maintainable in the near future?

Not only do people do this to do proper work, but the major companies people look up to do and want to work at or emulate do. Hence the problem.

Yes.

based on the title, I thought it was going to talk about how to build a modern front end from scratch. That is, "modern" meaning that it meets the user's expectations, fits the realities of how they are browsing, and makes use of the features of current browsers (web sockets, local storage, etc); "from scratch" meaning using only your own code written in vanilla javascript. I thought this was going to be about the fact that you can do compelling work on the front-end without needing to get bogged down in a tangled web of dependencies. I struggle to see how this qualifies as "minimalist".

Are you guys familiar with the term overengineering?

I wonder what % of HN would be unemployed if companies moved away from crazy complex SPAs. Surely how crazy they get is a reason why many here have jobs.

"This is a minimalistic JavaScript stack"

"ES6, Babel, Gulp, ESLint, React, Redux, Webpack, Immutable, Mocha, Chai, Sinon, and Flow"

brutal.

Minimalist python backend stack:

Django, gunicorn, Django Rest, Postgres (psycopg2), celery, redis, requests, nose, factory_boy, freezegun, raven

Building good applications for lots of people requires lots of stuff. Using vanilla JS to build web apps is as much fun as using vanilla python to build a backend.

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.

I believe you quoted me wrong :)

The "guide" is minimalistic, not the stack. The point of making the guide minimalistic is to help folks feel less overwhelmed by the complexity of said stack.

I'm between entry-level and intermediate as a full-stack JavaScript dev, and I'm seeing these tools (or equivalents) as the basics used at the last couple jobs and the ones I'm applying to now. Really appreciate you putting this together. Thanks so much.

Glad I could help you my friend! :)

Nah, nobody's using Brutal anymore. That was last week.

so easy, any 10 year old with 30 years' experience can do it.

Over the years (ok months) I build aversion against JS stacks. I tried to used many of them when they popped up and I was starting new project. But it was never a fit to me. However to give them at least some credit, I read sometimes list of libs they're using for inspiration.

This whole complicated stack of parts is why I don't really like React, you're never 100% sure if what you're doing is best practice. I find Ember to be much better, you only need to install Ember CLI and everything is put together for you.

Ember still has by far the best out of box experience and guides like this make that point painfully well. With Ember CLI you start at step 1, skip all the build steps (babel, webpack, etc...), and move on to learning the framework and getting some work done.

In the end you'll end up with a framework that already has a story for state management, api interaction, client side routing, and a complete testing story.

I've setup the described React stack many times. I like React as a view management library, but it requires a large amount of duct tape to get working and even once it is I still have to dedicate a lot of time to tweaking and maintaining all of these interconnected build steps. There are still tradeoffs that have made React a great choice some cases (namely its reliance on build duct tape allows it to be retrofitted into larger mature apps), but for apps I want to just work out of the box Ember/Ember CLI is an easy choice.

You don't need all those tools. I'm a big fan of browserify and the budo development server.

  npm init
  npm install -g budo
  npm install --save-dev babelify babel-preset-es2015
  echo "console.log('hello world')" > index.js
  budo index.js --live -- -t [ babelify --presets [ es2015 ] ]

Add tape for some tests and you're done.

The "... from scratch" part made me think of actully implementing a Javascript based browser environment from first pronciples and not just of a list of random third party libraries.

"From scratch" tutorial, that tells you to go learn react elsewhere then come back...

An excellent description of the stack and an able "defense". Thank you very much

I don't use testing frameworks, no point to it.

This is ridiculous.

subbed

What's the author's credibility? I know it's free, but why should I give my time to read this compared to other resources?

I don't know how to say it without sounding like a dick, but the amount of long "learn web dev" resources by people who can't write well and whose only ethos is just being a programmer is ridiculous.

Well, for what it's worth, he has a Masters in Computer Science, his open source Initializr project is pretty popular apparently, this tutorial has 3700+ stars on Github, he wrote a book on HTML5, and was a front-end engineer at Yelp.

You can see his Github here https://github.com/verekia And his resume here http://verekia.com/resume/

Edit: I find the article to be fairly well written, and I do have a background in reporting and am a full time dev using most of these tools (although I'm not particularly bound to them).

Reply on news.ycombinator.com