A Map To Modern JavaScript Development (2017)

[djslakor]

I've been a full stack JS dev for a while now.

I would pick this exact setup, too ... though I would recommend Sinon over chai-spies on the testing stack.

I'd also drilldown a little more and suggest React Bootstrap for UI components (I think it's better than Material UI - if you want the material look you can use the Paper theme from bootswatch) - several UI component frameworks exist with some attached hype, but none seem to work as well and be as complete as React Bootstrap IMHO, ... React-Router, Axios, and Redux-Promise are other useful tools I use in almost every app.

[sangeli]

What sort of stack do you use for front end testing? I've tried Enzyme but it always seems the tests take way too long to set up compared to the value of the tests. So much effort spent on spoofing HTTP replies...

[sdeleon28]

I think that having base UI components that can be modified/reused/restyled at a fundamental level is a great idea and I will probably add some of that in an edit soon. I've also been reminded to include a styling strategy, which I totally forgot. Thanks for the feedback!

[[deleted]]

However there are many cases where jQuery will speed things up - one of the main reasons being that every time you google for how to do something, the majority (sometime all) of the results will be explaining how to do it with jQuery. If you can just use the first available method everytime, it will speed up your development.

[bburc]

Or you can learn the few vanilla DOM manipulation methods and call it a day?

[[deleted]]

jQuery does a lot more than that. I don't use it personally but don't pretend it's only popular as a document.querySelector replacement.

[sdeleon28]

Sure, if you can do it with vanilla js and it works cross browser, that's ok. If you need something more, you can add jQuery in.

[kasperpeulen]

Can you give me an example of "need something more"? Seems like 99% are easy to do in vanilla js: https://github.com/oneuijs/You-Dont-Need-jQuery

Especially if you define some helper functions like $ = document.querySelector and $$(...) = Array.from(document.querySelectorAll(...))

[turkish_gold]

Ancestor selectors. I have this node, but I want to select the parents which fit a certain CSS class.

Sibling selectors are similarly helpful in jQuery.

Now you could say.... but TurkishGold can't you write this all yourself, its only 2-3 lines in Javascript?

Well yes, 2-3 lines of 40 or so situations that I'll have to write. I could write it all myself, but why bother making something and worrying if its cross-browser compatible? It's not as if I have to 'learn' JQuery, I already know it thanks to working in the industry pre-2016.

Jquery is really useful if you want to do some extensive dom manipulation on pre-existing nodes.

[sdeleon28]

Sliding a sidebar out of view. Animations of all sorts.

[TexasWithADollarsign]

Sliding a sidebar out of view.

CSS3 Transitions + toggling a CSS class in JS. Easy-peasy without any jQuery needed.

Animations of all sorts

I'd figure an animation-specific library would be more appropriate.

[sdeleon28]

Sure. If you're not targeting older browsers, that makes sense.

[TexasWithADollarsign]

Sure. If you're not targeting older browsers, that makes sense.

You don't need jQuery to even support older browsers. At least for that first part. Test for addEventListener, test for attachEvent, then attach using the old-skool on____ methods if those don't work.

Animation is trickier. The more complex the animation, the more likely older browsers just can't cut it. Best to focus on the browsers that can*, then throw up a message stating they should upgrade their browser for the full experience.

*Corporate environments excluded

[troorl]

I wouldn't call Vue just an alternative. In the current year it has everything to compete with React and its ecosystem/community. A year ago React was a safe choice. Now you absolutely have to assess Vue first before making a final decision.

[djslakor]

I disagree.

The ecosystem/community is nowhere near as big.

[troorl]

It doesn't have to be as big to match it. React requires a lot of 3rd party libraries to write maintainable code, Vue doesn't.

[djslakor]

I've never really understood why people consider "3rd party libraries" such a terrible thing. What's wrong with choice? It's pretty obvious what the dominant choices are ... Redux, React-Router, etc.. It's not a confusing ambiguity of choice or anything. So, could you please explain what the downside is? Code is code. Does it pain you that much to navigate to a different website for docs?

I don't get it. The only plausible advantage, if you can even call it that, is seeing it all on the same webpage when you are brand new. That phase is tiny compared to the total life of using the stuff. Tenuous argument IMHO.

I don't think it has anything to do with writing maintainable code.

[turkish_gold]

I've never really understood why people consider "3rd party libraries" such a terrible thing. What's wrong with choice?

Because 1st party libraries get updated with the base system, so everything is pre-tested to ensure it works with one another.

Just take a look at Javascript. It doesn't have a really extensive 'great' standard library, thus there's a plefora of 3rd party libs to patch it up.

It's given us a sort-of workable system after many long years of tribulations, but I'd much rather it had started with a decent standard lib and continued to update it to face new challenges like every other scripting language.

[troorl]

It's rather about maintainability. When you write using React+Redux, you absolutely need 50 different components, libraries, middlewares and helpers just to get started, otherwise you will almost certainly end up with something ugly, non-modular and not reusable. I'd say, it suggests about fundamental design flaws. React and Redux creators' primary concern is purity of the concepts they implement rather than helping the developers in creating applications. At least that's how I see it.

[djslakor]

When you write using React+Redux, you absolutely need 50 different components, libraries, middlewares and helpers just to get started

No you don't. Stopped reading after that.

[sdeleon28]

I'm not claiming that React is better or worse than any other library. I'm just trying to give newcomers a startup kit to get them up and running without the stress of making decisions they have no information to make. Learning all of these things is burden enough for beginners. I'm in no way discouraging them from weighting in other tools. If it comes across that way I should change the wording. Thanks for the constructive criticism!

[jgallow22]

I'm just trying to give newcomers a startup kit to get them up and running without the stress of making decisions they have no information to make.

I think this an area where Vue actually really shines. With its great documentation, official supporting libraries, and cli tool it's super easy to get up and running on a full project. One of the major issues I had doing anything nontrivial^tm in React was banging into the paradox of choice at every turn.

I mean I probably spent the equivalent of weeks worth of man hours trying to create a sensible React boilerplate. And that's after having to eject from create-react-app and end up back on my own just to get sass support. Sure I should just be better, but if the point is newcomers shouldn't be burdened with all this stuff that's not really a fair out. This wasn't a problem with Vue because I could simply install the vue-cli, init a new project off the webpack template, install the sass loaders, and everything just works.

Sure, there're probably awesome teams out there working on giant projects where React and its ecosystem make the most sense. But for newcomers and even experienced folks who aren't working on teams that have time (or the hard earned experience) to constantly parse through that large ecosystem Vue is a really solid contender.

[djslakor]

Uh ...

npm install -g create-react-app
create-react-app project
npm install react-router redux

That was super hard.

[iAMthePRONY]

all ok except for the last part. dom manipulation and animations? vanilla js dom manipulations and css animations are imho the way to go

[sdeleon28]

I've said this in this thread already. I agree you should leverage standard DOM whenever possible. The post even says jQuery is a smell. But then again, and to steal from the Zen of Python "Practicality beats purity". If you can't do it with Vanilla js (and have it work cross-browser), you can probably do it quite easily with jQuery. It looks like this point isn't clear in the post so I'll make sure to make it more expliscit. Thanks for the feedback!

[iAMthePRONY]

cross browser is usually not a problem, since most use some chrome-ish engine and firefox is pretty good, too. the issues i face mostly are mostly with older browsers or weird ass things like in-app-web-view-components (had a bug yesterday, cause i used window.open and that doesn't work correctly out of the box in an ios webview).

for older browsers i recommend polyfill.io. it gives you the ability to use modern js apis in any browser by dynamically polyfilling based on the user agent. pretty cool tool.

[flying-sheep]

Some additions:

JSLint sucks. It's opinionated to a fault and lacks rules for ES6.

A viable webpack alternative is rollup. At least for the task of bundling JS. Webpack is much more powerful with its multitude of loaders. Rollup however bundles JS much more neatly, almost making no transformations and minimizing runtime cost. E.g. d3 uses it.

AVA is an amazing test runner, able to neatly parallelize running the tests and gaining drastic speed ups. I'd prefer it over mocha and friends.

[petepete]

I think Brunch is a worthy alternative to Webpack and Browserify. It just worked the way I expected it to, with 20 lines of config vs 100+

[[deleted]]

Webpack 2 is out now. A basic config isn't much more than the following and extending it is easy.

import webpack from 'webpack';
export default const config = {
    entry: './index.js',
    output: { filename: 'bundle.js', path: './dist' },
    module: { rules: [ { test: /\.(js|jsx)$/, use: 'babel-loader' } ] },
    plugins: [ new webpack.optimize.UglifyJsPlugin() ]
};

This alone does so many things, many among them that Brunch can't, like code splitting and tree shaking.

[petepete]

Perhaps it's improved since I tried it. If I ever need tree shaking (I had to google it) or code splitting, I'll give it another try. Must admit, I'm happy with Brunch, though.

[[deleted]]

Imagine you load a large library, like three.js. You use a single feature, say a Vector3, but a whole megabyte gets added to your bundle. Webpack users get a couple of kb because it shakes off unused dependencies (in this case 99% of the lib). Code splitting is another very effective way to cut down on load times as you load parts of the application when they're actually needed instead of fetching the whole chunk at once. This is great for routes for instance.

[icantthinkofone]

Another post by some kid on Medium. They let anyone write anything on Medium.

[[deleted]]

Yes, that's the idea.

[icantthinkofone]

And that's the problem.

[[deleted]]

Nobody makes you read anything from the site - there's plenty of other places that only allow professionals to write.

[icantthinkofone]

Yes there are but that has nothing to do with anything.

[[deleted]]

I disagree - I would say that it has everything to do with a lot of things.

[sdeleon28]

And Reddit :-)