JavaScript frameworks and topics to learn in 2017
medium.com
medium.com
Unless you're already familiar with a tool, I'd suggest starting with the very Hello, world basics.
For Webpack, that's creating an empty project and incrementally adding config, starting with just an entry point (use a simple script importing some modules) and an output filename. Add one loader/plugin at a time. Move into boilerplates once you're familiar with the basic concepts.
(I wish more projects had a Concepts page like Webpack now has: https://webpack.js.org/concepts/)
A boilerplate is another person's code, and while it's good to avoid NIH, unless it's superbly documented, it contains tricks and workarounds that only cloud real understanding.
---
Eric wisely started the article with JavaScript & DOM Fundamentals. For people like me, who were familiar with pre-ES6 JS but weren't actively writing JS lately, the basics themselves have changed a bit.
I attended a General Assembly bootcamp last year (to great success afterward for me), and the pervasiveness of jumping right into a generator / boilerplate really caught me the wrong way.
I felt like going the path you describe, starting with relatively low complexity and building on top of it, was/is the right way.
Even talking to co-workers who have been doing this stuff for years, there's little incentive to jump into a boilerplate, if only there's then two learning curves... one for the boilerplate / its layout, and one for the tooling involved (React or Angular, etc).
> A boilerplate is another person's code, and while it's good to avoid NIH, unless it's superbly documented, it contains tricks and workarounds that only cloud real understanding.
This caused a lot of headaches with other students in my class (and classes afterward).
My idea to "solve" it was to incrementally build out my/our own boilerplate so we'd be able to at least use that confidently, as well as maybe have some understanding into how someone else built their boilerplate. It got shot down due to time constraints, though.
Whenever I'm asked to come in and mentor newer students for their projects, this is something I try to impart, though.
Webpack is, essentially, a compiler. It, or something else, will mature to the point where you don't configure it any more except for maybe a debug flag. At that point learning it's internals will be as useful to a web programmer as learning LLVM's (by which I don't mean "not useful", but probably not worth neglecting whatever the trade-off may be).
[0] I think it was mostly developed by a single guy with a day job, and it has had more impact than any software I have or probably will ever build, so it's not meant to be insulting. Annoyances such as these are the price of a fast-moving field.
[0] Tree shaking completely broken? #2867 https://github.com/webpack/webpack/issues/2867
It suffers from tutorial-like instructions and a lack of formal list-like documentation, which leads to conflicting or confusing configurations (very easy since there are multiple ways to do the same thing, shortcuts found in the CLI but not in the configuration, etc.)
I love Webpack, but the documentation is really rough in some places.
Exactly. I wish I could help with docs for Webpack, but personally I'm willing to trade extensive documentation for a friendly community. These aren't mutually exclusive of course, but I've seen my share of OSS projects with a bad attitude towards beginners and people who are just missing some detail for the whole thing to click.
Likewise, my point re: boilerplates would be moot if most boilerplates had good docs (even if just a detailed README).
To me this is the equivalent of saying "learn molecular chemistry, don't follow recipes" to someone who's trying to learn how to cook. It may be true that the most experienced chefs have a deep understanding of chemistry, but it's much more practical to start from the surface and dig deeper, compared to overwhelming newcomers with "principles" and "philosophies" right off the bat.
A more appropriate analogy would be learning specific recipes vs learning the flavour and texture of individual ingredients, so that you can mix them in new ways and learn how existing recipes work. You might want to start at the former but to be even a 'good' cook, you need to learn the latter. I guess this is more in line with the sentiment the GP is trying to express.
I don't think that's natural at all. You might learn some kind of philosophy, but it's not neccessarily the right one. If frustrated or pressed for time, people might also give up completely and just resort to "copy-paste programming".
That said, the answer is not throwing some documentation full of abstract concepts at a novice and expect that they magically understand them in exactly the same way as the designers. That's just as bad. But I think many designers that tried that and are frustrated that it doesn't work try to fix it by declaring the concepts as "boilerplate" and hiding them from the users completely. That will work exactly until the user actually needs to know about the concept.
I believe you can grasp many abstract concepts a lot better if you actively work with them. So it's crucial to have a good progressive learning curve that makes you "experience" the concepts and not just read about them. (Ideally by first explaining why you need them and what problem they solve)
As a uni student, I had some degree of disdain about being taught from first principles when I really just wanted to build games and apps, but the further I get in my career, the more I appreciate this groundwork. Recipes and frameworks come and go. Theory and first principles are timeless.
Cooking is much less complex, so learning it without much background works rather well.
Just look what your philosophy brought us, a horde of 'developers' who thought JavaScript is jQuery.
Hugely disagree with this. I really like Vue - but in my (very limited) experience, its appeal is that even though it's not as powerful or flexible as React or Angular it's way easier to learn and get moving with. Fewer new concepts, less new tooling, no ecosystem of related stuff to consider, etc.
I'd have suggested learning Vue first, and sticking with it until you outgrow it. If you start with Ng/Rx, and get to where you're comfortable and have a tooling/workflow around them that works for you, then sure you could still learn Vue afterwards but I'm not sure what it gets you.
I don't see how using Node server-side has anything at all to do with user's capability to store data in the cloud.
I understand that as we have moved from web pages to web apps the increase in complexity was inevitable, but I question a lot of the tools being used now. For one thing, once we moved to creating full applications using JS, one of the concerns that tooling moved to address was maintainability. This is why MV* caught on and destroyed JQuery as a viable option for many projects. That being said, Angular pretty quickly swapped one kind of maintainability problem (refactorability) for another (over-abstraction and cyclomatic complexity).
As for the dev tooling (webpack and company), one of the reason I avoid a lot of them is in my experience they can get in the way of maintainability. For example, I recently tried to pick up a 3 month old project in Android Studio and it took me around 3 hours just to get it to compile again because of updates and other tooling complexity. This NEVER happened using Eclipse. The same thing is happening and will happen when the apps being built today get dumped on some poor sod 3-5 years from now.
Lastly, an example from my job. I was recently asked to update the verbiage on a sign in form built ~13 years ago. The devs decided to use some java framework that had buzz at the time named JATO. Jato literally doesn't exist anymore and building it is basically impossible. This is to say nothing of modifying it as all documentation has literally disappeared from the web. The devs picked JATO b/c they thought it would be easier to modify and maintain. Exactly the opposite has happened. They could easily have written the form (literally two input boxes and a submit) using plain JSP. If they had, that code would still be useful today.
Are there any options for this? Are there even keywords I can search for that discuss this?
Sure, this files under "anything is possible", but honestly, I'd like a javascript framework that doesn't actively fight me also having static content. Any of these libraries that put their document derivation logic front and center are ipso facto refusing to compose well with a simple static first page load that renders fast and then gains progressive enhancement from the JS.
It also manages to do this without introducing needless abstractions into your code. Even more magical: it works with any server side language or framework you desire!
The trick is that all rendering gets done server side and the SPA framework is just a dumb little script that replaces old DOM nodes with the newly rendered bits as they get sent down the pipe. You only bring the logic client side as needed, but defer work to the server 99% of the time. So no need to reproduce your rendering logic in 2 places.
Someone on HN has been hyping up his own variation on the technique and calls his framework IntercoolerJS but I haven't felt the need to move away from jQuery-Pjax.
I'm wondering if it can also support merging elements into an existing document:
for example, I have a table of elements, and suppose that I have an 'id' attribute for each row which correctly identifies which elements I would like to replace when new content is fetched. If some elements are replaced, of course I must replace them; but if neighboring rows are unaffected, if the users has a selection in them, their cursor should not move. So, replacing the entire content div is not ideal: the user's cursor will be discarded if it's anywhere in the replaced area.
This seems like something that almost a for-loop around this jquery-pjax stuff would handle, but of course if someone else has written it already, I want to join their project rather than reinvent it!
It's a reimplementation of the library without jquery and with a few extra features.
Instead of working on a single container where all the ajaxing happens, you provide it a list of IDs, and then it extracts the nodes with those IDs from the response and replaces them throughout the document. If I understood you, that's the behaviour you're looking for. It also has a few extra hooks for animating content in and out.
It's not as widely used as the defunkt version though, and I remember needing to stop using it because of a bug where it wasn't scrolling to in-page anchors properly. But hopefully it would work for you.
Personally, I might just use the defunkt version and write a before and after hook to refocus the appropriate input. When it comes to reimplementing browser features in JavaScript, there are lots of edge cases so it's nice to use widely adopted libraries.
jQuery-Pjax is used by GitHub so you know it's well tested :)
These javascript frameworks ultimately produce, at the end of the first page load, a DOM structure with event hooks attached. The DOM structure could be 100% created using html markup from the server, so if the framework provided a way to just hook up the events and then manage the DOM from that point on, you'd get the best of both worlds. It's possible to do this with native javascript jQuery by putting either classes or data attributes in the markup to indicate where the hooks go and then running an init method to find them. Bootstrap components work this way, for example. One of the earlier SPA frameworks, Knockout, worked this way too.
I don't understand, you want a javascript framework to do server-side rendering, but don't want to use node?
Depending on the page, we can go anywhere from old-school full-page-refresh to a complete single-page-app design. Mostly we do Enterprise back-office interfaces and customer web portals, both of which tend to have a lot of data grids. So a very common feature of our applications is a data grid that supports paging-in-place, along with server-side filtering and sorting of large datasets. So we'll do that SPA-like, even if the overall site is more of an old-school design where each link loads a new page.
Our plugin does more than just fetch a url; the client side and server side are designed to work together to allow standard options to be passed up to the server along with the request, standardized error handling and content in the response, and standardized ways of handling the response when it gets back client-side.
https://github.com/angular/universal
It hasn't received much attention from the community apart from the occasional keynote presentation and it is not linked anywhere on the official documentation for Angular 2. However, the description now says "Current Status: Merging Universal into Angular core".
- Ruby - Pakyow framework - I think it uses ring.js and/or vDOM
- Elixir - Texas - might be an experiment, not sure
- Scala - lyft framework
- NodeJS - anything
- anything else - You can use react/vuejs+nodejs as a "templates proxy" and defer your real backend to your language of choice. You get the full whatever of nodejs, plus you can simplify your back-end by only using JSON.
It seems orders of magnitude simpler than something like Angular and I assume it's correspondingly less capable, but depending on your use case it seems like it might be a good fit.
edit: another guy in here suggested something called "jQuery-Pjax" which intercooler is possibly "inspired by" and very similar to, and if that's true then I can recommend jQuery-Pjax as well.
It's no ideal, as the initial DOM render isn't fully populated, but it's much faster than waiting for another round trip to the server to populate the view.
Here's an example sketch using vue.js (data is in #game-data div): https://game-collector-staging.herokuapp.com/
<script> var models = {{=models}}; </script>
And just like that, I have my data accessible as a global variable.
JavaScript as an ecosystem needs mature robust solutions rather than a new way to do things every other week.
It also won't be gone tomorrow. Angular is still the dominant framework by a healthy margin. Yeah, there are newcomers like Vue.js, but they're currently about 1/10th as popular as React.
This "over in 5 minutes" meme in the JS discussions isn't exactly telling the whole story.
Did you even read the article before making this comment? It would appear you didn't since this is just a classic, low effort javascript bashing comment that mentions no evidence from the article.
Every single thing he marks as important to learn is either
1. a mature library that has been around for years and is used in production at hundreds of companies (React is 3 years old and Angular is 6 years old, Lodash is 4 years old, Node is almost a decade old)
or
2. is a fully specced and largely implemented feature of the Javascript language.
How is Ajax gong to be obselete before you finish reading? How is Node, a nearly decade old, battle hardened runtime going to go out of style in 2017? By literally any definition JS builtins, functions, closures, callbacks, Chrome Dev Tools, React, Angular, Tern, ESLint, npm, git, Redux and Promises are all "mature robust solutions". They've all been around for years and are thoroughly tested and used. Many of them are used maturely in other languages as well, for example Futures in C# are basically the same thing as Promises.
The author does mention some newer things like async/await, generators, and ES6, but all these are now official parts of javascript. They simply can't "go obselete", and all of these share ideas with other languages which are also, by any definition, mature and robust.
The author does mention some libraries which are new and less proven, like RXJS, Angular2, MobX, Vue, Yarn, Typescript, and Flow, but did you notice how every single one of these has an asterisk? Which he specifically states means "strictly optional": Cool things to try out that may be useful tools, but not essential. Even most of these are several years old and perfectly mature anyway.
Yes the javascript community moves quickly. Yes JS programmers enjoy trying out flavor of the month frameworks, but it seems I'm one of the only people who sees this as a great thing. People try out lots of new things and learn lots of new strategies, and in the end the ideas of these get incorporated into existing mature frameworks, making them better and more robust.
As someone who is actively trying to get into the JS world coming from the back-end side it is extremely hard to find best practices that do not change every other week. In the beginning of the year, tutorials were made with grunt, yarn, yeoman and the likes, then they were written to use gulp, bower and now it's webpack and what not. I can't even catch up on what the tutorials have used. To be extremely fair, every other week there seems to be a new tool I need to know and I can't even catch up on why I should learn or stop learning/using the previous. Every tutorial/documentation does something differently - there is no unique set of tools and instructions that do not change over time. I cannot find the best practices docs, because everyone has their own opinion of something and bashes the other guy for having an opinion in the first place.
I know it might be a bad analogy - but I usually compare the state of the principles of RESTful APIs to the state of principles of the front-end stack. They are design principles and you have set of instructions/best practices you should follow regardless of the language, framework etc. Thus I can make RESTful APIs in Python, Go, Ruby etc. On the other hand, Javascript is very opinionated framework. I cant seem to find the principles wrapped in a talk, book or docs. Offer me a choice, let me make it, do not make it for me. Let me make a mistake, let me learn how it does not add up to the whole picture.
Every JS documentation assumes something or fast forwards through an important part of the process - the set up. Why the heck do I need to use something, and why is it good with another tool you have in this stack. Why shouldn't I use something? Don't just copy the gulpfile or any other js file I need, explain it.
You said it is a good thing to try a new thing every month - how do you have enough time to observe it and test it properly in production or wherever? I don't see a new framework every month as a good thing, the frameworks don't mature in your environment and neither does my deep understanding of the framework. That makes for constant struggle to optimize a way. People in the JS world, at least to me seem like, hmm, this does not sound cool anymore let's change it up with this.
I hope I don't come of as a hater, I'm just speaking as a front-end newbie.
I don't have a perfect answer for you, but this article is a great place to start. Focus on the fundamentals of the language first, then the tools he provides here will let you build apps. The reason things are this complicated is because JS basically comes with basically no standard library and the need for javascript escalated extremely quickly before tooling could catch up. Now there's been a tooling explosion so it can be hard to find out what's best and how to learn it.
Get started with simple scripts, learn the Javascript basics he talks about, the built-in functions and classes, ES6, etc. Then move on to basic DOM manipulation, then the frameworks like React to let you build more complicated features without worrying about the DOM nodes themselves.
"how do you have enough time to observe it and test it properly in production or wherever?"
I certainly don't have time to use them in production, but with most I just look at the documentation and see what I think of the philosophies they use. Once you know the fundamentals of the language, simply reading their examples usually gives a pretty good idea. Then if I want to try it I'll download example code, mess around with it, and see what does what.
"I don't see a new framework every month as a good thing, the frameworks don't mature in your environment and neither does my deep understanding of the framework"
I'll give an example of why I think this is a good thing. React has been around for about 3 years ago and at this point it's probably the thing most people are going to go for when they are starting a new app. It's mature, robust, well tested, and well proven. It's a rock in the JS world that brings new features occasionally but doesn't break past features and remains strong and consistent. There has also been an explosion of frameworks that use the same philosophy as React, declartive UI that is expressed as a function of state, and resolved using a virtual DOM. These can't really compete with React yet, but they have helped improve React. For example, Inferno, which has almost the exact same API as React, has some great tricks for extremely fast rendering, and the people who work on React have expressed interest in using those ideas.
In the end, yes there's a new framework every month, but the tools that people are really using in production aren't really changing too quickly. Focus on the things that are mature, and there isn't much fatigue to wrry about.
"People in the JS world, at least to me seem like, hmm, this does not sound cool anymore let's change it up with this."
Guilty as charged. Part of the reason for this is that it's so easy since every computer has a browser and trying something can be as simple as adding a script tag. I love trying new things, though in the end in production I've been writing in React with Webpack, Babel, and some of my own self-built libraries for a while now without much changing since not much about that needs to change. I remember trying out Redux when it got big and loved the ideas so much that I wrote a similar state management tool that fits my needs better, and I've added that to my app but haven't changed much in the grand scheme of things to do it. I basically just learned some principals and applied them.
Link to speech: https://russ.garrett.co.uk/2011/01/30/tough-and-competent/
Yes, you can develop highly interactive, reasonably complex web apps with jQuery, but then you would have to develop a lot of abstractions, guidelines and whatnot to keep the thing from exploding. That's pretty much what those SPA libraries and frameworks are.
About server side, IMO there's no inherent advantage on picking node over java other than the fact you'll have one less language in your stack(or not, since you may end up using TypeScript or some other compile-to-js language).
The will to learn vanishes completely.
I suppose that's fine for people who just want to learn something new every day. I want to make stuff, and the less maintenance it needs the better. Most of what's on the hype train isn't too appealing for that.
We tend to compare ourselves with the extreme outliers and even then we overlook their deficiencies and assume they additionally know everything we do. We also tend to conflate all the people we see talking about things we don't know as if they were all the same person.
It's okay not to know things. It's okay to make trade-offs. It helps to have some spatial awareness what else is going on outside your sphere of interest, but pick a handful of things and focus on them instead of trying to learn everything.
There are many other factors involved in brain health.
I would say Ramda.js is most deserving of much wider adoption.
As to how it came to be in that standing, it was and likely still is a very powerful platform.
The client showed me a couple of examples of what they wanted.
One used Angular to make the widget. For a 5 field form that transitions to a "thanks, your order is accepted" div.
Personally, I would consider firing any-one who thought using angular in that scenario is a sensible thing to do.
I say this as someone who is no fan of Angular or of this sort of attitude in general - but, on the other hand, I have many times seen the harm that results from in-house micro-frameworks (which tend to be poorly documented, poorly tested, overly specific, and a disaster waiting to happen when the in-house expert decides to get a job somewhere else).
but of course, "enterprisey" has never really been a good litmus for "correct" or "sane" or "efficient". it's not a coincidence the Java ecosystem became the brunt of so many jokes. i can't help but wonder how seriously it would have been taken if it weren't a Google project.
In response to the mention of Google backing it, I don't see how how that should discredit it in the slightest. Sure you don't see anyone getting fired for choosing Angular. That's because it's supported by a business that runs the business on it. In this case, a company filled with some of the best engineers in the business. It also was and is damn good at certain things. Pretty sensible choice.
the connotations are your own. :) the problems with Angular have been beaten to death and i didn't think i needed to include them to foster a conversation. i'm sure i'm not the only one surprised by the graph in the post [0].
even the article that OP links to- "The State of JavaScript: Front-End Frameworks" [1]- would beg the same question. if we take it's research seriously- more people want to learn React. less than half of surveyed Angular users say they would use it again. there is a discrepancy between that survey and Angular's popularity. i think my question is fair. i think dismissing it requires less thought than asking it.
in any case, i didn't say that Google's involvement discredits it. quite the opposite really. a lot of people will admit it's the only reason they've taken it seriously.
[0] https://cdn-images-1.medium.com/max/800/1*gmYPusm1EjWu713tmV...
[1] https://medium.com/@sachagreif/the-state-of-javascript-front...
It fulfills a need, and works.
Just because you have a preference for something else doesn't make it any less effective.
Not everyone is building a cheap hackathon twitter clone in their spare time.
For some of us the JS framework is solving business problems, not hobby JS side projects using the latest hip JS frameworks.
This sounds...circular. "AngularJS is a framework for building large SPA framework systems solves the real world business problem that business need to build SPA framework systems."
Frameworks don't solve business problems, practically by definition; they're potentially the common factor across software systems that solves part of the technical problems of developing an application.
That's assuming a framework is any good, of course, but we're talking about Angular, so by all means: tell us what development problems Angular solves for you.
And if I were defending Angular, I don't know that I'd invoke the problems of fashionability and the bleeding-edge of change, because it's hardly insulated.
Mind you, there are people using Angular outside the enterprise (e.g. via Ionic), but it's definitely one of its main strengths.
For anyone wondering: detractors criticise Angular for relying on a lot of idiomatic concepts (compared to other frameworks that largely build on concepts that apply to JS in general) and creating a lot of abstractions to the point where Angular can be considered its own language (as is certainly the case with its template language despite people saying it's "just HTML"). All of these things are the way they are for good reasons, it just makes Angular entirely unappealing to a subset of the JS community. Luckily there are plenty other frameworks to choose from.
I'd much rather stay on the well beaten path with a mature, less sexy, less efficient solution than hack my way through the jungle with something more contemporary and powerful but less mature and less well understood.