Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Overwhelmed with learning front-end, how do I proceed?
255 points by PythonicPro on Nov 6, 2016 | hide | past | favorite | 132 comments
Hey, I am currently learning front-end (knew jQuery but after many recommendations and doing backend for a long time decided to "modernize") with Vue.js components, etc... but feeling very overwhelmed with the big change, and after trying tutorials I don'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.

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't use. The file trees seem massive in comparison to simpler projects made in jQuery, which don't help the stress much...

Overall, I am very overwhelmed with what I am seeing in the front-end world, how do I proceed? I don't know how to continue this. Any tips? Experiences?




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

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

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

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


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.


Wow, after reading the docs and several examples of intercoolerjs, if you ask me to describe it with one word, it'll be "simple", two words, "no over-abstraction", three words, "easy to pickup".

I develop desktop software for Windows, but I'm also interested in the web development techs - although haven't done any real-life web apps, I have read a lot of docs about most of popular frameworks you can list here. The first framework that got me think "cool, it's natural and simple" is Angularjs 1, maybe because it's so similar to the good old Delphi's GUI framework called VCL (Visual Component Library - yes! Component!), but you all know the story - it's "killed" by angular 2 and the version 2 feels so complex and so over-engineering to me :P

Now intercooler.js gives me a feeling similar to the one when I first landed the angular 1 homepage - it's not the same of course, but I think both of them made me think "natural" and "simple".

Maybe you think, well, you are not a web dev, but trust me, I've writing software for a living for over a decades, I know the pain of a framework when being over-abstraction, over-engineering, or being bloated. KISS, is a rule that fits in all fields, I guess.


I'd never heard of intercoolerjs before, and was going to comment how introducing another framework to the discussion was counterproductive, but then wow I checked it out.

It's exactly the improvement on jQuery the OP asked for, and thus fits that mental model perfectly. It is also so logically designed it basically requires no documentation - I read the introduction and a handful of examples and thought, "shit of course it works this wasy" and could basically derive how every other feature mapped to its implementation in that moment.

Congratulations!


Ok, just spent my Sunday playing with intercooler.js library and I am so pleased right now. I have plugged that right into my flask app and got it working like butter with flask-paginate and flask-table and Ajaxified nearly all-the-things in an afternoon. I've been dreading taking this on as I could have easily lost months trying to get this-much-shit-done screwing around trying to become javascript/react/vue guru. Awesome work man, great stuff.


> Intercooler is a sturdy, quiet alternative in a web development world of noise and complexity. I'm happy with that.

love this and thanks for sharing. your intro/docs page is very well written in that it progresses very well from simple examples to more intricate examples. very well done!


Not sure if I'll ever use it, but intercooler.js would be great for many use cases (that usually end up being implemented using a hugely complicated stack).

The only reason I probably wouldn't use it is that I'm happy with just using browser APIs directly for the small stuff.

I'll just say that the examples make intercooler.js seem much more complicated than it is, until you read closely enough to realize that most of the code is Mockjax and backend implementation. You'd do well to split the view into two parts: frontend source code and server-side source code.


I work with an application that wasn't built with "new" javascript standards, so migrating everything over to the component, reactive, built standard will take us some time. In the interim, we started using Intercooler, and it's awesome. If I were starting a project fresh I don't know that I'd go this route because I like the deep customizability of a well-designed JS app, but for simplicity, Intercooler does an awesome job.


This is really clean and simple and looks like it can grow with needs. I don't think I would have come across it in the framework noise if you hadn't tied it to the issue here and spoke to it.


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.


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


Please stop the fanboyism. OP did not say there was anything wrong with Vue, but asked if there was any specific reason it was chosen, and suggested they try something that comes with good preconfigured defaults to avoid being overwhelmed by all the choices. Which you completely fail to address in your canned sales pitch.


What are you on about? I cited two specific reasons: the excellent documentation and easy syntax which made the learning process go very smoothly. You seem to be doing exactly what you accused me of doing. Are you suggesting that React and Angular both have "good preconfigured defaults" and Vue does not?

Being overwhelmed by all the choices is a valid concern which is why I find it strange for you to be suggesting OP switches to another framework when he has already started with Vue.


Vue comes with good preconfigured defaults, see vue-cli;

https://github.com/vuejs/vue-cli

Incidentally, vue-cli predates create-react-app.


Recently I have created few tutorials on Vue.js. I comes from Angular JS 1 and 2 background. After few days of Vue.js, it seems very simple to begin with you.

If you are planning to build a side project, or dashboard kind of stuff so you can definitely give it a try. I feel it's like jquery :) little bit more concept to grasp.

Few video tutorials I am creating, you can watch and leave your comments:-

https://www.youtube.com/watch?v=Bv3_eTttgso

https://www.youtube.com/watch?v=WSXN-p7jVIk

https://www.youtube.com/watch?v=VKLUGU7YCFc

https://www.youtube.com/watch?v=FAa7Er_zQcg

https://www.youtube.com/watch?v=k5L2uikYkoc


Great, that's actually useful information.

But you could have safely skipped the "first!" comment. Being first does not make you any more superior in the front-end world than it does in a youtube comment.


I couldn't help it, I'm sorry ;-). Although there is a point that Evan You has put a lot of effort into finessing the "developer experience" of using Vue. That includes vue-cli, "blessed" packages surrounding the main library (e.g. Vuex), being able to start using a script tag include if that's easiest, and clear documentation.

My "getting started" experience with React (which I use every day) was much more rocky. Admittedly this predates create-react-app.


first comment was useful


What about Ember CLI? Predates both of them.


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')
);


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

*Updated with simpler code and JSfiddle example


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>;
      }
    });


Useful to know. Cheers.


PS: This can be cleaned up even more with ES6/ES2015 syntax.

See https://babeljs.io/blog/2015/06/07/react-on-es6-plus


Thank you for that link! I am starting in react and there is a blend of ES6 and ES5 in the tutorials (maybe even within the official react tutorials?). This hits the spot in clearing up some confusion for me.


Just a question. Why would you create a new button component when the only thing it does is return a <button> html element with text inside. Why not just do {listitems.map(listitem) => {return (<button> {listitem.text}</button)}}. I think react facilitates unnecessary boiler plate logic like that. When in reality a component should probably do more in order to save code if it's going to be created at all. Just my opinion. Open to other people's thoughts on this.


I remember when I could show a button with nothing but an html element. Things sure have improved since then!


For React, one step by step complete tutorial for beginners is the https://www.reactjs.co

:-) just sayin;-)


I didn't mean to imply anything was wrong with Vue, I also was trying to keep it somewhat framework agnostic using react as an example (react is just what I'm most comfortable with currently, so it was easy to type up). The Vue question was more out of curiosity, and the fact that more popular frameworks are going to have more "help" available in most cases (learning is one area where it kind of is a popularity contest)

My comment probably should have been 2 separate comments.


"Don't add anything on top aside from what is needed for the bare minimum of your project you are learning with"

I believe not following this advice is the reason why so many (of us) are having difficulties in getting started. It very tempting to try to go for the "best-possible-stack" which includes too many neat libraries for solving some specific problems. This leads to endless troubleshooting which kills all the fun.


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.


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


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


The people building these front end frameworks aren't building products to last 5-6 months much less 5-6 years.


Agreed! I know it can be so so overwhelming, but just hang in there. We have had these problems with the web from the very early days of JavaScript, but we have only reached an inflection point in the past 5-ish years where we have solved these problems. So these new and successful JavaScript abstractions/frameworks/layers/patterns are here to stay.

And yes, things like React, Redux, Flux, Backbone (if people still use that) etc etc etc are based in some solid grounding CS and technology architecture principles. Let the burden of engineering load not get mixed up with your ability to embrace and understand application of the fundamentals that underlie here.

I complained about something similar about a year ago, and the Facebook guys told me they felt the pain, but said that the investment would pay off, and it already has in the shortest amount of time. Just. hang. in. there.


This is a very good point. All the JS frameworks I know of solve a real problem. Still most of them are just horrible unless you know exactly how to use them properly. Then again, UI programming tends to be ugly in any case (at least when you're stupid and do all the wrong things).

WRT jQuery, I'd even go further and say there's nothing wrong with jQuery perse [0]. It's just very hard to write modular, easy-to-read, reusable code with it. If you're smart enough and can come up with a good architecture, or if you need just a dozen of lines of JS, jQuery (or a lightweight reproduction of the API, eg. Zepto) might be the best choice.

So yeah, work on fundamental programming skills; learn to design good software architecture; and stay critical. You can work with most technologies, and you can mess up with all of them.

[0] I'm a Finn btw


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.


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


It would have been nice of you to point to a scope or topic, not just say "Get simpler".

You're right, but in your backend example, one might say - Go learn ONE SQL technology, such as Postgres, to understand relational backend, which is a big thing. Then, if you'd like, go learn ONE document based backend, such as MongoDB, which is popular.

Or, recommend a book on the subject, such as "Seven Databases in Seven Weeks".

But that's backend. I don't know where to start with frontend.


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


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.


It's the "script" curse. Some of the worst code I've seen has been in build and deployment scripts, cause "it's not realm code".


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/), but same concept applies elsewhere: everything is variations on a theme, basic functional requirements forcing particular forms.


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


I had a lot of problems with front-end stuff as well. Turns out I didn't know Javascript well enough. Solved it by going through this course: http://watchandcode.com/p/practical-javascript


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.


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.


Nicolas Bevacqua's JavaScript Application Design: A Build First Approach isn't a bad place to start -- Manning has a few books on SPA design and development that are well-suited for experienced developers who are new to modern web front-end dev.


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


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


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.


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!


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


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


Of the list of UI libraries and frameworks you listed, only Polymer creates Web Components. All the others have their own component model.

There are Web Components libraries besides Polymer: Skate JS, Reactive Web Components, Bosonic, X-Tags, and probably others. They're all interoperable.


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.


Frontend developer here. Everytime I need to create some sort of rich API I discovered that the last framework I learnt was "no longer valid". Happened with CakePHP, Webforms and now ASP.Net 2.

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


+1 for riotjs.com


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.


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.


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


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.


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


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.


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/


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 and it was enough to get me started.

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


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


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?


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


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

And have some laughs: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...


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

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.


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

[1] https://github.com/markerikson/react-redux-links/blob/master...

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

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

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


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.


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.


Read and follow "A Study Plan To Cure JavaScript Fatigue" by Sacha Greif. https://medium.freecodecamp.com/a-study-plan-to-cure-javascr...

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


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


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/learn-es2015/ 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/

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.


What's wrong with hash URLs?


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.


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.


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.


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.


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.


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


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.


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


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


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


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


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.


(cross-post from 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.


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.


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.


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


I don't know that I'd call it "ophaned and dead-end" when AFAIK it still is being used a lot more than any angular 2 stuff. I'm kind of skeptical about the jump to ng2.


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.


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

Why is jQuery alone not enough?


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.


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.


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


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.


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.


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!


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.


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.


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.


build mini-projects. I made 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...


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


What do you mean by "loose components"?


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


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.


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.


I like this example of learning React without using React.

https://medium.com/javascript-inside/learn-the-concepts-part...


Typescript + React + Webpack.

Follow the quickstart here: https://www.typescriptlang.org/docs/handbook/react-&-webpack...


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.


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


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


Learn this: https://www.amazon.com/Concepts-Techniques-Models-Computer-P...


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.


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.


I hope it helps - https://www.youtube.com/watch?v=sBzRwzY7G-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.


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


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

then build something slightly larger


=== Intro ===

1. Read this: 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.


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


For React true truecar/gluestick.

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


this article really answers your question on how to proceed: "Advice to Aimless, Excited Programmers" ~ http://prog21.dadgum.com/80.html


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


Wait for wasm


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)


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/

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

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: