I've been in situations where I've spent weeks or even months re-writing things because I read one more article about how some given approach is better than the one I was considering. Ultimately it doesn't matter enough to make a difference in the real world - your application will not be appreciably better because you used gulp instead of grunt or React + Redux instead of Backbone.
That doesn't mean that there isn't a difference between those things, or that some aren't better than others (I like React and would recommend it) but the choice of tooling is not your main problem[1]. This is going to sound very dull, but your best bet is to make some simple choices, stick with them for a while, and see how far you get. Try to avoid questioning things for a while, even if that feels really unnatural.
I think there's a kind of tooling FOMO that afflicts developers, where we get worried that if only we were using a particular tool or technique then our jobs would be, say, an order of magnitude easier, more successful etc. This is hardly ever true, and if it is true then you will be unlikely to be able to identify the choice you need to make until you've spent a good while building version 1 of your application anyway.
It sucks, but it doesn't end. Every once in a while you're be in a nice place where you're using familiar tools and libraries and doing familiar work, but every new project and technology brings potential new demands to feed the machine.
You can have a long, happy and prosperous career working with a single stack that someone has made work on your OS of choice, but if you don't enjoy feeding the machine, there is a ceiling on your flexibility and problem solving ability.
That's what gets to me the most. I'm fairly confident in my problem solving abilities and coding skills. But I frequently lose all motivation to do good work when 80% of what I do is "feed the machine". There are times when doing it makes sense for the problem at hand, and then I feel motivated, but most of the time feeding the machine is about dealing with shitty code, bad documentation and unnecessary overengineering.
This phenomenon is one also of the biggest reasons people who set out to "learn to code" end up giving up.
Go simple. Pick a language. Start writing code. Stay focused. Only solve the problems that you need to solve, not any problems that you might maybe, perhaps, come across. Don't go shopping for a toolkit until you have tried building something yourself. Especially if you are young - remember that writing code to solve problems that someone else has already solved is not a lost cause; you are learning!
YAGNI: https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
Remember, perfect is the enemy of good.
Today I think it's way too easy to get lost in the flood of of platforms/toolkits/frameworks. When I got started 20 years ago it was a lot simpler - crappier but simpler. :) You might or might not have what it takes to be a good developer - but I seriously see the risk of potentially good developers getting stuck before they learn how to navigate these new-fangled floods of ... stuff. It's like a tax on brain cycles to keep up with it all. If you have no discipline you will end up spending all of your cycles shopping toolkits rather than solving problems and learning how to actually program.
For this reason, projects run by a solo developer tend to use less tooling and process than team efforts; the friction introduced by each new step in the workflow is a major penalty. The solo developer can just opt to ignore all the cruft and use a cheap, lazy option, because there is no communication issue.
This also presents a bit of a dilemma if your goal is to learn a workflow in order to get hired on a team using that workflow, because you will feel like you are making nothing interesting or noteworthy. Your best option is to temporarily change your mindset from "engineer building software" to "writer building documentation".
The person documenting has to play detective and ask questions constantly. It takes them four times as long to do anything because they have to write down the steps and make it digestible. But each time they make progress and write down those steps, they set down a little roadway for people to drive over in the future. They also gain more credibility as an expert in the process.
Excellent suggestion. But also here, focus on a tool and/or workflow is warranted. Meandering the field is very productive; it has its time and place. But it is not a panacea for a deep dive. Sustained focus remains necessary.
Writing documentation can be a rewarding, productive, and, yes, even noble method for taking a deep dive.
Personally, I would suggest, to go at it one at a time. The reason being, these "things" (build tools, frameworks, etc) are there to solve specific problems. If you don't have that problem, then you don't need to understand it, yet.
Pick a project and start building, you might find that you need one specific tool, which then you would use that specific tool or you might find yourself having trouble with a certain design then you use a framework that fits your model. This resonates well with @johansch comment. Over time, you will notice a pattern in your knowledge where jumping from one framework to the other is not that difficult because you are jumping from a higher board knowing the frameworks you already used, this applies generally.
Be depressed but don't give up, the joy comes when suddenly it all just clicks.
JavaScript was hastily designed, has never recovered, and shows no sign of ever fixing the fundamental problems. :-(
What do you mean about maps, and whitespace sensitivity? I've never heard anything about that.
Most languages have features to avoid, JavaScript is no different. Many JavaScript developers use linters to avoid the poor `==` feature. I'm unfamiliar with the argument of the `Map` datastructure implementation being broken. Do you have a reference to that claim?
Javascript development is a total mess. Even very experienced people spend a ton of time trying to navigate that ever-shifting terrain. It's also a very primitive, clumsy language, missing the most basic tools that a developer might want (e.g. first-class includes and packages, for starters). To top it off, in my experience, the average JavaScript developer is quite inexperienced. The good examples of javascript code are outnumbered 100:1 by bad examples.
If you're doing web dev, Ruby and Python are good places to start. Pick a language where there are a core set of experienced leaders who have been working for years, and there's a small set of "right" ways to do things.
Just don't use them for this project. Just build the project using what you know now.
You can pick up that new tooling again at a later stage when you aren't so pressured to deliver something.
99% of being a successful programmer is coming back tomorrow, and getting a tiny bit more done, and learning a tiny bit more.
Relevant Quotes (Sometimes these help me push through)
-----------------------------------------------------------------
> I have not failed. I've just found 10,000 ways that won't work. ~~ Thomas A. Edison
> A failure is not always a mistake, it may simply be the best one can do under the circumstances. The real mistake is to stop trying. ~~ B. F. Skinner
----------------
Actual Advice
----------------
Based on your question and comments, I'd actually suggest you reach out to your friends in the community who know more about the tools that you think you need. They might be able and willing to get you up and running with those tools, so that you can move forward.
For example, I'm fairly junior, but comfortable with testing once there's a framework in place. I've been through this enough that I've reached the point where I can get a basic Jasmine or Mocha framework up and running on my own, but recently ran into a problem where I needed more than a basic set-up. I mentioned it to a coworker and he said I needed Webpack. When I expressed concern about spending time learning and setting up Webpack, instead of working on my application code, he volunteered to get Webpack in place. As I learn more about Webpack, the process of setting it up for my next app should be less intimidating.
------------------
Other Thoughts
------------------
I love this meme - http://i.imgur.com/5mAUQj2.jpg - If you're a programmer, you've certainly experienced both states. While I think I run about a 1:1000 ratio, when I've spent a significant amount of time on the right, I try to remember the sensation of being on the left and I know that each mistake is one less mistake I can make and therefore moving me toward the left.
And one last, very relevant quote...
> Do not fear mistakes. You will know failure. Continue to reach out. ~~ Benjamin Franklin
[edited for formatting]
Ultimately the times you are learning/improving the most are when you are facing many new challenges.
If you are anything like me, you may find trying to find ways to enjoy this time more helpful than trying to bypass or speedup this phase.
Well, it got built and it's been successful for its built purpose. The code isn't exactly pretty but it's fast and not buggy at all.
I spent the last year learning object oriented programming, software architecture, ui toolkits. I'm just starting with react, typescript, node, aws for my new app.
Because I built my first app 'the hard way' I now appreciate the value of these toolkits and frameworks and think they're worth taking the time to learn, but only if they simplify my process and not complicate it.
Keep working you'll get there and it's worth it!
EDIT: This is important, so I want to say it as clearly as possible. FUCK. ES. 2015. ES5 is actually pretty good. Learn prototypical inheritance, or just don't use OO. People have built real apps in ES5, you'll live. It might be hard at times, and you might have trouble learning, but the important thing is that you'll be writing code, not fixing your toolkit.
It's COHESIVE. You have an idea and want to work on it? It'll just work, no bullshit gluing together bits and pieces from other libraries. It's comes with realtime, javascript everywhere, documentation is on point.
I can guarantee it's going to restore your faith because you will spend most of your time writing your features and ideas, instead of glue work. Nobody likes glue work.
---
Where do I start? Right here: https://www.udemy.com/learn-meteorjs-by-building-10-real-wor... - you build ten real world apps, not some shitty task list garbage. I promise you won't regret it, it's -fun-. Like that first time you used Rails way back when? That kind of fun!
[1] https://github.com/tylermcginnis/re-base
So it's not just you. I would never set any of this up from scratch for a personal project. And I don't expect you'd need to, ever - established companies will have an existing pipeline (with its own problems you'd never learn externally), and new ones can just use one of the various boilerplate project templates.
Don't give up and keep learning!
There is a proliferation of [boilerplate projects](https://github.com/xgrommx/awesome-redux#boilerplate) out there at the moment but they are quite heavy and all do things a little differently.
I think what is lacking and will emerge eventually is some glue to fill the gaps that everyone is identifying. I think it will be a few small core libraries with some conventions about project structure, toolchain, and modularity.
Use less-shiny stuff. Ditch the frameworks etc. Do the simplest thing.
Don't get hung up on tooling. Things like babel, webpack, ORMs, graphQL, gulp, react, redux, etc etc etc. They're all useful things that have a place in the world. If you try to grok all of them all at once you'll send yourself insane. You don't _need_ any of them. Not a single one.
Just write some code to solve the problem in front of you. Then write some more to solve the next one. Then come back and refactor. Then write some more code and solve some more problems. Keep going like that. You'll end up with a useful thing at the end of it.
The thing you end up with may not be as modular/scalable/etc as something a seasoned professional could build with All The Tools. That's fine. It'll work.
Importantly, though, some slightly muddy, homebaked code will meet your needs a hell of a lot better than a collection of half-understood learning about the most fashionable frameworks of 2015 and no actual code.
For example, I really can't afford to program with any JavaScript language except ES2015 - I just don't have time to try to understand all the weird idiosyncrasies and underpowered crap that is older versions of JavaScript - I need to work with "JavaScript that makes sense" i.e. ES2015. But to do that I need to be able to wrap my head around - and fight all the myriad problems with - getting my ES2015 to compile using the webpack babel toolchain.
It's a strange thing about programming that to understand the easiest way to do it you need to have a higher order understanding of the entire programming system that you are working with.
I feel like this statement is the crux of the issue. Have you considered that your opinion is simply wrong?
Everyone else: Stop running into walls then.
OP: But they are so shiny. I think running into them is the best way forward for me. Please keep me a trick that allows me to run into them without pain.
Everyone else: Eh..
Think brutally effective rather than elegant or modern. The simplest most old fashioned method that will work is often good enough.
> The trouble is that you need to learn those tools and languages before you can get to do it the easy way.
this is never some weird tradeoff, this is simply people selling you bullshit and you buying in.
I thought it was all a mess too and wasted a few hours.
babel ./*js -s -w -d ../../target/
Move on to solving real problems with code.
I agree with your sentiment that you should try at least get es2015 going though.
Good luck.
I'll second what others have said; you really don't have to use every framework. I really don't see anything wrong with building it with the simplest tools possible, and then if you feel like you need better tooling finding something which fixes your specific problem.
Honestly most things are there to fix some use case, but in my humble opinion you're better off running into said use case before using some framework because you'll understand the problem it addresses and abstractions always leak.
Load in an instagram feed. Query some api and show results. Have one model and make a basic CRUD app around it (todo list?).
Do that several times (seriously).
Eventually, when you understand all the basic pieces, start tying two of those things together in one app. You'll learn new things.
As you go on farther, you'll learn the whole stack piecemeal, in digestible amounts.
I'd say that what needs to change is your mentality.
There's a lot of things you can do to change how you're thinking. It all comes down to understanding the essence of why you're feeling this particular way.
What are you trying to achieve?
There's so much that can go wrong in modern web dev it seems.
The tech stack I'm using is: Nodejs backbone mongoDB
Is this the kind of thing you mean by modern JS approach?
You probably already aware but just in case your not one possible option for you is to try a vm like virtual box using one of bitmani's pre configured systems
It's not a silver bullet but it may help
PS
If you do give virtual box a go don't use shared folders, at least not until you have got your build tools installed and running.
I'm working on an application that has about 15K lines of hand-prepared React/Flux JavaScript (well, TypeScript) and it is planned to scale up by maybe an order of magnitude eventually. It's built with ES5 and plain old revealing modules. I'm managing dependencies by hand. I'm not using Node or CommonJS modules at all. Heck, I'm not even using JSX yet because my version of Visual Studio doesn't have TSX (TypeScript+JSX) built in. Does this mean some headaches and extra labor? Sure! Do I feel like an imposter when reading about all this awesome fancy new stuff? Sometimes!
But the headaches are surprisingly minor and barely figure in most of the time. If/when these headaches get bigger (I suspect this will start in earnest when more front-end developers join the project), then I'll take another look at integrating a module loader, or a form generator, or an automagic React router, or a super-cool atomic state system like Redux. In case you're wondering the application works amazingly well and most of the time implementing even far-out crazy features has been easy and fun.
Finally, don't get too worried about making the "wrong" choices, and don't bail out for something newer when you hit your first roadblock. Most of the options you have available these days work great! The things we expect them to do are totally incredible, that's the only reason people are still proposing alternatives all the time.
[0]If you don't need to support older browsers, ES2015 is pretty easy to include. Otherwise if you need to use examples based on an ES2015+ version, just paste the code into the Babel REPL: https://babeljs.io/repl/
[1]You can get any bundled npm module here: https://wzrd.in/
Programming is much about learning and it never gets easy when you need to pick something new. I suggest you find a mentor if you don't like experimenting alone, somebody who can give you some guidance.
After you learn something, it gets easier, and very rewarding.
On the subject of "not having what it takes", I disagree. Find a friend who draws, sings, plays an instrument or whatever, and ask them to tell you how much effort they had to put to learn their craft.
"Computers" are probably a lot easier, at least in comparison, since you have to use them anyways.
Solve some of those puzzles once in a while, no tooling necessary. Or if they are too easy, go to project Euler.
I also feel the same frustration of JS tooling. It's just not a lot of fun to go through so many steps before you can actually start coding. I hope it gets better once the basic setup works.
It'll save you the headache if configuring and setting up everything, and with a feature complete framework like Rails, you'll hit the ground running and be cranking out features in no time.