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

https://github.com/verekia/js-stack-from-scratch

by lobo_tuerto • 10 years ago

366 192 10 years ago

iyn• 10 years ago

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.

anon1253• 10 years ago

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.

TheDrizzle43• 10 years ago

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.

ng124• 10 years ago

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.

Roboprog4• 10 years ago

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.

rootlocus3• 10 years ago

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

ceronman• 10 years ago

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.

rubber_duck• 10 years ago

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.

gravypod• 10 years ago

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.

jonaf• 10 years ago

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.

xg152• 10 years ago

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

Roboprog4• 10 years ago

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

Roboprog4• 10 years ago

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.

xg152• 10 years ago

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

elnado3• 10 years ago

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

rimantas• 10 years ago

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

Wintamute• 10 years ago

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.

treehau52• 10 years ago

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.

lucideer• 10 years ago

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

KON_Air• 10 years ago

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.

dceddia• 10 years ago

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.

swsieber• 10 years ago

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.

Touche2• 10 years ago

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

hhsnopek• 10 years ago

I agree, all you really need is webpack and vuejs

giancarlostoro2• 10 years ago

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.

beejiu• 10 years ago

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.

garysieling• 10 years ago

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.

cel1ne2• 10 years ago

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

flanbiscuit• 10 years ago

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

vmasto2• 10 years ago

Care to provide sources for Immutable's bad performance?

acemarke• 10 years ago

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

BigJono• 10 years ago

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

mambodog• 10 years ago

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

cel1ne2• 10 years ago

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.

bsou• 10 years ago

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

k__2• 10 years ago

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.

vmasto2• 10 years ago

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

Matachines4• 10 years ago

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.

elnado3• 10 years ago

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.

rhodri• 10 years ago

Yarn came out this month

ourmandave• 10 years ago

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

LordHeini• 10 years ago

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?

jasonthevillain• 10 years ago

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.

dglass• 10 years ago

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.

20years2• 10 years ago

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.

ythl• 10 years ago

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.

onewaystreet2• 10 years ago

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.

steveax• 10 years ago

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.

sospep• 10 years ago

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

cyberferret• 10 years ago

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?!?

dclowd9901• 10 years ago

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

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

giancarlostoro2• 10 years ago

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.

bikamonki• 10 years ago

Are you guys familiar with the term overengineering?

Matachines4• 10 years ago

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.

nulagrithom• 10 years ago

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.

morgante3• 10 years ago

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

threeseed• 10 years ago

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.

wheelerwj3• 10 years ago

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.

jomamaxx2• 10 years ago

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

cgag• 10 years ago

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

Retozi• 10 years ago

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.

Cyph0n• 10 years ago

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?

ateevchopra2• 10 years ago

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.

ateevchopra2• 10 years ago

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 :)

khc• 10 years ago

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?!

Klathmon9• 10 years ago

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.

gotofritz5• 10 years ago

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?

elcct• 10 years ago

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

djfm• 10 years ago

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!

Klathmon9• 10 years ago

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

meddlepal• 10 years ago

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

paulryanrogers• 10 years ago

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

gotofritz5• 10 years ago

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

novaleaf• 10 years ago

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

jomamaxx2• 10 years ago

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

snorrah• 10 years ago

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

lloyd-christmas6• 10 years ago

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

ivanhoe• 10 years ago

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.

facorreia• 10 years ago

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.

czep• 10 years ago

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?

pault4• 10 years ago

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.

dwaltrip• 10 years ago

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.

johnwatson112182• 10 years ago

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?

majewsky• 10 years ago

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

johnwatson112182• 10 years ago

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

codingdave• 10 years ago

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.

Matachines4• 10 years ago

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.

dvdhnt• 10 years ago

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

finchisko• 10 years ago

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.

tomcam• 10 years ago

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

stevoski• 10 years ago

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.

joshkpeterson• 10 years ago

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

kayamon• 10 years ago

Until next month, when Flamphf replaces Yarn.

pault4• 10 years ago

Welcome to front end development. :)

gotofritz5• 10 years ago

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.

Klathmon9• 10 years ago

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.

Kiro• 10 years ago

Step up your game.

skizm• 10 years ago

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

morgante3• 10 years ago

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.

ng124• 10 years ago

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.

kennell• 10 years ago

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

Stopped reading right here.

blueside• 10 years ago

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

jfe• 10 years ago

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

zemo• 10 years ago

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

disordinary• 10 years ago

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.

be_erik• 10 years ago

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.

captainbenises• 10 years ago

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.

Achshar2• 10 years ago

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.

frik• 10 years ago

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.

metaloha• 10 years ago

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.

agnivade• 10 years ago

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.

Achshar2• 10 years ago

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.

tribby2• 10 years ago

"This is a minimalistic JavaScript stack"

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

brutal.

bendavis381• 10 years ago

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.

tribby2• 10 years ago

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.

jverrecchia2• 10 years ago

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.

vnchr• 10 years ago

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.

mcbits• 10 years ago

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

manish_gill• 10 years ago

This is ridiculous.

fsloth• 10 years ago

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.

gagsrg• 10 years ago

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

ge96• 10 years ago

subbed

Raed667• 10 years ago

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

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

Related Stories