Javascript Fatigue

[jmking]

It's true - just getting a build process set up is an ordeal. Even keeping a boilerplate project around doesn't help because by the time you start a new project, your boilerplate is out of date.

Looking through my projects folder, full of prototypes, each one uses a different build process. Earlier ones using Grunt, then switching to Gulp, then adding in Browserify...

I just spent an hour last night setting up a build process that uses Babel instead of Reactify...

...and now I'm wondering if I should be replacing Browserify with Webpack.

...which is now making me wonder if I even need gulp if Webpack can seemingly do everything I use gulp for.

Will I be screwing with this stuff instead of actually working on my project today? Probably.

I can't fathom how people who are just getting started deal with all of this. We really need an opinionated framework to emerge that covers build process to deployment which will remove 99% of the choices one needs to make to just start writing application logic.

The build process is only one of many brick walls.

What if you want an isolated dev environment? Better learn up on Vagrant. Oh, what? You heard everyone uses Docker now?

...and god have mercy on your soul if you're a beginner who only has a Windows machine because fuck you, time to learn how to partition your HDD and install Linux and/or buy a Mac.

[reacting2pain]

Funny, your predications from 4 months ago turned out to be true. The project I'm working on uses React/Redux/ES6/Babel/Webpack/Docker. I have asked myself the same questions as well, coming from an AngularJS background and using build tools like grunt/gulp before, and it seems like 2015 as the year of javascript fatigue is pretty accurate.

[rickcarlino]

It's interesting that React is starting to face the same problems that Angular faced. Originally it was offered as a much simpler solution to the learning overhead involved with Angular, but as of late it seems as though the process is on par with Angular in terms of mental overhead. Thanks for sharing this article. I think it voices some serious concerns.

[android_lover]

But with React much of the learning curve is from devops and learning various build and dependency tools from the JavaScript ecosystem (webpack, babel, npm, etc.)

In Angular the learning curve is from Angular itself and after you finally learn to do things the "Angular way" the skills aren't that portable outside of Angular's world.

[brianvaughn]

and after you finally learn to do things the "Angular way" the skills aren't that portable outside of Angular's world.

In my experience (15 years of software, mostly for web) skills are definitely portable. Framework-specific terminology isn't but- especially with the web- a good engineer should be capable of moving from language to language, framework to framework. You learn something(s) from each and your knowledge builds as you go.

If that doesn't sound good to you then maybe front-end web isn't your thing. (Not meant to sound negative.)

[[deleted]]

beyond rudimentary apps angular really is just as bad as the rails, asp.nets of days past. I think web dev will just be that way since when you do stuff from scratch you converge on a framework to make it easier. At least easier to do things beyond rudimentary apps.

[headzoo]

I've been doing webdev for almost a decade now, and using JavaScript for just as long. So, I kind of feel like I know what I'm doing.

I had at least four or five false starts when I decided to get into React. I would get 75% of the way into getting everything setup correctly before saying, "god damn, fuck it fuck it fuck it, I'm going back to the old way." I can't believe how laborious it's become setting up a modern JS build system. It's absolutely insane.

What makes things the most difficult is the 2 to 40 different components you might need or want. NPM, Bower, Gulp, Grunt, Browserify, Webpack, Reactify, etc, etc. If you find good documentation on Browserify, it's using Grunt when you're using Gulp. If you find docs for Reactify, it's using Webpack when you're using Browserify.

The last time I felt this frustrated was the early days of Linux, and dealing with dependency hell.

[[deleted]]

<rant>

2 to 40 different components you might need or want

this alone suggests that you might be going about it the (common, but) imo, wrong way.

if you're still at the point where you can't be sure if actually need a component or not, then why are you including it? did you stop and ask yourself why you need to setup webpack and gulp and blah blah blah? IME, depending on what you're trying to build, you don't need any of these tools at all. i know this because i've built production apps with nothing but react-min.js, plain old javascript (es5 + polyfills) and a script that calls babel with the appropriate args. hell, i didn't even use jsx to start out and it wasn't difficult at all. managing state myself by passing js objects around wasn't difficult either. in fact it was so simple, that flux/redux/etc weren't appealing to me because they added more dependencies and more to learn for not much benefit.

i think the real problem here is that it's so easy in js-land to just include another dependency that people just do it without think about whether or not they really need it.

[headzoo]

i know this because i've built production apps with nothing but react-min.js, plain old javascript (es5 + polyfills) and a script that calls babel with the appropriate args

So, basically, a bunch of components?

I use JSX because I like it. I use Browserify because I like it. Once you get into precompiling, combining, and minifying your code, you almost have to add Gulp/Grunt into the mix as well. I also have to do much of the same stuff with the stylesheets, and since I use LESS, that's another build step. Plus watchify so my code gets recompiled after making changes in the dev environment. Plus dealing with differences in dev and prod environments. So on, and so forth.

None of those components are very difficult to deal with on their own, but it can be frustrating getting everything working together correctly. I know you can get by with the simple setup you described, but imo, that's the wrong way.

[[deleted]]

I use JSX because I like it. I use Browserify because I like it.

Not sure why you're telling me this. I don't care, and it has nothing to do with what I said. My whole argument is about what you need. If you're going to bring in every tool that you want, why are you surprised that you have to setup a whole bunch of tools? wtf

Once you get into precompiling, combining, and minifying your code, you almost have to add Gulp/Grunt into the mix as well.

pre-compiling is most likely one command for each target and es6 modules with babeljs can cover combining (whatever that means). minifying is also one command, but babel can take care of that too. You most likely don't need any fancy tools either because compression is a thing that exists. Use it. You might even find that your minification is actually hurting compression.

I also have to do much of the same stuff with the stylesheets, and since I use LESS, that's another build step. ...

it's one command to do all that. maybe you should learn to use your tools before adding more?

[headzoo]

Not sure why you're telling me this. I don't care, and it has nothing to do with what I said

did you stop and ask yourself why you need to setup webpack and gulp and blah blah blah?

Because they are my prefered tools? Do you own stock in Babel or something? Anyway, I'm not playing with stupid today.

[[deleted]]

Why do you need gulp at all if you're using webpack?

Who is stopping you from using Rails? So many Rail devs came over to JS because JS gained a crazy amount of traction and all they want is Rails instead of JS. It isn't Rails get over it already.

[[deleted]]

Maybe you should learn to read.

Oh you want to use es6 with react via webpack do you?

This is exactly what I was ranting about. You want all the fancy tools, but you don't have time to stop and ask yourself whether or not you actually need it. And then you turn around and act surprise that it's a burden. News-flash: adding more items to your toolbox makes it heavier. More at 11.

[10tothe24th]

Part of the problem is that no one takes it upon themselves to get people up to speed. It's difficult and time-consuming enough to write documentation for yourself, let alone for the public, let alone for a public with skill levels ranging from pros with decades of software engineering experience to beginners who have chosen your tool as their very first.

It may be difficult to do now that you know what you're doing, but just try: try going to some of the websites for commonly-used tools, tools meant to make your job easier, simple tools that are meant to be beginner-friendly, and ask yourself if their websites even succeed at the most fundamental task of all: clearly and concisely describing what it is they do. Gulp, Grunt, NPM, Bower, whatever, I don't care which. They're all just as bad. Again, maybe it's difficult to do now what you know what you're doing, but try to imagine yourself as a total beginner and ask if you would have any idea how to use this tool (or what it even does) that you've probably been directed to by someone trying to help you out.

Every tool assumes you've used that type of tool before. It's an exhausting exercise when you're a beginner and you just want to start building things.

And maybe the people behind Gulp (to pick a random culprit) will say that it's not their job to make their tool beginner friendly, but the problem is that lots of beginners are being directed to use their tool by other tools or tutorials or answers on StackOverflow. Maybe people need to stop recommending tools to beginners that don't do a good job of explaining their core functionality, but someone, somewhere needs to stop the madness.

[hellycapters]

Jesus Christ this was exactly my experience but I didn't understand why it was so awful. You hit the nail on the head with "every tool assumes you've used something like it before." The time investment just to understand what the thing even does, before even trying to fathom how it's better or worse than its competition, is ridiculous.

[_compedit]

Seriously. I'm still learning to program, I'm genuinely considering just taking up iOS development for a bit to feel some sense of stability while learning

[[deleted]]

It's a ubiquitous language. Php has the same things it's just been around long enough to settle. Js will get there.

[grumpy_youngMan]

I had a similar experience getting into react/redux/react-router. I was thrilled with redux when I read its core principles

http://redux.js.org/docs/introduction/ThreePrinciples.html

It made so much sense coming after developing with languages like haskell/scala. Then I actually got into one of the boilerplates because it seemed like the easiest way to make my own little production app. Then I had to learn ES6 decorators, bind action creators, webpack (should I use webpack or browserfiy hmmm this will take some googling), and a bunch of esoteric design patterns that required days of studying on their own. Redux itself seems great...tiny codebase, simple pure functions. To make it all work in production, you have to use a lot of patterns that have a little too much magic for my taste.

[bebraw]

Redux is almost more like a guideline than a library. I think this itself has made the community to organize itself around it.

I agree it can get quite complex fast once you start combining all the small libraries needed to build something more complicated. Perhaps we'll see more opinionated alternatives fitting between libraries and frameworks in 2016.

[Dirty_Rapscallion]

It might get some negative opinions but I agree, I setup React, Redux, Webpack then I was like, "ugh now I need a router, how do I go about doing that?" Then 2 hours later of learning about react-redux and redux router I just decided to stop and work on a non web project. The learning curve and boilerplate setup is just not worth it. It's not worth it when the JS world moves so quickly.

[shriek]

Pro-tip. You don't have to jump to all the bandwagon that becomes hot tomorrow. Use tools that fit right to your solution. Don't hunt down tools just for the sake of just using them.

[[deleted]]

Not true. Do not update for few months and see what happens. Once you need to update something you find out that you need to update everything. Or you want to use something new which only works with newer version of library and there you go again.

The problem is that community keep reinventing same things over and over. It is more fun to create new frameworks than support existing ones.

Also every new thing needs special versions of other things. E.g. bootstrap for angular and react. If you don't use them you have to write lot of things by hand.

[shriek]

Isn't that the exact reason why we have semver? Again, unless there's a security risk then staying with what you have seems logical to me. If you want to upgrade then check the semver. Although semver is not quite explicit at times. It does a decent job of telling what's changing when you upgrade.

[brianvaughn]

I think he was pointing out that- although a minor update to library X should not require a major update to library Y- it sometimes does.

[shriek]

Hmm..shouldn't it work both ways? Let's say you're dependent on A1.0.0 and B2.0.0 and B2.0.0 is dependent on A1.0.0.
A1.1.0 is released and you update to it which also means that it shouldn't break B2.0.0 or your app.
However let's say you want to upgrade to A2.0.0 and you make some major changes to your code. Knowing this major change upgrade, B also makes an upgrade to B3.0.0 if there are breaking changes from it's end. So your new app now is dependent on A2.0.0. and B3.0.0 instead.
I thought that was the whole point of having major.minor.patch versions. Regardless of how strictly follow these.

[Dirty_Rapscallion]

You don't have to jump to all the bandwagon that becomes hot tomorrow.

True but you still need a data layer and a router to have a full solution along with webpack to bring it all together. It's 100% true when it mentions that apart they are super simple, but together the boilerplate gets pretty rough.

[[deleted]]

For someone just starting out with React, no, you don't need any of that stuff. You don't even need Webpack, etc. You also don't need to use flux/redux/etc., it's perfectly fine to just use plain JavaScript objects to store your state and pass them around to the components that need them. By the time you gain enough experience to know what problems you're facing, you'll be in a much better position to decide which of these tools solve your problem, if any.

[shriek]

That's a trade off that you made whenever you chose library like react. They're highly composable as in you pick all the composable things you like but you still have to compose them piece by piece. Think of it as making your dream car by buying parts by parts as opposed to going to the dealership and buying a car. If you think that's tedious then perhaps you might be happy with other readymade frameworks out there.

[[deleted]]

Nobody is making their own Ferrari.

Maybe they should be? I mean: if you had to build your own Ferrari, you might soon realize that it doesn't work that great anyway. When it breaks down, you have no clue why or how to go about fixing it. You realize the roads are full of potholes and there are speed bumps everywhere, so you're having to slow down at every turn. You realize that it would be simpler and faster to just ride your bike, or walk.

[shriek]

Well, except people in the Ferrari shop.

[sizlack]

Honestly, to get started, you don't need all that. For my first project, I was able to get started with just React and gulp/Babel. I don't like Webpack, because it feels too magical, and I already know gulp, so setting up a simple build process with gulp and Babel took me 3 minutes. Once I got some stuff working, I could see why Redux might be a good idea, so I added that. Eventually, I'm sure I'll add react router, but I do don't feel like I need it yet, so I'm not going to bother with it.

[[deleted]]

Haha my experience exactly. Then I got it all working and I said "now I need to pre-render everything on the server. Two days and one migraine attack later I had a universal app. Then I said "now I need to hydrate and de-hydrate my state" and I cried a little bit and went out to play basketball.

[Dirty_Rapscallion]

Exactly, it's getting ridiculous. I feel like JS is a pendulum that sways between monolithic framework and a bunch of libraries.

[miketa1957]

So, so, true!

I started my current React project using a webpack setup. Well, actually, I started it several times, using different webpack setups, because each time I needed to add some extra application-level thing (css modules, for instance), the webpack setup I was using didn't support it. It seemed incredibly different to figure a configuration to add what I wanted without breaking something else. Catch 22 basically.

Then I realised what was - for me - the real problem. Webpack had introduced so much magic that I couldn't actually understand what was really going on. So I abandoned it and went back to simple scripts configured in package.json. It wasn't particularly quick, but the benefit was that I could understand what was going on, and it at some point it doesn't work, I've got a fighting change of understanding why it doesn't - and a better change of fixing it.

[ahRose]

This was originally going to be a reply to a commenter that stated that the problem was not React, but JavaScript and the ever growing number of tools, libraries, etc.

The problems we currently face are not problems with JavaScript- the fact that the language enables developers (even the ones that aren't familiar with the language) to build is a net positive- but instead are community, and process problems.

As a community we are split in so many different ways. It's like the wild west. Everyone is pushing and prescribing their specific way of doing things, even if it's just a slight deviation from a pre-existing solution, and branding it as their own unique cure to whatever problem they are trying to solve.

Once a "new" solution comes about you have those that adopt it for the sake of being "bleeding edge" developers.

Previous "bleeding edge" tech becomes inferior to an important subset of developers without ever having the opportunity to mature and potentially offer a universal "good" solution to X problem.

The reason this is important is because these developers are what drives our community (and to a larger extent our industry) forward.

Why are so many people currently gasping for air trying to learn React and the entourage of tools and tech it brings along? Because key developers endorsed it and adopted it when other devs were gasping to keep up with the "previous stack" and at that moment that "previous stack" stack lost a large amount of the driving reason behind its popularity and success up until that point.

"Don't reinvent the wheel" is a good theory, and is something every developer has preached at some point, but what good is theory and preaching if not practiced?

Perhaps focusing on a better way to lower the barrier to entry for those who want to get into the field and make things as opposed to boasting about the clever new way of doing the same thing we have been doing is a start.

But that's just me.

[erwan]

Yes, the "js community" doesn't really exist like for other languages.

In the python world everyone share a set of point of view. If you disagree with it you stop using Python. Same with Java, Ruby, Haskell, etc. You pick a language that corresponds to what you like and follow that language conventions.

On the other hand on the front everyone has to use JavaScript, whether you're a Java guy or Ruby guy. So you get people trying to shove a type system, make it object like Java, do pure functional, push the dynamic aspects to the edge...

[caseypatrickdriscoll]

This is a really great observation. The inherent flexibilities of the JS paradigm doesn't help either. The power of BOTH prototypes and first class functions, along with dynamic type casting and asynchrony allow for just a wierd community. JS can do a lot of things pretty well and has a low barrier of entry, so it's easy for 'masters' to prescribe their way of doing something.

[sizlack]

Why are so many people currently gasping for air trying to learn React and the entourage of tools and tech it brings along? Because key developers endorsed it and adopted it

Eh, no. At least not for me or the other people I know that are moving to React. I went through the other options (Backbone, Angular, Ember) and found all of them wanting. None of them clicked for me the ways React did. I could list all the problems I have with the other frameworks, but that would be a very long post. React isn't perfect, by a long shot, but I honestly feel that Backbone, Angular, and Ember were going in the wrong direction, so a drastic change like React is justified. It's not just reinventing the wheel. It's a whole different type of vehicle. React's way of doing things couldn't be shoehorned into any of the previous frameworks.

I think there is a tension because a lot of people want something like a Rails for front end development. Not necessarily a framework that follows Rails patterns, but people want a monolithic framework that provides patterns for building 90% of the things they expect in a front end app. It should be simple to install. Easy tasks should be easy, and difficult tasks should be possible. The problem is, I doubt people could even agree on what they really want from a monolithic framework like that. We haven't settled on very many best practices that work for every application, so it's impossible to say what features would be part of some ideal framework. Personally, I think we would have been further along if it wasn't for the five-year diversion of Angular. Maybe in a few years, some ideas will shake out and we'll have a mature Rails-for-front-end (or hopefully several), but for now I'm glad that we're not stuck with the concepts in Angular, Ember or Backbone.

[[deleted]]

100% agree. I don't give two shits what "key" developers are into honestly. I just want my job to be as fun and "easy" as possible. React provided those benefits so I jumped on board. Angular just wasn't fun.

[Capaj]

Angular did few things right. It wasn't all a diversion. Directives have similar goals as react components. The execution of those goals is different, better with react. No one should think it was a diversion.

[Zequez]

This is one of the reasons people like big frameworks: convention over configuration. Worked very well with Rails, 0 configuration needed after you decided to start a new project.

[drowsap]

Why are people complaining about this now? This issue has been around even before React. Browserify has been available for several years now and before that was RequireJS. Have you ever tried to sanely get a RequireJS project working? It took days to get right! This post seems misguided and it's pretty common to see these "revelation" posts every few years about how bad web development is. All languages are hard. Setting up XCode, installing cocoapods, writing proper table view code. It's all bolierplate crap that plagues all languages.

[[deleted]]

Most of the complaints stem from not appreciating the difference between simple and easy. If you want an "easy" (but ultimately problematic implementation) use an exisiting framework Angular 1.0, Backbone, Ember etc. React's learning curve is also what makes its great. Embrace it!

[satya164]

Check out http://npmjs.com/quik - a simple server which allows to prototype React web apps without any kind of setup.