I come from a pure HTML + CSS + JS (mostly via jQuery) background. My career has headed in a direction that focusses a lot less in the frontend web, but every 2 months or so I read one of these guides and I get giddy - "Finally, I will teach myself angular/vue/react/backbone/knockout". After about 10 minutes I am filled with dread. I expect to learn about a specific piece of software, instead, I am greeted with requirements of previous knowledge on a whole bouquet of other technologies: node, webpack, babel, grunt...
It's just discouraging. This whole thing feels like a farce. I watch colleagues investing time in this and I feel sorry for them.
I learnt a lot from the article Modern JavaScript Explained For Dinosaurs[0] (featured on HN recently), which explains the history of developments from vanilla JS to 2017, "a historical context of how JavaScript tools have evolved to what they are today". I thought it was brilliant at making sense of the jungle you describe.
Thank you for this, this is fantastic. Exactly what I was looking for (not a dinosaur, just a back-end dev who's curious about a lot of front-end tech).
The official React tutorial starts you out by installing create-react-app. I know that vue has something similar and I wouldn't be surprised if others did as well (are there even other important front-end frameworks besides React/Angular/Vue at the moment?)
This allow you to start off with a great setup and skip the configuration so you can get started with just writing React. I highly suggest starting with official docs before writing these off. A lot of other tutorials are of varying quality but you can trust the official docs for sure until you learn more about the community and which resources are worth it (or just use this https://github.com/markerikson/react-redux-links). It can be overwhelming if you aren't actively following the front-end world but the reality is that you need very little node knowledge and can go a very long way without ever touching webpack + babel. Even then, once you get to the point, learning to configure those things won't take much time and to me, it's worth it for the developer experience.
If you really want to dabble in just writing React code, you can also try these browser IDEs if they float your boat.
I could have written this myself. I did a lot of web development before JavaScript exploded and have since done mostly back end work. Every time I hype myself up to learn any of this stuff I feel like I'm chasing my tail.
"Wait, I can't learn this until I understand that, but that requires some knowledge of that other thing which is best understood in the context of..." It's exhausting. I have written code professionally in a dozen languages or more on projects ranging in size and scope, but I have never felt so lost as when trying to learn the labryinth that is the JavaScript ecosystem.
I come from backend programming experience with a little bit of jQuery and Bootstrap experience.
I run into similar experience when trying to learn new JavaScript frameworks. Documentation for these frameworks is usually written as if you already are expert in another JavaScript framework. And then it is really hard to understand benefits of tooling they have. I could do simple apps or tutorials but trying to use any of these technologies in a real project is such a hassle that I end up using good ole jQuery. Sometimes, i feel like these frameworks and their extra tools have no real purpose but to help one pad their resume.
Only reason I keep diving into these frameworks is because I worry that if i don’t learn new technologies, I ll be outdated soon.
From what I see, we are moving away from a heavy server which does the heavy lifting to thin server layers that just send data and feature rich UIs that process the data. This is possibly because the browser has become a widespread means of distributing general software.
As a result, the domain of "backend" engineering has bled into the frontend and thus frontend engineering has gotten more complex.
If you purely want to learn React in a way that allows you to do some light modification of an existing architecture then something like create-react-app or some browser codepens will be the best way to get involved with the library.
Otherwise, if you want to understand React from a more fundamental sense, going away and doing some backend courses or learning some basic CS and/or FP architecture may serve you well in understanding the paradigms that inform React's design. As a bonus, these skills will never be useless.
As for JS tooling, it's not ideal and is definitely a lot to learn all at once. Your best bet is to abstract over as much as possible and learn only what you need to when you have to. Though, again, the skill of picking up and using new tools is a valuable one in this line of work.
Yeah, In my day to day work I do a little bit more than the OP and know some react/webpack and such.
But the last time I needed something a little complicated I ended up using VueJS. If you don't want to do it the "right" way (ie, a whole build system and such) you can just toss the file onto the page with a script tag and get to work with your scripting wherever you feel good about doing that.
> If you don't want to do it the "right" way (ie, a whole build system and such) you can just toss the file onto the page with a script tag and get to work with your scripting wherever you feel good about doing that.
The "wrong" way, in this case, is not only the "right" way, but the only way. Any javascript framework, no matter how esoteric or abstract, has to wind up generating one or more javascript files to be called by script tags in an HTML document.
And any framework that recognizes this and just tells me up front where a prebuilt script is that I can just include and use is a plus in my book.
While it seems kind of pedantic, I take your point.
And I agree with your assertion that it's nice to be able to shove a pre-built script somewhere... but I've been working on toy react/redux apps and I feel like no, that would miss the point of the tooling and workflow that I want to learn.
Same. Recently I had to do some web work and it is so daunting. Any tutorial for a given technology asks you to use a bunch of other tooling dependency that you don't understand. It's just mixed up dependencies everywhere even for little example projects.
Something like create-react-app that is supposed to help you learn react. Set it up and just look at node_modules. Just a shit ton of dependencies and you have no idea what any of them do. All this sort of scaffolding set up that you're supposed to ignore.
> Set it up and just look at node_modules. Just a shit ton of dependencies and you have no idea what any of them do. All this sort of scaffolding set up that you're supposed to ignore.
Yeah, good luck going through legal/license compliance audit in any serious company doing software.
Security is more of my concern: these things change constantly and versions can even be completely replaced, so even if you convinced someone to do a full security audit (and they checked all the dependencies of the dependency, etc. etc.) I still don't think I'd feel entirely secure.
Is it even possible? I once checked perhaps at the depth 5-6 and it reached maybe thousands of items. At some point though there were many repeated dependencies, sometimes on different versions of the same module.
Funny, I've worked with multiple companies and their lawyers who were very serious about license compliance and what not. It took all of fifteen minutes to prepare a spreadsheet of our licenses (planned, anyway). Not a complaint from any of them, other than an "oh, that's more than I'm used to seeing."
The one sticking point was webpack 1; they had some dependencies with unlicensed dependencies. Fortunately, we were already leaning towards browserify anyway at the time. Webpack 2+ resolved those issues.
The idea that you should consider "what to do if your company grows to be a competitor to Google" in your technology decisions is quite frankly some of the worst bikeshedding I've ever seen. That question shouldn't even enter in to the process at the start.
If that happens, and it probably won't, but if it does you will have a team capable of dealing with the issue by then.
Considering that both Google and Facebook are heavily invested in this scene with Angular and React, there's not much to imagine. They're both fine with lots of licenses.
I'm coming from a similar background and mindset but over the past few months I've been doing a lot of prototyping and some production using Vue without the build tools. I just include vue.js and use x/template scripts for the templates. It's definitley saved me hundreds of hours already.
I can't comment for the parent, but I've done that, and yeah, I just toss the vueJS file, any additional files for components/polyfills, and my script file into the page via a tag and it works as expected.
I've dabbled but I don't use es6 much. I assume you assumed that because how the build tools allow you use es6 and compile to a lesser es. A good chunk of what I write is used by devs so I don't necessarily avoid es6 due to browser compatibility, I just haven't found there to be a ton of useful features in es6. Variable scope has never been an area of concern for me; I've always used snippets, which covers most syntactic sugar; and I definitely don't want to start using OOP in JS.
I'd recommend trying out create-react-app if you want to learn React without having to worry about all the build tooling craziness. Eventually you'll have to start fighting with those if you build some real life stuff, but create-react-app is great for just getting up and running so you can learn the actual library (the fun stuff) first.
It discourages us full time FEs too. Webpack and a full transpile pipeline is still relatively new to JavaScript but it seems like we’re starting to land on some assumptions (and thus making this a more turnkey process)
ES6
Route based lazy loading
Some sort of typing (TypeScript or FlowType)
CSSModules
React with JSX
Redux
The reason it’s been so difficult is because we’ve had a sort of Wild West mentality where we want to throw everything at the wall and see what sticks. Hence the extreme configurability of Webpack. But this seems to be the preferred configuration. I speculate we’ll see a more turnkey build pipeline in the next year rise.
My shop does not use any front-end build system because of the trouble of setting it up and we don't like cli to create a template for us too because it takes time to study how to change such a template to suit our need. If parcel gets mature support of vue, we may use it and skip webpack for the next project
Im learning all this stuff now after 30 in person and phone interviews and no offers. Ive been a Design coder (bootstrap, html5, css3, jQuery) since 2010 and never had an issue finding work before.
It's ok though because you got to keep up with the benjamins or become a useless dinosaur in this field.
My biggest struggle is knowing why a certain thing is done. I don't want to simply build on a layer of magic, I want to know why I am using a particular framework or library. But without much experience having done it prior, it is hard to evaluate why the current trends exist at all.
I came from the same background, and got hired onto a team that uses a modern stack, and it really wasn't that painful to pick up. A few weeks of working day-to-day in such a codebase, and you'll get it. You might not like it, you might prefer the old school ways of coding, but feeling sorry for devs who move to such platforms isn't necessary. We're doing fine.
Considering there is easily (in US) 60-80K+/year difference between doing HTML + CSS + JS (mostly via jQuery) and say React. Spending 1 month to learn webpack + React looks like fairly sound investment of time.
There are no longer any HTML, CSS, JS jobs posting without the fact of needing to know one or multiple JS frameworks.
If you are currently working and using no frameworks in your current job you better learn them before looking for your next gig. Because if you don't you are no longer relevant .. .speaking from current job hunting experience and 30 interviews yet no offers.
One interesting question might be why the reverse isn't true: if companies could spend 60k less per head (or even 30k less per head) by hiring developers who demonstrate facility with HTML+CSS+JS+jQuery and then training them over a few weeks in webpack+React (while getting them up to speed with the particulars of their codebase, which is inevitably going to be a thing anyway), why wouldn't they do that?
Two reasons: recruiting departments head recruiting and they use keyword filtering tools to limit their nets.
The second reason is that nobody (as far as I can tell) seems to be hiring to train anymore. They just want full capacity from everyone and there’s a lot of myth out there about how an unskilled contributor can be a huge detriment.
Seeing you get downvoted, I don't get it. Why would professionals not want to spend a week to learn something which you can build knowledge on for the next few decades, especially when it has monetary value?
There's an aggressive/paradoxical luddism in tech that I'll never understand, considering that it is the tech industry. How many great tools/frameworks have come out over the past decade and how limited would you be if you ignored it all?
Few survived a decade though... I doubt that changed with the current generation.
Not saying it's not with the effort to learn. Just had to smile about your time reference
Forget about Babel / Webpack. Pick one of the simple ones that can be used without a build process: choo, Hyperapp, Preact. Read the source. The change in paradigm is the main takeaway.
That's how I feel configuring networking and load balancers and other backend stuff. I know its essential but for some reason front end and all its quirks makes more sense to me
It depends on the developer. Myself I like to get in touch with where my code is deployed. So I like to do that stuff myself but most of the time there
Is somebody dedicated to that.
The number of projects is simply a sign of how popular the language / platform is (is becoming).
When you start to understand / recognize the different "types" of projects you'll see they all (generally speaking) fall into probably less than 10 total categories of projects.
Your goal is not to understand all of them well, but to understand them well enough to know which ones fit their use cases the best. When I think of these things in this way I can generally dismiss ~90% of the projects after I've read a handful of pages of their documentation to know whether they're on the right track or not.
Then, for the ones I've dismissed, if I start seeing those projects pop up more and more on forums like HN I might reassess, but other than that once you get over the steep edge of the learning curve it's no longer intimidating to see so many projects popping up in the ecosystem.
EDIT: Or just get your skills to a point where you're confident enough that you understand the fundamentals well enough that you can fit into any project no matter what front-end libraries / frameworks they're using.
Lots of replies here, so not sure if you will read this. If you do, I hope it will help you in your career going forward.
"Pure JS" and "Mostly via jQuery" are actually at odds with each other in your description. jQuery itself is a huge library/framework and requires at least as much specific knowledge as any of the frameworks you list. The main difference for you is that you already know it, and so it seems simple/obvious/unencumbered/whatever. Understand that when people describe their framework of choice they are coming from exactly the same place you are. Their preferred setup seems simple, obvious, reasonable and everything else is bloated, complicated, and foreign in comparison.
Especially when you are at the start of your career, or if you have had a career made up of pretty much the same thing, it's easy to see the world outside your sphere as confusing, complex and unnecessary. The computing world changes quickly, though. People complain about the JS world, but it's not really as crazy as most people make out. In my career, I've been paid to work with no less than 15 programming languages (and probably more that I'm forgetting). Each of these programming languages come with multiple ridiculous frameworks. How many X Windows widget libraries have I used? Windows? Old Mac? OS X? Java has it's own! Web frontend frameworks? Then how many DB frameworks? How many communication frameworks? How many IPC libraries? Seriously, I'm just getting started.
Programming is programming and if you don't want to be constantly learning new things, then this job is not for you. I don't for a second think that's the case ;-) Every one of us gets "new framework fatigue". This isn't Pokemon. You don't have to learn them all. However, you should keep learning new things that interest you because each one of these things has valuable ideas in it. Each one uses a technique that you can use later in your career -- even if you aren't using that framework/library. Similarly each one of these frameworks and libraries has huge drawbacks. Really understanding those drawbacks makes you a much better programmer.
I've got a lot of friends that are still DB2 programmers. Others that are MFC programmers. There's a good chance that if you are under a certain age that you don't even know what I'm talking about. They have to hang on to their jobs with a death grip because they will never get another one. Move on. Learn new things -- you don't want to be like my friends.
P.S. I have used almost everything you've listed -- except jQuery. :-D
This is for React Native (which lets you make mobile apps), not for web, technically, but you can try learning React with https://snack.expo.io/ which is 'batteries included' and lets you write the code in the browser, no setup required at all, just a mobile app (Expo) on your phone that can load the code you're writing to display your app. No webpack, babel, grunt... involved!
Same happened to me when starting with iOS programming. It requires some time but it’s totally worth it. after all this is why i love coding... challenges :)
I wish people to complain less and enjoy more the road to master a technology.
> instead, I am greeted with requirements of previous knowledge on a whole bouquet of other technologies: node, webpack, babel, grunt...
Have you looked at the standard Vue tutorial? It uses nothing but pasting code into a blank HTML page, a jsfiddle, or the tutorial page's JS console. It's extremely well-suited to someone who isn't already familiar with node/bundlers/etc. And it gives a surprisingly thorough introduction to Vue.
I recently started to build an electron application using the electron-vue boilerplate. Dear god, there is a ton of garbage in that boiler plate! Not to mention boilerplate is such a code smell.
With so much base stuff baked into that base, it makes it difficult to add new components and really understand what's going on.
Still I'm glad my first step into Vue is through an electron app so I'm not dealing with figuring out browser comparability. Still it makes me sad we don't have very many cross-platform desktop app tools, that we have to use electron and package a 100MB web browser and VM as part of our app.
Slack, Discord, etc are all at least 90MB. That's kinda messed up.
It's ok, the people who have picked a weekend to learn it feel sorry for those stuck in 2005 web design, too!
Sometimes I think web devs specifically and devs in general forget just how much you have to know to get started even with something "easy" like Django. You gotta know HTML (it gets new features, too), CSS, SQL, Python, Javascript, and the tools necessary to each of them. You gotta learn all that while a framework abstracts it from you. And that's not even considering the choice before that. Why not Rails or something else? Frontend dev is pretty simple in comparison, you're just familiar with one and not the other.
Node is an interpreter that runs JS on the backend. If you understand what Python or Ruby do, then you understand it. You of course can use it on the backend, but the main reason frontend devs use it is to compile the most recent versions of JS down to stuff that works on browsers. You're free not to do that, but JS has evolved for the better over the last decade. Babel is the main tool people use to do this, and webpack uses something like Babel to "pack" your app/components for the frontend. In a lot of cases, if you are using webpack, you don't need grunt. But both of them are build systems, which all language ecosystems use.
Most of it is optional but quasi-necessary and fits a defined role and need. But don't miss the forest for the trees, don't let choice anxiety get to you. What you want to learn is the underlying model, which is a huge step up from what people were dong 10 years ago. If you don't want to get complicated, there are a few "no choice" options.
1) Use React or another view library without any fancy schmancy tools.
2) Use a small, full-stack framework like hyperapp or Elm. This is the entirety of the model you want to understand, and both are small and easy to learn (we're talking a day if not an hour).
3) Use a bigger, everything included framework like Vue. There's no guarantee it won't be passe like Ember or Angular in five years, but there's an existing community and documented way of doings things.
Pick one of them, any of them, but don't get in that dread of choice. The great thing is once you've learned any of them, the concepts are wide enough that you can pick up another framework really fast. As in I can look at any of these and understand what they are doing the same way you can look at a web MVC framework from 2005 and know the hows and whys of what they are doing in an hour.
The great thing about the churn is it's like Christmas every day. You don't have to pick up any of the new stuff coming out, but I'd rather have options and evolution rather than not. The alternative is stagnation.
It's really fun and empowering. I encourage you and others not to get discouraged. Oh, and don't feel sorry for your coworkers. They're learning new stuff. What's better?
I'm not a web dev (I'm backend/HW communications). But I dabble. For me, it's not that I don't understand all of this (it's all relatively simple). I just don't want to do so much just to get something on the screen.
I've used webpack for well over a year now, and while there is a lot to learn in webpack if you really wanted to write your own config or just learn for learning's sake, you really don't need to learn it to dabble. The thing that makes comments like these absurd is that you really need to learn almost nothing about webpack, grunt, gulp, broccoli, rollup, etc. Just to dabble. Almost all of the boilerplates and starter kits do this for you.
But that shows some kind of misunderstanding, because you can literally build single page applications in 50 lines of code and a JS include in an html file.
None of this stuff is that much work. People are really overestimating how hard it is, and you realize it once you try it. It's just people aren't familiar.
No, no misunderstanding. I was being snarky and referring mostly to the laundry list of items that most FE devs have running or install just to start building a FE. To me that seems ridiculous and shows me that FE devs have either not paid attention to the bloatedness that is Enterprise style development or have and walked away with all the bad habits.
Thats a little presumptuous. We're doing the best we can to build complex applications, on top of a platform that still has no proper module system, no UI toolkit except a wonky document model on top of which bloatedness was built, sandboxed to hell, with the crappiest "stylesheet language", on top of a wasteful protocol that wasn't able to do more than one request per connection, with 1s (if you are lucky) time to load, compile and run fresh code on the fly, in multiple different VMs, some of them years old with half of the features missing.
We have paid attention. We're doing the best we can.
Until we get HTTP/2 everywhere, ES6 modules and we fix the tire fire that is global CSS... this is what we have to do to make it work.
The official React tutorial is excellent and I learned the basics of React from that and was up and programming in a day. It took me a couple of weeks to understand the library in more depth, but there just isn't a whole lot to React. For Angular I agree it takes far longer.
You cannot learn React in one day. No matter how clever you are. You can learn enough to start coding but, until you understand Redux, how to use selectors with Reselect, middlewares, async-actions and the component lifecycle, you will be writing awful code.
Some people, when they pick a new technology, they choose to spend an afternoon reading half tutorial and then start coding straight away. By the time they finally "get it" and start to write decent code, they already put 5000 lines of spaghetti in production that some other developer will have to cope with in the future.
Even Dan the creator of Redux says you don't always need Redux and I got along fine without it for a basic app. I was writing clean React code within a day. The component lifecycle took maybe two days to understand? It's so simple I wrote a popular answer about lifecycle on Stackoverflow within a couple weeks of learning it. Want to write a big app with complex state? Sure, you'll want to add Redux to the mix. But it's not a hard requirement and is overkill for small simple apps. You can learn React itself very quickly.
Too late to edit my other response where I meant to point out that in React, Javascript is the templating language, which is one less thing to learn when compared with Angular and others if you already know JavaScript well.
> In order to be able to tell if you need Redux or not for a project, you need to know Redux
Not according to the creator of Redux. His advice is "Instead learn to think in React. Come back to Redux if you find a real need for it, or if you want to try something new. But approach it with caution, just like you do with any highly opinionated tool."
> too many developers overestimate their intelligence and write awful code because they didn't take the time to learn well the tools
No argument there. You do have to go through the entire official tutorial, and I would also recommend the article "Thinking in React", that Dan Abramov referenced above. https://reactjs.org/docs/thinking-in-react.html
I'm not claiming your experience with awful code isn't real, I'm sure it is. But is it because React is difficult to learn? When I learned React I was already good at JavaScript. And I had already learned Angular. Angular took me over a month to start to feel comfortable, and I still felt like I was stumbling around in the dark. The Angular API is very big. With React I was writing code, and code that I still use, within days. And I felt comfortable that I mostly knew what I was doing. When my code got a little more complex, I took a few hours to read about and learn about Higher Order Components. And when I needed routing I taught myself React Router in one day, and began answering questions about it on StackOverflow shortly after. Did I take the time in each case to completely understand the API and is that different from what other devs are doing? Possibly. But the point is that the React API did not take me weeks to learn. It's a simple API and there just isn't much there to learn. The React lifecycle for example has less than a dozen methods. It's super simple. Maybe other devs do struggle with getting such a simple API internalized, or maybe they just didn't go through the entire tutorial carefully enough. With React Router I am constantly answering questions that have answers right in the documentation. So maybe what you are seeing is lazy programmers, not a difficult API. In any case, in the interest of not going around in circles here with a difference of opinion, my most important point was comparing the simplicity of learning a UI library (React) vs. a very complex framework like Angular. React was WAY more simple to learn in comparison. And it should be. It does far less. Fair?
This is an opinion, so don't take it as fact, but JS frameworks are a mistake. It's better to take the Unix philosophy and build things up from single components that do their one job well, and focus on standards. So an example would be to use Web Components rather than React. React is amazing but it has a limited lifespan (though that lifespan could be long), whereas Web Components, while not as feature rich, are a web standard. The gaps between React and Web Components can be filled in by various libraries, such as Lit HTML. For state management you could just use plain javascript or dip into a particular library like Redux or MobX if your needs get complex.
In any case, once something no longer fits your needs, you can change it out with something else, which is difficult if you use something like Angular or React or Vue.
I don't know... not all web standards worked well in the past: xhtml, appcache, etc. I wouldn't be surprised if web components never got success. Why should anyone use this standard when a library is 10 times better? Being the standard is not enough.
(HTML) DOM is performant, snappy, and cross browser compatible as never before. One of the reasons why jQuery is becoming irrelevant is that DOM finally works.
The rumours of Ember's demise are greatly exaggerated.
I have yet to hear of people making the same amount in any other framework. Seniors are making $200k to $500k in remote positions (the people I know live in Toronto, but they could be anywhere).
It is hard to learn, and I'm far from an expert, but the highest I've heard another JS developer who knew both Angular and React completely and he was responsible for migrating a company from one to the other and he was just starting to get into that range.
Large SPA JS applications are easier to structure in Ember because there are so many best practices. The problem with Ember is the learning curve because it doesn't usually let you take shortcuts.
I'd point out that often rare and often unused skills get higher pay due to simple supply and demand. I've heard similar salary ranges for Assembly programmers for example.
Angular and React are widely used, and there are many people out there that know them. No need to pay a ton.
> The problem with Ember is the learning curve because it doesn't usually let you take shortcuts.
I'm guessing that's precisely one of the main why it's not used widely. Why train an entire dev team on it only to have half leave in a year and have to be constantly retraining on a language with a large learning curve?
It’s not a language, it’s a framework. You can take any experienced JS developer and make them proficient in either Ember or any framework mentioned in the article within days.
People overexaggerate how difficult each framework is. They’re all front end frameworks made to do one job. Yes, each of them have their own nuances, but nothing that cannot be understood spending few days coding, reading docs and speaking with someone experienced in this particular framework.
I'd argue frameworks are their own language built on top of another, but this is all semantics.
As far as learning curves, I'm taking the GP's word on Ember's difficulty to learn, but generally as mentioned below, I don't think you can truly learn a framework that quickly.
Convention, best practices, etc take time. For example, someone that learns AngularJS in a day could end up using $scope, a practice abandoned for many reasons for alternate methods. So does standardizing devs and dev teams on the same practices. A lot of these things often take mistakes to truly understand, or someone who has seen a lot of them within close proximity. The way people write code for each of these programs evolved though those exact mistakes. A framework can constrain, but there are still plenty of ways to mess up at a high level.
Completely untrue. I was at Bocoup and we wanted to standardize on Ember. It took weeks to get devs doing the basics in a large app. Ember isn't gone because its misunderstood. Its gone because we can build the same apps using more suitable libs/frameworks, in a fraction of the time, with less code, less magic, and less upgrade burden. Ember sucked at upgrades, even though they tried to make it better.
Not to be a jerk, but can you provide any links to large sites or apps that use Ember? Again,this is a serious question, as I like to keep tabs on trends for JS stuff like this.
This is about how long people stay at the same job, not the framework stability. In my experience people hop from job to job often enough that you'd be regularly training people on a language unless they already knew it when hired. So a language that people already know or has a low learning curve is usually preferred for many companies.
The Framework wars are overblown, and they've become profitable to perpetuate for clicks and views. I know plenty of people using Ember today and loving it. Same with Angular. React is popular but it's hardly the only game in town.
Actually, learning Ember.js is quite simple, because of Ember CLI, which was the pioneer and inspired Angular CLI and Create React App. Try this tutorial and you will be an employable Ember expert in a few days: http://www.yoember.com
I know it's just a joke, but maybe there should be a section about not using frameworks at all? I'm also curious about the weight of these frameworks. Once you minify and treeshake everything, what's the minimum you can get down to in order to deliver an app?
Also, do any of these frameworks have a way to degrade for people without Javascript enabled? From what I understand, the only way to do this seems to involve some server-side rendering (and it looks like JS is still required).
I'm also really curious how heavy React/Vue/etc are compared to the original gmail implementation back in 2004 (only of the oldest major javascript/ajax applications that minimized page refreshes).
Wow, Dojo is still alive and kicking! I'm going to have to find some time to take it for a spin. I really like the idea of framework that looks to address a few needs, making framework selection easier and less reliant on "Oh Framework X is popular now? Let's use that and hire a bunch of devs for it..."
While Dojo is there, I'm surprised ExtJS is not. I haven't worked with it directly for quite a few years but I know it is still being supported. I seem to recall some backlash around licensing issues so maybe that's caused a dip in market/mindshare?
I liked Elm when I played with it, especially the similarities with Haskell. Unfortunately they had moved away from some of the Haskell like syntax shortly after I started with it, and I didn't feel like I fully understood how to use JSON properly.
Kind of surprised to not see Meteor on there. Haven't used it for awhile, and iirc there were concerns around security, deployment, MongoDB lock in (which I thought they were moving away from?) at the time. For smaller, personal use projects I felt I got moving quicker and easier with Meteor than anything else.
I'd love to see something like this for libraries and tooling. Really feels like a lot of worthy choices, and therefore a lot of high-level knowledge needed to understand which to choose and when.
Purely from an outsider perspective, it's interesting to see all the different frameworks out there, but for front end devs I can't help but feel that this type of comprehensive list hinders more than it helps. One key thing JS needs less of is fragmentation. If I were in the front end dev community I'd want to see people making the front runners more mature and flexible, not endlessly fragmenting just because they slightly disagree with what a more established framework does.
Looking through a number of the entries in this list you read that it was "inspired by React". Why not just make React more flexible so that your alternative way of handling code fits within it? Does each of these new approaches really require a whole new framework?
Contrast this with something like the .NET Framework (which is something I'm more familiar with). Whilst the CLR has the potential to run frameworks other than the .NET Framework, you don't see the same churn in frameworks that you see with JS. I'd suggest this is due to a mixture of two things:
1. A greater focus on getting things done over code elegance.
2. The more mature a framework becomes, the more work is required to match its feature set.
On this second point, if JS continues its constant framework churn, it'll be stuck with immature frameworks. I'd suggest that JS devs should be doing what they can to get past this stage, and if that means (for a few years) treating new frameworks as interesting experiments rather than the next big thing, then that may be a cost worth paying.
I actually think fragmentation is ideal, it demonstrates the failures in a system more cleanly. For example, I started with Protoype.js many years ago, after a bunch of research at the time. But then later switched to jQuery, because it was simply better in every way.
There simply was no fixing the problems with Prototype.js, they were inherent in the system.
I think when a fragmentation occurs in every framework, its for the same reason. Consider Angular 1 to Angular 2, they broke backwards compatibility because they had too. Angular 2 could have been called something else, and it would be viewed as "fragmentation" not an "upgrade", but in effect, it was fragmentation.
This is the exact reason why I think all of these frameworks will ultimatly end up in the dustbin of history. Does any major programming language in the last 30 years use a framework that requires multiple build systems, multiple "dialects" of differing syntax just to do what is inherently available already? (but just faster and easier?)
This sounds like the end result is Webassembly, not the "perfect framework".
The end result may be development without a 3rd party frameworks, perhaps in a way that allows you to mix and match libraries without needing to use a large underlying framework. However, as things stand now there is clearly a need for JS frameworks. They are plugging gaps in vanilla JS.
My argument isn't that frameworks do not have any utility (right now), my argument is, if you stick to a smaller selection of frameworks and work on both polish and flexibility, you'll have frameworks that make people want to develop in JS. At the very least it'll mean that the basics would be easy, and design decisions could be deferred until later in the site design.
I know people love to shit on JS for being blisteringly fast, but does it really apply here?
All 3 of "the big 3" are over 4 years old, making all of them older than windows 10...
And of the notable category:
Aurelia: around 2014
Elm: around 2013
Inferno: around 2015
Polymer: 2014
Preact: 2016
ReasonML: 2016
Svelte: late 2016
So most a few years old. Yes, it's faster than older technology stacks, because the web is still evolving quite quickly, but it's not as blisteringly fast as many make it out to be.
Yea I'd say the big churn appears to be around tooling and paradigm thinking (state management, functional programming, etc.), the latter of which driven in part by the rapid expansion of the language itself.
I would actually like to know if there's a list of systems, apps, sites, whatever, that are using any particular framework. Using data from Stackoverflow or NPM downloads just isn't the same as real-world examples of actual use.
How did ReasonML (a dialect of a language), or Elm (a language) end up in the list of JavaScript frameworks? Whereas ClojureScript (a language) or Purescript (a language) didn't make it, but libraries/frameworks built on Purescript did.
I'm still using Jquery and some of the millions js libraries available only when you do not bind yourself to a SPA framework taking control of the DOM. And it work pretty well I must say!
My opinion is that for 80% of the websites out there, a SPA framework is not only overkill, but is also a bad choice. Your website is probably not Gmail or Facebook. Server side rendering is perfectly fine.
We should start a competition where any framework/no-framework could be used to develop a project and judge the winners using metrics such as : time it took to develop it, compatibility, accessibility, fun to interact with.
Web 1.0 (html and hyperlinks) is still valid and working perfectly. Web 2.0 (AJAX and DHTML) is still valid and working perfectly. Web 3.0 ([MVC][MVC][MVC][MVC]) is basically a fully client side application. It takes a professional to identify which solution will be the most optimal given the requirements.
...and yeah - most likely you don't need React+Rxjs+Redux for a wizard-like prev/next multi-select online-quiz, but it's me looking for a job so you're right. Hell - let's throw in async/await as well. You'll need a space shuttle to debug this thing.
Nope, I think regular people are completely able to judge.
Which do you prefer, Youtube from a couple years ago, where every page was a page? Or now, where every page is 15 weird loads of something with blank blocks and comments taking a minute or more to display?
Regular users' opinions should matter more than a developers, as they are the ones who use it.
I am trying to transition from Ember to React, but calling Ember "historically significant" is odd given adoption by big name companies (including Apple and LinkedIn) and very active development (3.0 should be out in a few weeks).
You are totally right... Ember is adopted and actively used by more and more places, people loves it and very easy to work with. Ember evolve a lot all the time, definitely one of the best choice nowadays.
I like that the only con for Vue is there's no jobs for it. Having done two major projects in React and Vue, Vue is my preference. While vue is supposedly faster, speed has never been an issue for either. I think the biggest thing for me is it's just easy. While I like React, I think vue is nicer and often more concise, and if you really want jsx, it also supports that.
I also use Bulma for the visual side which works nicely with vue.
i mean its also because the author is obviously biased toward vue. see the other comments here for why people actively pick react over vue. dont confuse the printed word for fact.
If you have any amount of dynamic data with a non-trivial representation, and you don't want to have to go through awful ad-hoc things of "when I update this data structure, tell the stuff on the screen to change" and "when this on-screen value changes, update these parts of the data structure", you eventually end up with an MVC framework: this is not a new idea and JS didn't invent it.
And once you have that, adding a bit of structure to make it nice to build up modular components results in something pretty close to Vue or React.
It's not specifically the DOM modification but the way those frameworks are designed. With React you have hundreds of dependencies, which have hundreds of dependencies. You lost me right there.
I've looked into Vue.js, and they seem to indicate that it's easier to get up an running than react (using what you describe here). Are you suggesting vue.js and react work exactly the same?
I don't know because I don't use Vue. What you'd be missing if you dropped in the react library and did no compilation at all is the ability to use JSX. I'm guessing vue's argument is their attribute tags still work in their minimal deployment whereas with React you'd be manually wiring up things to the React object functions.
Choo is pretty underrated IMO. Very small and fast, vanilla js, real DOM node diff, simple state management and routes built in. Also a very supportive community, esp Yosh.
No no no, you think wrong - like an unhirable dinosaur. Sometimes I just chuckle when I see yet another SEO growth-hacking startup doing full client-side rendering in React/Angular.
Whats the right choice for building a repacement for an existing app that has survived for 15 years and you want the replacement to last at least another 10? Whats the long term hedge?
I completely agree re: sponsoring company - although react seems to be orders of magnitude more popular, so someone is going to have to be supporting these apps that people are creating now you'd expect, right?
Similar to the way Postgres has deep roots that trace back to Ingres[1] in the days before SQL was a solidly established standard, Ember traces it roots back to SproutCore[2] in the JS framework pre-historic era of 2010.
And the same way PostgreSQL was seen as a second-tier or only "historically significant" open source database, the PostgreSQL team just kept at it, toiling away year after year, steading churning out awesome code and excellent documentation, getting better and better with each release. Like clockwork.
In the same way PostgreSQL is now, finally, enjoying more popularity and getting the recognition (long overdue in my opinion) for the awesome platform that it is, I expect that in time more developers will come around to appreciating Ember. The Ember leadership is definitely approaching the project and the processes around it like they intend to be not just relevant but pushing the boundaries for a long time to come.
For one example this boundary pushing, you should not miss @tomdale's talk at ReactConf about GlimmerJS (the view layer extracted from EmberJS). It is, in my humble opinion, simultaneously mind-blowing and and inspiring.[3]
Starting from fresh, I would honestly recommend PureScript or Elm (and eventually Haskell/GHCJS when that moves to WASM).
The benefit you get from the amazing type systems and compilers these have, is worth so much when it comes to refactoring, and later on boarding new people, giving them the confidence to make changes thanks to the help of the compilers.
If you want type-checking, going with React + Flow/Typescript is a wiser decision than choosing Elm. Better support, better ecosystem, much bigger community by a huge difference.
Flow/TypeScript is not really near the level of the other type systems, so I wouldn't really say that—it is a nice first step though, one that you can do on an already established code base.
What are the "clear best practices" for Angular? I'm just starting in Angular 5 and I'm starting down the ngrx path. From what I can tell there's many different ways to structure the project and ngrx is in version hell - the current docs on master reflect an unreleased version.
Honest Question. What is breakdown of market share angular versions market share? does anyone have these stats? I know not a lot of new projects are being done in angular 1 but I am under the impression that majority of jobs are still for angular 1.
Since when does a small library or even a single function count as a framework? Shouldn't a framework provide some sort of structure and I just plug in my app-specific code?
Today I was playing around with a webpage, and realized it was the first time I had directly touched the dom in like a year and a half. It was so simple and joyful. I miss it.
I'd like to see pro and cons for all the lower 'smaller' frameworks and methods. Maybe we can contribute? I have used many of them. Seems like the ones with pros and cons, React, Vue, Angular etc everyone already knows. I think there is opportunity here to give more depth to lesser known frameworks. The top 5 are pretty well discussed at this point.
What do you think is the long term prospects of frontend development?
I have come to terms with continuous learning in frontend but I can't help but feel that I am standing on unstable ground. That one day, all the knowledge that I have accumulated would become irrelevant.
I have come to the point that I am learning backend using Python just to have a fallback.
Not really sure I get the constant Vue v React debate. They both do basically the same thing and each support almost all the concepts the other does. Both are great, neither is significantly better (after about a year full time with both in various projects).
That link was recommended to me as a simple, clear explanation of React. I'm a real minimalist - just plain vanilla Javascript serves my purposes - but I'm glad I read parts of that explanation, as I got familiarity with the term "render" and could see that React is the go-to framework for mobile.
Yes, it's a lot. But imagine the opposite. Imagine nothing new came out, and everything just stagnated. Evolution, experimentation, testing things out, this is a good thing.
Combining Mithril ( https://mithril.js.org/ ) with Tachyons ( http://tachyons.io/) or a similar CSS approach is also a great option to avoid having to write that much CSS. That way almost all your code can be in one language and easy to refactor -- especially if you use TypeScript.
Honestly I don't think Vue is better than React, or React better than Vue.
They are just different, and that's where a lot of the arguments come from.
For me, Vue is such a monumentally large step backwards. I loved React because there are no templates, there is no 2-way binding, you don't have the vuex style state handling. Using Vue is an exercise in frustration for me, dealing with all of the templating headaches that I was so happy to escape, needing to learn the "template pseudo language" which ties your hands in a way that I haven't found helpful. But this makes Vue no more wrong or worse than someone using tabs instead of spaces is "wrong" or "worse".
But for others, React is a nightmare because of those reasons. A friend of mine greatly dislikes the React paradigm, and was always more productive and wrote better code in a templating style. And I genuinely don't think it has anything to do with productivity or skill. Vue's style might be better at some things, worse at others, React is the same, but in different ways. They are both fantastic frameworks.
There is a huge deficit of intermediate-advanced Vue tutorials compared to React. There are like 30 advanced-level tutorials on Egghead on React and like, what 3-4 advanced Vue tutorials (Nuxt, Nuxt and using Angular-like decorators to write proper classes instead of the 'it just works' vanilla boilerplate)?
Learning the ropes of Vue is easy. It's a go-to framework of the Laravel crowd for this very reason - you don't need to know Javascript much if at all, just learn some basic syntax and you're good to go for some basic virtual DOM magic.
ekhem.. check this tutorial: https://www.udemy.com/vuejs-2-the-complete-guide/ <- that's the only tutorial You'll need to master vue that's not its official documentation. You know why there's not many more advanced tutorials for Vue? Because that one COVERS IT ALL - once You finish it You're basically Vue.js dev that will solve any problem related to it.
Unless I'm mistaken, it only really works well within a component. You don't get prop type checking in the component hierarchy.
Also, Vuex is very string-based, so you don't get payload or return type checking when you use Vuex. There are additional libraries that look to help this, but it's still an issue.
I could be wrong about any of this, but those are currently the issues I'm running in to.
The points you've listed are the very reasons why i would prefer React actually ...
- JSX fixed all the templating issues from 10 years ago, i see no reason to go back to dependency injection, scope loss, arbitrary code-in-html expression and a semi-javascript accent
- Presentational view logic belongs to the controller while business logic is elegantly abstracted in React: view=fn(state). There's no point in ripping view creation from the presentational layer.
- Context and higher order components. Can't have those in an imperative architecture.
- v-for is not sane to me. Also odd, being forced to mix-in extensions for the simplest basics that go beyond the few presets Vue provieds: https://github.com/Krizzu/vue-for-range A React user doesn't solve problems by searching the internet for framework specific solutions, they import _ from 'lodash' and use _.range, like everyone else does.
- {condition && <div>hello javascript</div>}
- We have suffered through two-way data bindings with Angular already
- Vuex is not native. It mutates state by aggressively transforming state into setter/getters, with nasty edge-cases. Once Vue switches to version 3 using proxies, you'll maintain two incompatible codebases. React has Mobx, even though Redux is great. Also lots of lean and promising alternatives like Unistore.
- Knowing React you don't rely on documentation (though official docs are on point). It is simple enough to grasp it after looking at a view examples once. The api surface and cognitive overhead of React is a tiny fraction of Vues. Coming from Angular it is amazing that one month of learning and half a year of consulting docs turned into a week and a couple of months consulting with Vue. Yet, you can learn React fully in the shortest amount of time while simply remembering the few things you'd need to know. A generic round-trip, for instance the one at egghead, costs you 60 minutes total.
These are exactly the same reasons that I think React is the best. Vue looks like it's going backwards compared to React.
Furthermore, you get native mobile apps for free with React Native.
Also, React has a much, much bigger community and bigger companies supporting it.
Finally being able to transfer knowledge and code, and due to the generic nature of React in some cases even everyday eco-system packages can be applied. For instance: https://github.com/gaearon/react-blessed-hot-motion (native console app using plain react-motion to move stuff around).
JSX is NOT just HTML and JavaScript! If it was just html I could write <label for=""> and not <label htmlFor="">, I could write <div class=""> instead of <div className="">. It's not even just javascript, or I would be able to write a simple if-else statement. JSX is a DSL, a minimal one, but still. I mean, you could say it's even worse, because those subtle differences can cost you hours of looking for mistakes.
> If it was just html I could write <label for=""> and not <label htmlFor="">, I could write <div class=""> instead of <div className="">
In case you don't know (and I also didn't until recently), those namings come from the HTML DOM Javascript API, and not from React. So having that naming in React+JSX is more a consequence of operating on that abstraction level, than a quirky decision of the React developers.
> If it was just html I could write <label for=""> and not <label htmlFor="">, I could write <div class=""> instead of <div className="">
for and class are reserved statements, hence htmlFor and className are the official api names, in other words they belong to the actual web-api spec, there's nothing arbitrary about it:
Some react-like libs do allow it, but the dom api takes offcial precedence, so it's all fine. It's just that HTML in general was made without taking all the things into account we demand of it today. It wasn't even made for imperative inflating, so the dom-api faced the same troubles.
It is Javascript, but JSX brackets only allow an expression within them. Conditionals are statements in JS, so you have to wrap them in an IIFE or a `do`-expression.
I suggest anyone thinking of using two-way binding for anything to rethink their choice.
v-model isn't two-way binding in the AngularJS sense; it's just a shortcut for binding a "value" property and updating it on "change" events. See https://vuejs.org/v2/guide/forms.html.
OP is slightly incorrect about two way data binding. Vue doesn't have two way databinding in the same way that AngularJS does.
Vue's "two way databinding", i.e. v-model directive, is actually just a syntax sugar that's equivalent to adding an event handler and a dynamic property on the value/text of the element.
v-model is meant for use specifically with <input> tags, so your local component state stays synced with what the user sees. You can use it on components, but you're not meant to. In general, vue encourages you to avoid using two way data binding on custom components unless your component is a souped up input component, like a fancy date picker or something.
You don't need to know jsx for using jsx. You only need to know html. You do need to learn something more with vue, you said so yourself, those v-for, v-if directives.
> each component is html.file, javascript.file, css.file
I prefer to only have one file per component so that I can just "import Component" and use it. With 3 files I need to make sure all 3 of them get loaded. Disclaimer: I do not know how Vue works.
The one thing that Vue does great is exactly what you say you like about React (edit: not to say there aren't other things Vue does great, just that this is one of them). In Vue you have one file that contains the styles, code, and HTML for the component, all in their own HTML tags.
That means that there is a "blessed" solution for styling, that I'm afraid React will never have. Between "styled components", CSS-Modules, css-in-js, and tons of other options, many in-operable with each other. Styling is React's worse part, and it doesn't look like it's getting any better...
styled-components are actually really nice, so I don't think it's fair to say "styling is React's worst part". This seems like a more general criticism of React's agnosticism when it comes to so many things. React falls more heavily on the library spectrum than the framework one. It's rather un-opinionated about a lot of things: styling, state management, routing, code organization, etc. Definitely not something that's unique to styling.
On the one hand this offers a lot of flexibility to do things the way you want, but also makes the learning curve a lot steeper. Honestly I would love for somebody to build a more full fledged framework around React that makes most of the decisions for you. A sort of "good for 90% of use cases" setup. (I guess create-react-app is sort of like that? You still have to make too many decisions, I think.)
I completely agree, but at the same time styling still sucks in React when it comes to using 3rd party components. Not to mention that with each way of doing it there are big tradeoffs (styled-components pushes a bunch of what I feel could be compiled before release to the client at runtime).
Most of the other parts of React are great with the freedom of choice. I can use a 3rd party component that handles it's state internally, or expects to be controlled externally, or uses or doesn't use JSX, or organizes it's code however it wants. But if I want to style it (which i'll need to do), I need them to support the method I'm using in my app, or have this very ugly and hard to support "bridge" between what I'm using and what they are using.
I'm not trying to be all doom-and-gloom, but it is a pain point for me, and it's not getting better in my experience, it's getting worse. It's not nearly bad enough to get me to switch away from React, but it's something I would like a nicer solution to.
"Some of Vue’s syntax will look very similar to AngularJS (e.g. v-if vs ng-if). This is because there were a lot of things that AngularJS got right and these were an inspiration for Vue very early in its development"
No, I think it would be fairer to say that it's like if AngularJS and React had a child and named it "Vue.js".
Because in the end, Vue.js has stuff in common with React, like the virtual DOM (you don't see this in Angular 2+) and has stuff in common with AngularJS (the good parts).
As someone who had to use AngularJS for a while, just wait until those template directives get replaced in future versions to support random-use-case-17483 and force you to refactor a bunch of template code for literally no tangible gain. Then you’ll understand why using native JS to generate elements makes more sense.
One non-trivial thing my team has experienced using Angular over the past year; the decision to abandon version numbers makes searching for answers or documentation a nightmare. Ironically the company that should understand search the best hobbled the ability for developers to search for answers.
TypeScript is nice. Actually writing code in angular is a fine experience. It’s all the stuff around that which isn’t great. We recently upgraded our app from Angular 4 to 5 without much fuss and that was nice. But the team should really go back to using version numbers. They exist for good reason.
I gave up on Polymer. I can't really explain it well but nothing worked as you expected it to. v2 was just hacked v1 (hybrid?) and so trying to actually figure out how to use v2 was impossible since every major custom element was hybrid. The documentation was bad, and the things you might want to use were somewhat depreciated, but you had to figure that out on your own. Then the standard glacial pace of development means that v3 was announced over half a year ago and as far as I can see, nothing has happened.
It's lacking the best - Imba. The rest are just funny toys. Sad it's lacking documentation. Hope it will change soon because it kills with performance and developer experience.
Some people read documentation, some tests (lol) to know what's going on. I read code - and Imba has really nice code to read. Also they are responsive on Gitter. But as I said. It's a pity.
It has a syntax dedicated to DOM operations. Doesn't change principles from React perspective - it's component based. So what I do for example: I can copy and paste react code, quickly parse it to Imba notation, and the result is 58 of original 198 lines of code. It's clear and nice to read. And outperforms React tens times. How could I not love it? :)
Author of CxJS here, which is also missing from the list. Please consider CxJS if you're looking for an enterprise-grade framework with ready to use form elements, form validation, advanced grid (data-table) control, navigational elements, tooltips, overlays, charts, routing, context-sensitive layouts, theming, drag & drop, culture dependent formatting and more.
It's just discouraging. This whole thing feels like a farce. I watch colleagues investing time in this and I feel sorry for them.