
Ask HN: Overwhelmed with learning front-end, how do I proceed? - PythonicPro
Hey,
I am currently learning front-end (knew jQuery but after many recommendations and doing backend for a long time decided to &quot;modernize&quot;) with Vue.js components, etc... but feeling very overwhelmed with the big change, and after trying tutorials I don&#x27;t know how to begin coding a real app, even after learning the concepts. Everything I try feels messy and strange, leading me to a lot of frustration. It seems very over-engineered.<p>I also wanted to start trying react but the sheer amount of boilerplate templates to start a project is insane and come with so many things I probably won&#x27;t use. The file trees seem massive in comparison to simpler projects made in jQuery, which don&#x27;t help the stress much...<p>Overall, I am very overwhelmed with what I am seeing in the front-end world, how do I proceed? I don&#x27;t know how to continue this. Any tips? Experiences?
======
carsongross
OK, I know a lot of folks are tired of me talking about it, but if you are
interested only in UX functionality and not necessarily in learning the latest
trendy tools, I have built a library that gives you a lot of what the other
front-end libraries do at a fraction of the complexity:

[http://intercoolerjs.org](http://intercoolerjs.org)

Basically you use HTML attributes to drive AJAX requests, and render your HTML
on the server side. (There are actually very good theoretical reasons for
doing this[1][2].) It is built on top of jQuery and dovetails very nicely with
it.

There are lots of examples here:

[http://intercoolerjs.org/examples/index.html](http://intercoolerjs.org/examples/index.html)

And, again, if you are looking for simplicity in front end development, while
still building a modern web application, I think it's a good option. There is
no tool chain beyond what you currently use for web development.

[1] - [http://intercoolerjs.org/2016/01/18/rescuing-
rest.html](http://intercoolerjs.org/2016/01/18/rescuing-rest.html)

[2] - [http://intercoolerjs.org/2016/05/08/hatoeas-is-for-
humans.ht...](http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html)

~~~
thatsethnz
I created an account to say this: thank you.

Having spent hours and hours trying to find to find my feet in the world of
competing JS frameworks and gui libraries a friend said "Just search for
'declarative ajax' and click the second link". Good advice, because it led me
to intercoolerjs. It's just so straightforward. Twenty or so minutes later I
was back in emacs generating Django views because I knew, intuitively, what I
needed to do to actually get things done.

It's hard to explain to people how quickly you can get working with it but
something like:

    
    
        <a href="#" ic-target="#datadiv" ic-get-from="/latest_data/">Get Data</a>
    

is basically pseudocode. I love it.

------
Klathmon
Is there any specific reason you are trying to use Vue?

If not, I'd recommend taking a step back, look at the few most popular
options, and start with the most "blessed" config/boilerplate with no custom
changes.

Like for react, use the create-react-app thing. Don't add anything on top
aside from what is needed for the bare minimum of your project you are
learning with.

Feel the pain points, feel what you struggle with, make notes about what works
well. Then when you have a minimum viable product, start adding "stuff". Maybe
try out redux, or mess with webpack yourself, try out that library that you
see people on HN bitching about all the time to see if it's really that bad.
Just start fixing the worst issues you had with the language/stack, and
understand how the additional tooling solves (or doesn't solve) your problem.

Don't worry about size, number of files, performance, how messy it is, how
over engineered it feels. Just make something first. You'll have plenty of
time to learn that other stuff once you have a good foundation. And at that
point you'll know to leave out x, or that y isn't over engineered, it's just
engineered.

Rome wasn't built in a day. Expect your first few things to be complete trash,
and don't worry about it.

~~~
eberkund
What's wrong with Vue? Sure it isn't as widely used as React or Angular but it
isn't a small fry either and growing quickly. Plus it is a great first
framework because of the fabulous documentation and learning resources
available. I also found it to have a much simpler syntax than Angular (I can't
comment on React).

~~~
icemelt8
Why can't you comment on React?

I don't really like Vue.js after coming from ReactJS, main reason is how hard
is it to create components, which is the main attraction of React.

This is ReactJS code for a List group that has list items which are composed
of buttons, can anyone post the Vue.JS equivalent code?

var Button = function(props){

return <button>{props.text}</button>

}

var ListItem = function(props){

return <div>I am a item <Button text="click me" /></div>

}

var ListGroup = React.createClass({

    
    
      render: function() {
    
        return <div>
    
        	<ListItem name="hello"/>
    
        </div>;
    
      }
    

});

ReactDOM.render(

    
    
      <ListGroup />,
      document.getElementById('container')

);

~~~
welanes
I'm not versed in React but I think this achieves the same thing -

1\. Create your custom component:

    
    
      var btnComp = {
        props: ['text'],
        template: '<div>I am a button <button v-html="text"></button></div>'
      }
    

2\. Register it:

    
    
      new Vue({
        el: 'body',
        components: {
          'custombtn': btnComp
        }
      })
    

3\. Display it:

    
    
      <custombtn :text="'hello'"></custombtn>
    
    

That's anything but hard. Here:
[https://jsfiddle.net/v5s77r2x/](https://jsfiddle.net/v5s77r2x/).

*Updated with simpler code and JSfiddle example

~~~
woogley
It can even be closer to React than that, especially with JSX render
functions. You don't even need the view to name itself:

    
    
        export default Vue.extend({
          props: ['text'],
          render() {
            return <div>I am a button <button>{this.text}</button></div>;
          }
        });

~~~
welanes
Useful to know. Cheers.

------
sssilver
First, it's important to understand that most of these technologies have
emerged and became popular because they solved real problems. In this regard,
it may be difficult to "learn" them, if you never had those problems in the
first place. If you feel comfortable learning jQuery, learn/use it enough to
run into its weaknesses -- it won't take long. Then moving on will feel more
natural and will feel less like effort and more like pain relief.

Second, I would be more focused on obtaining fundamental programming skills,
like the ones you get taught in academic CS classes, and less concerned about
[insert-your-shiny-"new"-js-paradigm-here]. The reality is, pillars of
programming haven't changed drastically since 70ies, and if you're very
comfortable with the fundamentals, everything else becomes less a matter of
understanding, and more a matter of memorizing ("oh so this is how you do
fundamental thing X in this particular framework").

Finally, as others have rightfully noted, focusing on one thing at a time
makes learning way more efficient. It may seem counter-intuitive, but learning
ten things consecutively will take way less time and energy than learning them
in parallel.

~~~
tluyben2
>and became popular because they solved real problems

Maybe someone should write a blogpost about which real problems they solve per
framework; not only is there a lot of overlap (very confusing for beginners:
people want to use the best not have choices they cannot possibly make at that
early point) and the problems they solve are often really not relevant for the
problem at hand. A lot (most; considering most sites are wp or some other
point and click cms) of people never run into the shortcomings of Jquery or
PHP or Mysql etc.

A blogpost about connecting the fundamentals to modern frameworks and to
specific parts of modern frameworks might be good too. For instance why the
fundamentals are easy to understand and when applied to serverside they are
still easy but when moving to frontend/js it often looks like a ball of poop.

A lot of that is because many of these things are not fundamentals anymore:
20000 slightly different build, pack, deploy etc tools are a good example why
a lot of people I know struggle. Boilerplate du-jour is another one: the
minute you pick one it is outdated and people moved on to some other repos it
seems. Many tools within boilerplates seem overlapping or redundant to
beginners: no one explains why and docs are often written for experts (or:
read the source).

Another point is that unless you have a team with you, it is hard to run
projects when so many changes to these modules and frameworks happen. If you
are a coder working alone it is hard to keep all stacks up to date (security:
less relevant for frontend a lot of they time but still) when they are so
instable API wise.

We do experiments internally but for production we use the tools we know until
things have stabilized. I need to know I can run security updates in 5-6 years
, run the testsuite and be quite confident I do not have to spend a few weeks
refactoring.

~~~
sssilver
> A lot of people never run into the shortcomings of Jquery or PHP or Mysql
> etc

I'd rephrase that as "A lot of people don't identify and challenge the pain
points of technologies they know and use for a while". Yes, that's a common
pitfall and one every developer should be aware of. Question everything. In
the example of jQuery -- "is there a way to bind my data to my view in a way
that wouldn't require diligent manual updates in a highly stateful system that
is now a major source of bugs in my existing design?" In the example of PHP --
"I keep having these bugs with comparing null, false, empty string, and zero,
I wonder if there's a better way", or even "often I have a variable that I
expect to be a dictionary, but it's null, and I have to check that everywhere,
what if nullability could be ensured?", etc. But these questions won't occur
without the solid fundamental base I've mentioned earlier. Because, guess
what, the fundamental theory does include type theory, which does include
nullability.

I don't think the fundamentals are easy at all. I think they're the hardest,
but they're the knowledge that'll never become "obsolete", and will make
everything else relatively effortless.

> 20000 slightly different build, pack, deploy etc tools are a good example
> why a lot of people I know struggle

Yeah too much choice is bad, but since most of them are incremental
"improvements" of each other and obsolete each other, the real choice isn't
that big. Honestly, with something like a JS build/pack system, I would just
grab whatever Google gives me first and wouldn't switch unless it caused me a
headache and there was an alternative that I knew fixes the problem. At the
end of the day they're all just some command-line tool coupled with some JSON
config file. It's not that hard to switch, most of us are not quite compiling
the Unreal Engine.

Full disclaimer: I'm not a frontend engineer, and am only aware of frontend
things on the surface plus the things I infer. I may be unaware of important
details that dramatically change the situation.

------
shados
Frontend at this point is a problem just as much as backend is a problem...
And I don't mean backend as in "I built an MVC app with Rails". I mean JVM +
Data store + infrastructure with virtualization + APIs + caching + queues +
blah blah blah.

You don't wake up one morning going "I know some java...lemme learn Dynamo and
S3 and SQS while learning dependency injection and Spring while figuring out
what this SQL thing is about on Postgres...or should I use MySQL? Oh and
there's Maven and Puppet and all the deployment tools...

That would be totally insane.

Look at frontend the same way. If you're trying to learn react and babel and
ES6 and webpack and eslint and flow/typescript and NPM/Yarn and Node while
looking into Service workers and websockets at the same time as reading a book
on Functional programming, yeah, that's overwhelming.

Pick one thing and a time and go for it. If you're a backend developer and
getting overwhelmed by frontend, it's because you're attacking it from a
"Frontend is an atomic small thing" perspective, as opposed to being an
ecosystem just like on the backend. And that won't work.

~~~
damosneeze
I agree. When we first started teaching React workshops, we taught a 1-day
workshop where we introduced students to React, Webpack, React Router, and
Redux. This was all done with ES6.

Fortunately we had the benefit of selecting from a large number of applicants,
and we required a brief selection examination. Most were already strong in
JavaScript and many even had ES6 and React experience. So learning React &
Redux, and grasping the concept of webpack and React Router was not too
difficult for that group.

However if you're coming fresh into the React ecosystem, and especially front-
end development on the whole, it's important that you don't try to learn all
of these things at once, as many have pointed out here. Our current workshops
are focused on learning React and React alone. For example, our current "build
an e-commerce app with React" workshop gives you a boilerplate with everything
you need, and we build out the application from that point.

We are based in SF but often travel to other cities. Our website
www.realworldreact.com is under development, so you can learn more about us at
[https://meetup.com/Real-World-React](https://meetup.com/Real-World-React)

------
oelmekki
The single most important advice I could give you is : take whatever
path/framework you want, but take it seriously.

Javascript has a long history of not being taken seriously. In early 2000, it
was considered a malware language, that you should disable. Then rails started
doing cool things with animations and ajax, and developers started getting
into it, but only by swearing they did not want to waste their time on it. I
think that's the reason why jQuery got so much success: its promise was that
you could use cool js features without having to learn much about it.
Personally, my big "oh wait, this language is cool" moment has been when I
discovered mootools. It was not unlike what es5/6 is nowadays.

And then, there has been this whole "javascript fatigue" thing. My analysis on
this is that the same phenomenon applies: backend developers know they need to
learn js but still do not consider it a "real" language and are overwhelmed by
the amount of things they have to learn.

By simply considering javascript is just as important as your backend
language, and deserves as much efforts from you, it should not feel any more
difficult. Oh, btw, css matters too :)

~~~
dancek
Indeed. I've seen people who write good code with any JS framework/library,
and then I've seen the snake oil crowd that's always in a hurry to create a
horrible mess using the latest buzzword.js.

This is not to say that all frameworks are equally good/bad, but nothing is
perfect. Once you're seasoned with one framework, you can evaluate others
better.

------
itamarst
1\. Don't try to learn 5 technologies at once. Pick one.

2\. As a first pass, don't overfocus on the details, focus on the conceptual
model: what are the key abstractions, how do they work and how do they
interact?

3\. Read a book, not just tutorials. Harder for newer frameworks, but got to
be something. A decent book will give you a much _deeper_ view than a
tutorial, helping you with item 2 on the list.

4\. Start looking for common themes that connect to existing knowledge. None
of this is _really_ new stuff; front end frameworks inherit ideas from GUI
frameworks, and from backend web frameworks. I've written a bit about doing
this for programming languages
([https://codewithoutrules.com/2016/03/10/compare-
contrast/](https://codewithoutrules.com/2016/03/10/compare-contrast/)), but
same concept applies elsewhere: everything is variations on a theme, basic
functional requirements forcing particular forms.

~~~
PythonicPro
Thanks for the tips! Any books you'd recommend for learning modern front-end?

~~~
brianzelip
I've found the 'You Don't Know JS' series very helpful for understanding JS
from the ground up. In book form or for free via !gh,
[https://github.com/getify/You-Dont-Know-JS](https://github.com/getify/You-
Dont-Know-JS).

~~~
dancek
You Don't Know JS has to be the best and most detailed book about JavaScript
that exists. It might be a bit much for a beginner, so just skim it at first
and come back when something doesn't make sense.

------
pacnw
Ok, I read through this whole thread and with the variety of recommendations
for frameworks and tools mentioned it will make your head spin for sure. You
mentioned Vue, so I will talk about Vue. Vue will get you there in terms of
any complexity you may need. React, Angular, Ember, etc. will also get you
there, but you mentioned Vue so let's stick to that. Wrt boilerplate
templates: just use vue-cli to generate the project, there are not even that
many options, and you get hot-reloading, test harness with it automatically.

To keep it real, I imagine your SPA will need different sections of the screen
to show: a header, some kind of menu (sidebar?) and a main window that shows
what the user is working with for the moment. How do you get the main window
to show the relevant content if the user clicks on a menu item? If you solve
that (hint: vue-router), you now understand one of the main benefits of using
a front end framework for managing components and avoiding round trips to the
server.

Next challenge: create a nice page that has, let's say, two different panels.
One panel shows a list of items, and the other panel shows some details about
the currently selected item from the list. How do you: 1. show the details
about the selected item in the second panel? 2. If you change the item name in
the detail panel, will it update immediately in the list above? Solving for
this will satisfy your curiosity of why a state management solution would be
useful, and you'll be led to ...... yes, Vuex!

These 'challenges' would be enough for a good 90% of common web apps/SPAs,
with navigation and master-detail UI.

Just one piece of advice, pick one current framework, learn it by solving
these common problems, and you'll be on your way. Source: I have built and
rebuilt a complex system in Angular, Meteor, React and Vue (I do NOT recommend
that kind of churn, but keep in mind each framework have had significant
shortcomings over that past 2 years which made client-side state management
difficult). If you take the intellectual route and try to do all this with
vanilla JS or solely jQuery, be prepared to spend a while before becoming
productive (depends on your app's complexity of course).

------
judahmeek
Here's a fun flowchart regarding React: [https://github.com/gaearon/react-
makes-you-sad](https://github.com/gaearon/react-makes-you-sad)

------
fuzzythinker
Learn by doing. It is hard to learn by just reading. You should have something
in mind that you want to build. If you don't or can't come up with something,
maybe you can build an internal tool your company may find helpful, or talk to
friends to see if they need something you can build. Once you have an idea,
then you have a goal.

Since you know jQuery already, that makes it easier to start. Start building
it with jQuery first. Then look for a component or two for which states get a
bit complicated. Replace the jQuery code in that/those component with Vue.
You're already ahead since you've decided to use Vue. Many people are not even
sure what JS framework library to use. Vue is an excellent choice, by the way.

This way, you have a reference to compare to. If you like Vue code better, you
can think about if you want to replace all or most of the jQuery code. If not,
then you can ask why. This may lead you to a deeper understanding of Vue.

------
dcwca
Ask yourself if you're building a website or a web application. The main
difference in my mind is websites are static documents at the end of the day,
allowing users to read text, while web applications are dynamic and often
allow the user to modify the data in the system.

If it's really a web application you're after, then get ready for some
complexity. The state of the art has progressed significantly in the last
couple of years, to the point where modern web applications are as complex as
iOS and Android applications in terms of the number of moving parts. To add to
the confusion, there seems to be a large number of framework and library
choices on the web, where with iOS and Android the vendor largely controls the
environment, and the tooling choices are more obvious.

Try to see the big picture as you're looking at all these tools, and recognize
that they're largely interchangeable. We can see a common architecture
emerging, where the latest versions of all the largest libraries have
coalesced around the same basic patterns and ideas:

\- Web Components (Angular 1 directives, Angular 2, Vue.js, React, Polymer,
Preact, etc)

\- State management (ui-router, Redux, MobX)

\- Network interface ($.get, $http, restangular, W3C fetch())

\- Local storage & persistence (W3C localStorage, ngStorage, react-
localstorage)

\- Build system (webpack, gulp, grunt, jake, make, npm scripts)

\- BDD Testing (Jasmine, mocha, Karma, Chai, Enzyme, Jest)

You really can't go wrong learning any one of these libraries. Even if you
aren't using the same library a year from now, you'll understand the
application design patterns and JavaScript, two skills which aren't going away
any time soon.

Hopefully that helps clarify things, and good luck!

~~~
dom0
> If it's really a web application you're after, then get ready for some
> complexity.

I beg to differ. In many cases it is perfectly acceptable to build a web
application with most of the logic in the server, and comparatively little
scripting in the client. Not everything has to be a one-page app / SPA with
lots of scripting and the complexities of client-side state.

There are also many cases where a SPA is really what is needed and then you
indeed need the complexity of a SPA. (And even without being a SPA a frontend
has plenty of room for complexity)

tl;dr what I'm trying to say here: Know your requirements.

~~~
dcwca
> Know your requirements.

I agree with you and had my own way of saying it off the top of my post. If
your application has a simple data workflow such as "ask server for document,
show document" and "store document on server, show new document" then by all
means do not build a client-side web application.

However, fully reloading a document for interactivity is a very crude model,
and doesn't allow for complex interactions, state transitions, offline
support, the ability to package your app and deliver it to app stores, and so
much more. Additionally, I often see teams who build their UI application
directly into the server fail to develop a robust API for 3rd party
applications such as mobile apps and data integrations.

------
olakease
Backend developer here. Everytime I need to create some sort of rich UI I
discovered that the last framework I learnt was "no longer valid". Happened
with JQuery, Knockout and now Angular 1.

My feeling is that frontend development is overcomplicated/overbloated.
Specially with the big players (Angular, React). Lucky me, I found my way with
riot.js. Simple, elegant, lightweight and fast enough. You don't need a lot of
complicated boilerplate, nor learning a new template language or syntax.

~~~
cloudjacker
I still make static websites with bootstrap and jquery and host them on Amazon
S3

They look great, they perform well and I make money from that big buy button
connected to stripe.

~~~
kowdermeister
But how can you look in the mirror in the morning and admit that your
node_modules directory is less than 500Mb? Joke aside, if it works, it works.
The simpler the better. JS is in a phase transition state currently that will
get better over time, when we can finally write ES6/7 without compilation and
use modules natively as well.

~~~
cloudjacker
yeah, I put my node.js stripe processing on a heroku server for like $1. Not
concerned about the node_modules size :)

------
natecavanaugh
First, I would say you need to understand your own learning style and what
methods work for you. For me, practical beats theoretical any day. Everything
I've become good at, I almost always had tried learning it from reading books
or tutorials online, would get bored and give up. It wasn't until I needed to
use the tool to get some greater purpose, then I could use the draw of having
that tool solve one of my needs, and had a reason to not get lost in the
details until I needed them. So read up on the general types of problems
they're commonly used for, and get an understanding of what they might be able
to do, and if something sounds like it could help towards solving a problem,
go after it.

Also, people like to shame you when you're learning, as if using "training
wheels" will keep you an intellectual cripple. I love training wheels. They
get me productive enough to keep me interested, and I can always dig in deeper
when I want to/have time, etc. But don't be afraid of just getting the job
done. Then go back, learn from your mistakes, and iterate.

Meanwhile, you're building real experience, familiarity with solving real
problems, and learning the internals of the tools you're using, while the
people arguing over the right editor to use, the right framework, the right
generator, toolkit, bridge, etc, are all still posting on medium about how
some new programming language/paradigm will solve all of our woes.

At the end of the day, whatever helps you understand it better, go for it, no
matter all of the "should"s and "shouldn't"s people will try to burden you
with.

------
matt_wulfeck
> _Everything I try feels messy and strange, leading me to a lot of
> frustration._

It appears you've learned to program but have not yet learned to learn. Like
learning to do anything new, you start with minimum viable product. Let it be
messy, buggy with edge cases, etc, just be completely persistent until it
works and then build from there. Then do it again and you'll do it better and
faster.

You MUST persist.

Don't worry about using anti patterns. I know this is somewhat controversial,
but in the beginning shipping with antipatterns is better than someone who
gave up. Besides, a diligent engineer spends their lifetime _perfecting_ their
craft.

I say this because when I was learning I was completely debilitated by fear of
doing it "wrong" and setting myself up for failure in the future. If you're
actually interested in becoming a better engineer this simply will not be
true.

Lastly I leave you with a quote:

 _Nothing in this world can take the place of persistence. Talent will not:
nothing is more common than unsuccessful men with talent. Genius will not;
unrewarded genius is almost a proverb. Education will not: the world is full
of educated derelicts. Persistence and determination alone are omnipotent._
[Calvin Coolidge]

------
jdavis703
In this day and age I think you should use vanilla JS and not jQuery. But I
don't think you need to use a MVC or "view manager" framework for simple
projects. My personal standard is when I start writing a bunch of code to
track state means I need something to do it for me. But if we're just talking
about some basic AJAX forms that send to a server, these frameworks are
overkill.

------
opvasger
Try the Elm programming language - it should save you the trouble of dealing
with the explosion of JavaScript frameworks. It is designed with learning in
mind, and should provide a really direct path to high quality front-end code.

[http://elm-lang.org/](http://elm-lang.org/)

~~~
zalmoxes
I second this suggestion. I'm a backend developer(barely, mostly a sysadmin
who happens to write Go backends for various reasons). I wanted to learn some
frontend because I wanted to make some internal pages for my users. I tried
React, but found the API surface I needed to learn to be productive
overwhelming.

I tried Elm on a whim, and found it very focused on being productive.
Functional programming was very new to me, but I spent a weekend with
[https://pragmaticstudio.com/courses/elm](https://pragmaticstudio.com/courses/elm)
and it was enough to get me started.

The Elm Guide([http://guide.elm-lang.org/](http://guide.elm-lang.org/)) and
Elm Slack [http://elmlang.herokuapp.com/](http://elmlang.herokuapp.com/) are
both fantastic resources for learning the language.

------
elviejo
Front end development is a total mess. The fact that you have to know: html5 ,
css3 and JavaScript with all the different frameworks is ridiculous....

For me the sane solution is: Elm-lang. It's a total delight, similar to
Haskell but easier plus the elm architecture makes developing web applications
very simple...

I'd say that Elm's biggest feature is architectural integrity...

~~~
dogfishbar
I'm teaching a sophomore level web apps course in the spring semester. I'm
torn between doing what I think will help them land an internship this summer
or land a real job and on the other hand, teaching them something like Elm
which makes much more sense to me. Anybody willing to weigh in on these? It
would be greatly appreciated. 1\. Would a course focussing on just the front
end using HTML + CSS + JS + React be reasonable? 2\. Is it reasonable to deal
only with the front end? 3\. If the answer to 2. is no, then what is most
reasonable and likely to endure technology for the back end?

------
bootload
_" Everything I try feels messy and strange, leading me to a lot of
frustration. It seems very over-engineered."_

Do you remember the google front page in '97? ~
[https://duckduckgo.com/?q=google+1997&iax=1&ia=images](https://duckduckgo.com/?q=google+1997&iax=1&ia=images)
Concentrate on the real problem, design (this is where you should start) a
simple interface. Iterate as @itamarst suggests ~
[https://news.ycombinator.com/item?id=12882850](https://news.ycombinator.com/item?id=12882850)

------
gotiger
I'm on same boat. I have been mobile developer for 3 years and I'm on front-
end web for last couple months.

This helped me a little: [https://medium.freecodecamp.com/a-study-plan-to-
cure-javascr...](https://medium.freecodecamp.com/a-study-plan-to-cure-
javascript-fatigue-8ad3a54f2eb1#.jxluaso95)

And have some laughs: [https://hackernoon.com/how-it-feels-to-learn-
javascript-in-2...](https://hackernoon.com/how-it-feels-to-learn-javascript-
in-2016-d3a717dd577f#.9u3tgc4pj)

------
scaryclam
I'd suggest getting a solid understanding of the core front end technologies:
HTML, CSS and vanilla JavaScript. If you can't build reasonably complex
websites without the crutch of a framework or a more complex tool chain, then
you've probably missed out on getting the basics right.

You should also learn about UX and design. I met a self appointed frontend
developer recently, who didn't have any understanding of what a good designer
does. This led to some really horrible conflicts where core design decisions
got ignored (the developer thought they knew better) and the end result was a
mess. Designers are your friend when working as a frontend developer and will
help to make sure that the end product is both well built and actually useful
for the users.

Read: [https://gdstechnology.blog.gov.uk/2016/09/19/why-we-use-
prog...](https://gdstechnology.blog.gov.uk/2016/09/19/why-we-use-progressive-
enhancement-to-build-gov-uk/)

If you're building frontend your job is to make sure that your audience can
_use it_. There's no reason not to learn and use fun tech, we all like play
and make our own development lives easier, but your users must always come
first.

If you can do all of that then you'll be able to do a pretty good job as a
frontend developer. Picking up the latest and greatest frameworks is really
quite easy once you understand how JS and the DOM works. You'll have the added
advantage of being able to critique new tools as well.

------
acemarke
Got some pointers for you. First, I keep a big list of links to high-quality
tutorials and articles on React and related topics, at [0]. As part of that
list, I have a page called "Basic Overviews" [1], which has articles that try
to help clarify what these various tools are, how they fit together, and what
you would use them for. There's also a couple articles in that section that
give advice for how to tackle learning front-end stuff, and not be
overwhelmed.

As for React specifically, there's an official tool from the React team called
Create-React-App [2]. It hides the details and complexity of project config
from you until you're ready to tackle them yourself, and lets you focus on
just writing the app. Meanwhile, the React docs were just revamped and
improved [3]. There's also a great community called Reactiflux on Discord,
which is a set of chat channels dedicated to talking about React, Javascript,
and React-related tools [4]. It's a great place to hang out, ask questions,
and learn.

Finally, part of what's going on here is that people are trying to write
highly complex and powerful applications in the browser, not just "pages" with
some interactivity. Complex applications mean some meaningful amount of
complexity in the project setup. These tools are basically the web equivalent
of a C++ compiler toolchain and standard library. So, there's several aspects
here: the tools are somewhat big, the libraries are sophisticated to enable
you to manage your application's complexity, and your own app code is going to
be more than just a couple click handlers.

The other thing to remember is that you don't have to use everything all at
once right away. Focus on learning one or two tools and concepts at a time.

Hopefully this helps!

[0] [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

[1] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/basic-concepts.md)

[2] [https://github.com/facebookincubator/create-react-
app](https://github.com/facebookincubator/create-react-app)

[3] [https://facebook.github.io/react/](https://facebook.github.io/react/)

[4] [http://www.reactiflux.com](http://www.reactiflux.com)

~~~
PythonicPro
Wow, thanks for the link list! Will definitely take a look. Also create-react-
app looks like exactly what I was looking for, very bare and to-the-point.

------
throwmenow_0139
Hello PythonicPro,

I'm currently using Vue.js to do some projects and can explain you everything
you need to get started - it's a great framework and doesn't hide too much
Javascript and emphasizes POJO (Plain old Javascript objects). I'm convinced
that no one here can help you without investing more time than searching for
their favourite links. If you don't mind, leave an email address in the
comments.

Read about MVVM (Model-View-ViewModel), because this is the design pattern
used by Vue.js, I assume you already know about MVC if you did backend
programming. If you're unsure about MVC in the frontend try to build something
simple with jQuery using Models, Views and Controllers. I did this in the past
and it's helpful to understand the problems of SPAs that we're trying to
solve. I don't want to repeat everyone's comment, but you should be aware that
the abstract concepts and fundamentals are more important than the frameworks
you are using, I guess you already know that.

I can't guarantee you that I have enough time to explain everything
thoroughly, but I can assure you that I can give some helpful directions.

------
chrisweekly
Read and follow "A Study Plan To Cure JavaScript Fatigue" by Sacha Greif.
[https://medium.freecodecamp.com/a-study-plan-to-cure-
javascr...](https://medium.freecodecamp.com/a-study-plan-to-cure-javascript-
fatigue-8ad3a54f2eb1#.hx4b8n4fz)

FE arch: mountain of coal. Sacha Greif: time + gravity. His post: diamond.

------
dmak
Hey, I've been managing 3 single page applications in the last 3 years. I
could breakdown what you need to get started, and answer questions along the
way. We can hop on Skype or Google Hangouts. If you're interested, contact me
at dmak [attttttt] moneytree.jp

------
jodoherty
I would recommend you start by building out a non-trivial project using the
tools and technologies you know (jQuery), but try to do a single page
application that calls services via RESTful APIs. Bonus points if you can
avoid hash urls using the HTML5 History API.

If you're not familiar with the standard Promise API and ES6, add babel and
the core-js shim. This gives you things like block scoped variables
(let/const), arrow functions, and the new class syntax. Start here. Most new
frameworks and tools expect you to know modern JavaScript.

[https://babeljs.io/docs/usage/cli/](https://babeljs.io/docs/usage/cli/)
[https://babeljs.io/docs/learn-es2015/](https://babeljs.io/docs/learn-es2015/)
[http://exploringjs.com/es6/index.html](http://exploringjs.com/es6/index.html)

Eventually you'll want to start breaking apart your code and organizing it by
responsibility/concern. You'll want to use ES6 modules and a tool like WebPack
to resolve and bundle your modules all up for production. This also means
learning how to configure WebPack to transpile your ES6 code using babel.

[http://webpack.github.io/docs/tutorials/getting-
started/](http://webpack.github.io/docs/tutorials/getting-started/)

Now just focus on building out your project and cleaning it up. Maybe deploy
it so real people are using it and you can get some feedback.

Once it's been out there and people are using it, plan a major new feature
change or addition. This is where you might start feeling the pain points that
are addressed by modern libraries and frameworks. When you do, start
researching things like Vue.js, React, Redux, Angular 2, etc. Pick one and
migrate/refactor your existing code into it before attempting anything new.

If you follow this approach, then your learning will be needs driven and
practical, which keeps it from becoming too academic and uninteresting.

~~~
mbrock
What's wrong with hash URLs?

~~~
jodoherty
The original poster may eventually want to experiment with server side
rendering or splitting their single page app into multiple apps, and hash URLs
pretty much trap you into a single page app with client side routing.

That said, I didn't mean to cast a negative light on them. Using hash URLs
makes it easy to build an app that can be reverse proxied to different
hostnames and paths without content rewriting (to change the base tag's url
for example), and it works well with legacy browsers.

------
KayL
If you don't have strong native JavaScript skills. Improve it first.

And then, let's say you picked Vue.js. Googling MVVM and learn about the basic
concept from your best backend language. (Reading as much as you can. Some
good articles are written in other programming languages also.)

And then, starting to read source code as much as you can. I won't pick big
projects. Just pick any sources you think you're interested and understand it.

After all, you will get the whole picture how the app should look like and why
framework trying to do X & Y.

~~~
KayL
For source code reading. I will read all similar projects. For example,
reading 10 counter apps in Vue.js. And then figure out the similar patterns
and differences.

------
boyter
I'd recommend starting with mithriljs. The idea behind it is very similar to
react for views. It's also vanilla JavaScript so you will probably have an
easier job learning it.

~~~
tobltobs
I also think the OP should have a look at Mithril. When I was in his situation
I also was overwhelmed by the tooling and boilerplate necessary for those
other frameworks. But with Mithril I was able to start developing after
skimming the docs for a few hours.

------
pknerd
>Ask HN: Overwhelmed with learning front-end, how do I >proceed?

Stick with jQuery || Native Javascript. Others are not doing something which
you can't do with your current experience.

~~~
JustSomeNobody
Indeed. Look at the code for the vanilla js todo example where you have a
model, view and controller. start modifying it to add views, an app controller
etc.

JavaScript is actually really fun when someone else's crappy framework isn't
getting all over it.

~~~
pknerd
One can still write clean and manageable Javascript without any lib/framework.

~~~
JustSomeNobody
That's what I was trying to say also. :)

~~~
pknerd
Actually these _frameworks_ introduced the concept of modular Javascript by
introducing marketing jargons like _controllers_ etc. Prior to that most of
the people used JS for validation, pop upunders or...
(BBlinks)[[https://i.kinja-img.com/gawker-media/image/upload/s--
hZcZ5eH...](https://i.kinja-img.com/gawker-media/image/upload/s--
hZcZ5eHJ--/c_fit,fl_progressive,q_80,w_636/185elagm1wgmkgif.gif)]

~~~
JustSomeNobody
But one doesn't need a framework for that. Just good architecture. But sure
frameworks do provide other benefits.

------
zerognowl
Frontend development has come along leaps and bounds since the days of
document.layers and MSIE6 alert() debugging, it seems to be slowly coming out
of a renaissance period lately as many devs have reached a consensus that they
are spoiled for choice and now all that's left to do is, well, _build_.

There is this trend of developers feeling just as you described: overwhelmed.
But rather than feel that, I try to embrace it. Like anything on the web, if
you're not building on strength, then you must be in it for other reasons,
like trying to impress employers, or trying to learn code because apparently
it pays the bills better than other gigs.

I would start small, and treat everything like an experiment. If an experiment
works well, you can build on top of it, and import what you learned from
experiments into full blown (hopefully paid for) development.

I sometimes have to remember to use <em> instead of <b> but only because I
didn't think such things were above me. Indeed it's a miracle a visitor to
your site can even read the content with the temptation that exists to include
another slider widget, or inaccessible web component.

------
eiriklv
(cross-post from
[https://news.ycombinator.com/item?id=12886968](https://news.ycombinator.com/item?id=12886968))

Take a step back and focus on JavaScript the language. Really learn how things
work. Then take a step even further back. Learn more about data structures,
about abstractions and how to think declaratively vs. imperatively. Rinse and
repeat for the rest of the stack.

That way you'll have a solid foundation to build on top of. At some point
you'll start to see patterns, and that all the "new" things are just
incrementally improved materializations of patterns and concepts that have
existed since way before the web was even thought of.

Spend most of your learning/experimenting time on fundamentals (timeless).
Learn actual implementations and specifics when you need to, just in time.
Avoid learning specifics (lib/fw) just in case.

Source: My own personal experience + the very insightful experience of
teaching classes in JavaScript and React the last two years.

------
Aldo_MX
Frameworks like jQuery allow you to do DOM manipulation in a less painful way,
but frameworks like Angular, React or Vue do their best to abstract DOM
manipulation away. This is the reason you may feel overwhelmed by the learning
curve, since a paradigm shift is involved.

I would suggest you to check the basics of Angular 1.5 first, just the
fundamentals to understand the big picture and build a basic application.

The reason is because Angular is an opinionated framework which gives your
project a specific architecture, so you can focus your learning efforts in
appreciating the decisions that were taken for you and how the different
pieces fit together.

Whenever you feel comfortable with the basics of Angular, you can start
checking alternatives like React or Vue, which will feel less strange and
over-engineered at this point.

~~~
gaius
_I would suggest you to check the basics of Angular 1.5 first_

That is a terrible suggestion since that is an orphaned, dead-end framework.
That's the fundamental problem here: the very short shelf life, meaning that
time invested in learning the "latest and greatest" doesn't give good returns.

~~~
Aldo_MX
Neither orphaned, nor dead-end, just declining in popularity, but not a
concern when you still work with jQuery.

The reason I picked Angular 1.5 as the suggestion is that you can still learn
it the old-fashioned way:

    
    
      - Load it from a CDN and start coding, no NPM or Bower required at all
      - No build process or transpilers (ex. Typescript / Babel / JSX)
      - No decisions for dependencies (ex. Gulp vs Webpack / Flux vs Redux / Enzyme vs Mocha / etc.)
    

Rather than overwhelming a developer with the current state of affairs, it
should be better if he can begin focusing in the DOM-less paradigm and basic
concepts like Data Binding.

You may not get to know the new hotness like ES6 and Live Reload when you
begin learning Angular, but it's pretty unlikely that a jQuery developer will
miss them anyway, whatever, it's pretty likely that they will learn about them
when they begin researching about tools like Babel and Webpack.

OTOH, Angular 1.5 backported components from Angular 2, so the transition from
Angular to React will feel more familiar, and you can get away without
learning Angular-specific concepts like custom directives, the mundane details
are abstracted away with components.

Finally, the requirement is to learn the basics, not the entire framework, I
also agree that investing time in Angular 1.5 is not worth it, but it is worth
getting a high level understanding of it, since tools like Vue assume some
familiarity with that high level understanding.

It's not the same learning Vue when you're an Angular developer, than learning
Vue with a blank canvas. At the end of the day Vue is the Angular's Zepto.js

------
z3t4
Its like when ppl try sports, they buy all these tools, clothes, suplements
and cool aid, and the same gear the pro uses. But you dont need any of that to
grow some muscles and stay healthy. All you need is a text editor and you are
good to go.

------
arikr
What is your goal? To build something specific, or get a certain job?

Why is jQuery alone not enough?

------
pmarreck
Go to pure back-end. That's what I did, although I did it during the time when
most sites still required IE6 compatibility, which was arguably more of a
hair-pulling experience than you are dealing with.

------
slmyers
I was in a similar boat and I recommend angular2 using the CLI. The build
process is totally abstracted and the nice thing about angular is that you're
never really going to be wondering what router do I use etc, because the
framework is full featured. Plus it's fairly intuitive. It will be more
complex than a jQuery powered Web page, but I think these SPA frameworks
assume you're trying to make a more complex application, ie if you can build
the same thing using jQuery, then just use jQuery -- unless it's an
educational exercise.

------
shermablanca
Are you in the SF Bay Area by chance? We're putting on a 2-day React & Redux
workshop where you build a full stack e-commerce app. We developed this
workshop after hearing similar feedback from students frustrated with the lack
of tutorials and workshops that teach you how to build a real app with React.
It could help you to wrap your head around how to use React in a production
application. More details at
[https://universe.com/realworldreact](https://universe.com/realworldreact)

------
francasso
If you are just trying to learn UI development: try to develop a somewhat
complex single page app without any framework (a GUI for a database for
example). Don't do it as if you were just changing a document here and there
with jQuery though. Try to approach it like a more typical UI development in
another language (i.e. write your own mini component library that renders to
the DOM, etc..)

By doing this you will see what problems you have to face, and the next time
you see a framework you will catch up much more quickly on the good, the bad
and how it fits.

------
JepZ
Advice? Try riotjs.com (at least read what it is about).

It gives you some basic structure, but is much simpler to understand than most
frameworks/libraries, because you don't need all this router, dispatcher,
whatever stuff, but can add it if you need it.

Experience? I tried some others before:

\- Backbone (okay, but a lot of work)

\- Angular (Angular 2 taught us to use something else)

\- Ember (very opinionated, too much for my taste, hard learning curve)

Riot.js is my favorite since about 2 years and I will stick to it. It's small
size is mobile friendly and in the worst case scenario you can maintain it
yourself.

------
breakingcustom
Posting this question on HN is just going to overwhelm you even more. Don't
listen to the noise, everyone has their opinions that they are entitled to.
Focus on the fundamentals!

------
vbezhenar
I suggest to avoid any templates. Start from empty configurations and add
things that you need. Avoid blind copypasting, read documentation about
anything that you want to add. It might take some time, but you'll have
control over your application. Also you might want to start simple, using
latest ES6 or TypeScript is not necessary, you can start with ES5, and then,
when everything OK, migrate to ES6. Same with CSS/LESS, magnification, source
maps, hot reload, etc.

------
halayli
It takes time (few months) and plenty of iterations to create the mental map
and learn the proper patterns.

I suggest to create a simple app and iterate/refactor until you feel
comfortable that you _got_ it.

Boilerplates are good but they do take away a lot of important concepts that
you should learn.

I'd start with react, redux, redux forms, react router, axios and webpack.

Also keep in mind that you're inadvertently learning ES6 as you dive in. So
I'd start with that first.

------
bastijn
in addition to all the great comments on how to start in this area I wanted to
add that you shouldn't feel bad about yourself for being frustrated and
overwhelmed. The frontend world is a mess at this point in time. There are
many options with as many camps arguing about them. There is a large amount of
framework over vanilla and most frameworks yet have to mature. You probably
will make a wrong choice once or twice (who am I kidding, more than twice) and
curse on the trouble it brought you. Two months in another tool or framework
becomes the flavor of the day and the major headlines tell you to switch. You
have to consider it, but always carefully decide if you need it (because
chances are another one comes along).

My point is, the whole frontend scene is relatively immature. So are it's
tools and frameworks. Angular2 solves major flaws in angular1. Yarn came to
solve issues with npm. Gulp fixed grunt. Webpack fixed both. React... You get
the point. Embrace chance. Hit your head once or twice and take the time to
learn the most valuable lessons from it.

------
samayshamdasani
build mini-projects. I made [https://enlight.ml](https://enlight.ml) \- and
although it's still a work in progress, it teaches small projects related to
web development and ways to actually implement for knowledge of html, css, js,
etc.

Let me know what you think! I plan to evolve it by building a codeacademy
style interface for learning these projects...

~~~
PythonicPro
The tutorials look good, but I already have a base knowledge of JS and
frontend- just looking to begin making SPAs and using React or Vue, which I
can't seem to get a grip on. There's so many loose components in them it's
overwhelming :(

~~~
acemarke
What do you mean by "loose components"?

~~~
PythonicPro
I meant dependencies, for example vue-router, react-router, vuex, redux, etc

~~~
acemarke
Ah, thought you might be referring to actually writing component-based logic
and UIs.

Yeah, React is very much a pick-and-choose-for-your-own-situation kind of a
tool. Somewhat true for Vue also. This is both a strength and a weakness,
somewhat depending on how much you like to be in control of exactly what
pieces you're using.

------
etewiah
My solution to the problem of not knowing which framework to learn was to pick
an open source product that I liked and learn the stack it uses. In my case I
experimented with Discourse for various projects for about a year and as I
result I learnt ember js and use it on almost all my projects now.

------
snarfy
I like this example of learning React without using React.

[https://medium.com/javascript-inside/learn-the-concepts-
part...](https://medium.com/javascript-inside/learn-the-concepts-
part-1-418952d968cb#.4qpfongbn)

------
novaleaf
Typescript + React + Webpack.

Follow the quickstart here:
[https://www.typescriptlang.org/docs/handbook/react-&-webpack...](https://www.typescriptlang.org/docs/handbook/react-&-webpack.html)

------
EvanYou
Did you follow the official guide, step by step? Honestly, I think Vue's
official guide is a better starting resource than ANY of the tutorials out
there, please don't ignore the official docs and reach for "easy" tutorials.

------
dpatterson2008
FWIW you could take a good read of: [https://github.com/verekia/js-stack-from-
scratch/](https://github.com/verekia/js-stack-from-scratch/) it's really good!

------
jamesmcintyre
One tip, Redux is great and is worth learning but if you want to curb the
amount of boilerplate and anxiety-inducing added conceptual overhead look no
further than mobx. And good news, after a quick search I found that someone
has made it one git-command away to implement a simple redux counter on top of
a fresh create-react-app template([https://github.com/mobxjs/create-react-app-
mobx](https://github.com/mobxjs/create-react-app-mobx)). Mobx is able to
drastically reduce boilerplate and cognitive overhead while still allowing the
flexibility to dive deeper and gain just as much granular control as you'd
have with Redux. Also it scales well (although that shouldn't really be a big
concern if you're just trying to learn how to build production react apps
right now).

------
pierre_d528
Learn this: [https://www.amazon.com/Concepts-Techniques-Models-
Computer-P...](https://www.amazon.com/Concepts-Techniques-Models-Computer-
Programming/dp/0262220695)

------
lightblade
Does the question implies front-end development now has a higher barrier to
entry? It has always been told that front end has a low barrier to entry
therefore attracting many people. It appears this is no longer true.

------
tribby
I'm answering this in depth only because I love vue and want you to eventually
succeed at it.

if you are not a total beginner and know javascript very well, start with riot
instead of vue. riot has fewer conceptual abstractions so it's easier to wrap
your head around and doesn't require a complex build system. as a vue user, it
will already make sense to you -- using single file components.

if you are truly a beginner:

don't start with javascript at all. start with HTML and CSS. this is how
you'll learn about progressive enhancement as you begin to introduce
javascript. (in production, you may need to satisfy tor browser i.e. noscript
users, non-Google bots for SEO, richard stallman, etc -- so your site must
function without javascript, or you're ruining the web. this is just my
opinion).

good CSS, if you work on a team, is critical, and almost no one gets it right.
use sass, a grid mixin library like susy, and autoprefixer to start. because
your username is "pythonicpro," I am assuing you're a python user, and would
recommend you apply to your sass the same sort of sanity that python applies
to indentation levels. sass allows you to endlessly nest things. this is bad,
and a common mistake. also, because python is a whitespace-y language, you
might look at pug (formerly jade) for making your HTML simpler.

don't use something like bootstrap, or if you do, only use it for a day to
understand the grid and then move to susy. grids are important. learn about
grids in a book called "grid systems" by josef muller-brockmann. you will be
disappointed by that book. learn to be disappointed by that book because it is
a very good book and one day you will not be disappointed by that book. do not
use flexbox for layouts or things will look weird as they render on slow
connections.

once you get to javascript, you should probably stop using all javascript
frameworks including jquery if you're just getting started. yes this means
you'll have to type "getElementByID" and "requestAnimationFrame." there are
worse things in life (like trying to use frameworks or complicated build tools
when you don't know how and why they work). consider using ES6 (my
recommendation) or typescript (many others' recommendation) for the
javascript, because this is what the frameworks you'll eventually want to
learn use. both es6 and typescript work with vue and react, but angular is
typescript-only. consider strongly using gulp for babel, typescript, es6,
autoprexfixer, sass, etc.

once you are comfortable enough with this stuff, start working on your design
abilities. if you have any autonomy at all in your job, you have no idea how
much easier it will be for your designers if you speak design. (this is why
grid systems are so important). learn about typography, because that's most of
what web design is. be smart about CSS em and rem units. be smart about the
size of your font files: ask your designers, "have you removed all of the
glyphs from the font file that aren't in languages we support?" look up why an
em is called an em. learn about colors that are compliant with disability
standards. learn about whitespace. read kenya hara's "white." be disappointed
by kenya hara's "white." learn to be disappointed by kenya hara's "white."
you're well on your way to pleasing your designers.

------
xcoding
I hope it helps -
[https://www.youtube.com/watch?v=sBzRwzY7G-k](https://www.youtube.com/watch?v=sBzRwzY7G-k)

------
k__
I'd say, start doing some basic HTML, then CSS and then JS courses, if you
don't know the basics yet.

Then, every framework does it's own thing...

I think it's the best if you start with something full fledged.

For example Ember, it has everything you need for front end stuff in one (okay
with ember-data in two) place(s). Throw in a Bootstrap and I think you're set
for 80-90% of the feature wishes you will encounter.

You get routing, data retrieval and rendering of DOM stuff with okay styling
out of the box.

Back in the days (2 years ago) it was enoug to simply include the ember.js,
ember-data.js and bootstrap.css and you could start writing a complete app.

------
dsego
Yeah, who has time to learn? Just slap in some jquery, some ajax calls here
and there. Why use templating when you can concat html strings. And pub/sub,
who needs that? You can easily do an ajax call that sets a hidden field
somewhere, and a setTimeout for some other "decoupled" module that is waiting
for that value. Because front-end is easy if you are writing a big ball of
mud. Good practices are for backend developers, because backend is serious
programming with algorithms and shit. /s

------
dylanhassinger
build something very small. like a simple compound interest calculator, for
instance. push it to github. blog about it.

then build something slightly larger

------
cel1ne
=== Intro ===

1\. Read this: [https://babeljs.io/docs/learn-
es2015/](https://babeljs.io/docs/learn-es2015/)

2\. Use create-react-app or a webpack/babel/react boilerplate to built a
little something. Ignore all the things you don't need in the boilerplate and
don't try to optimise for production right now.

3\. If you're comfortable with this, gradually remove the parts you don't
need.

=== Node, npm and webpack ===

All of the tools are installed and configured using "npm install" which
installs everything listed in a "package.json" in every project. You don't
need to install anything globally except nodeJS to get "npm".

* You install all your runtime-library-dependencies also via npm. Ignore "bower", you don't need it anymore.

* There are a couple of different module-systems to split up javascript code ("requireJS", "commonJS" etc.) Just use the ES2015 "import" syntax. Webpack handles the rest for you.

* There are many tools ("gulp", "brunch", "requireJS") that bundle your javascript-files together into something for the browser. Most people use Webpack now, which is confusing to configure, but does everything you want.

* With Webpack you can just import/require text-files or CSS or images as modules in your code (see "import" above). Webpack will figure out how to serve them (as files, or inline with the HTML or else). It also does everything on-the-fly while you are coding, called "Hot reloading".

## ES 2015, ES6, ES7

* The JS world kinda settled on ES6 syntax / ES2015 now. But JS-syntax is rapidly improving and many people use additional plugins for "babel" (see next point) to enable them to have, for example, class-properties.

* Most people use "babel" for transpilation from ES6 to code that browsers understand, webpack does all of this for you with "babel-loader".

## ESLINT

* "eslint" is generally used to format code and correct warnings. It is also installed by npm and run by a script in "package.json".

## React / Vue

* React brought back the virtues of functional programming to the web. If you use React, I'd recommend using it with the JSX syntax, which is enabled in the boilerplate by default. There is also vue.js, which seems to be better in various points. I don't like it because I prefer JSX, but it doesn't really matter for the beginning.

* Many people don't like react because it's too big. I wouldn't really care about that if you don't build for production now. There are a couple of improvements like tree-shaking (removal of unused code) that are around in the corner as well.

### State / reflux/ redux

* There is a war going on about how to best organise your code and your logic. There is "redux", but also stuff like "mobx". Just try anything you want for the beginning and see how your thoughts involve.

### CSS / SCSS / POSTCSS / SASS

* There is another war going on about how to do styling. There are various helpers like SCSS and SASS that provide improvements over CSS. These processors are usually run by "postcss" which, in turn, is also run by Webpack. There are also various CSS-frameworks and the possibility to just write your CSS inline with the React/Vue code you are producing.

I personally would recommend "tachyons.css", because you won't need any other
framework, nor postCSS, nor SCSS anymore, but it's all your choice.

------
dccoolgai
Get on the list at simplestepscode.com Program specializes in helping you past
the overwhelming parts of it.

------
chrischen
For React true truecar/gluestick.

It separates the boilerplate so you just focus on the application code.

------
bootload
this article really answers your question on how to proceed: _" Advice to
Aimless, Excited Programmers"_ ~
[http://prog21.dadgum.com/80.html](http://prog21.dadgum.com/80.html)

------
psadri
make it work, make it not crash, make it fast, make it pretty.

------
6nf
Wait for wasm

------
simion314
One of the problems that must be solved one a larger project is that you want
to put your code in many small files,like put each class in it's own file
(similar to how you would do it in other languages) , because you do not want
to import each small file you need a tool that will merge them in one big file
and for production maybe also minify it, also you will want source maps to be
generated so you can debug your code. So to solve this problem in larger
projects you need a tool, I am not familiar with all tools that exists to
solve this, the project I am working one uses gulp (I did not made the choice
so I did not done the research why gulp was the best solution then, and now
something else may be better)

Other problem in big projects with jQuery is caused by the fact that data and
UI are combined(what I mean is I often see data set as attributes on UI
elements ,hidden fields with data in it), this can be solved if you use
jQuerry better though, if your UI is not very dynamic I would continue
generating it in server side but if you want something like an infinite
scrolling list, or a very huge list then it is more smouth to implement it on
client side and implement some tricks to have it work efficient(react would
work better in this case then jquery and maybe you can find a good component
that you can use),React is used for UI.

Some people compare angular1 with react, angular is a full framework it
contains a lot more, like translations support, ajax support,routing , If you
want my opinion here it is, angular templates vs react : reactis pure JS , you
can use JSX and you should use it but have a look at the generated .js files,
when I started I did not use jsx so I can learn better what actually happens.
Angular templates feel to me as magic, there are no generated js files, the
templates are compiled at runtime, I am sure eval is used too, in case of
errors if you are lucky you get a printed stacktrace (not a real one)) if
there are other errors you get a generic error message with a link to a
generic solution and if you are not lucky nothing happens, no errors, no
application loading. If you need to do something more complex you will have to
get your hands dirty and have a look under the hood and maybe use the
$compile. Also react can be used in existing jQuery projects, I have worked on
such a project where we migrated some components to react and keep the rest
using jQuery. If you like languages like C#, AS3,Java then I suggest trying
TypeScript , TS works great with React. P.S. I am not a person that tries
tools, frameworks and the latest shiny thing, I am working on web projects
that were already started, so I seen what problems and what solutions we
faced, until some of the solutions get standardized then there will be more
alternatives, you will have to identify the problem in yourproject, then try
to find the simplest solution for it and also try to not bet on the technology
that is at the end of life(it is not easy)

------
kleigenfreude
One option is to eschew front-end and do to work for a large company where
roles are so defined that there are jobs that truly are back-end. Pretty much
anywhere else you go, even if the role is "back-end", there is a chance you'll
have to touch front-end at some point.

I wouldn't suggest that, especially since you started off with JQuery.

If you don't mind probably rewriting everything and don't have models that are
that complicated, you could take a look at Electrode. I've not used it, but
the goal of their project was to hide the complexity of JS front-end:
[http://www.electrode.io/](http://www.electrode.io/)

Angular or Ember are opinionated frameworks that might be good to use if you
can give up JQuery and just embrace something new. The following has an answer
which suggests Meteor also- it's cool, but is a more specialized use case that
might not be appropriate for everyone. Also note that the opinion on Ember
being better than Angular is pretty biased- it really comes down to what makes
sense and is comfortable: [https://www.quora.com/React-Angular-Meteor-Ember-
Vue-etc-In-...](https://www.quora.com/React-Angular-Meteor-Ember-Vue-etc-In-
what-specific-cases-would-you-choose-to-use-one-framework-or-the-other)

However, if it just doesn't matter and you are just doing it to try to stay
current, I'd argue to not jump to a new framework unless it makes things
easier for you and your team.

There are benefits to using what is popular in the development community, more
specifically in the pools of development talent you have available to your
company.

But, in the end, what matters is your productivity. Are you getting more done
now than you used to? If not- you shouldn't be doing it.

