> Webpack: The most popular bundler for standard JavaScript look for simple starter kit/boilerplate config examples to get things running fast
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.
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.
> 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 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.
Learn programming, not just frameworks. Frameworks will come and go, but the core programming concepts (good design, algorithms, cleanliness, simplicity, data structures, architecture) will tend to stay relevant longer. Learn the principles of Reactive Programming, not just RXJs, learn the philosophy of Redux, not just its syntax. You won't be able to keep up with it otherwise. Source: a guy who was an actionscript guru 15 years ago.
This is a nice-sounding programming mantra but it doesn't make much sense in the real world, in my opinion. Learning the "philosophy" of Redux is a natural by-product of learning how to actually use Redux.
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.
> Learn [Vue.js] after you have learned React or Angular.
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'm with you. I went with Aurelia for a new project (which is unfortunately missing from his list) and would recommend it for everyone who wants to code an application using web standards. I briefly considered Vue but in this case needed a little something more and I found Aurelia to be more straightforward than React and Angular, especially after 14 years of application development in a variety of languages.
If I had to guess, the recommendation is due to that there are simply more jobs around React and Angular out there. There is a practical bent to the lists in the article.
Yeesh. In fairness it's a fine list, but you can be an excellent JavaScript developer and know less than one third of what's on that list. Ambitious JS lifers maybe can get to most of that, but for people who value some breadth of knowledge across tech, I'm not sure even pursuing such a list is a good idea.
My 2 cents. I would consider myself a JS expert as I have writen AngularJS and RequireJS clones. Personally, I don't agree with the path that OS JS dev has gone in recent years. The reliance on build systems and transpilers are fundamentally anathema to the spirit of simplicity and low barrier to entry that attracted me to the language and ecosystem inn the first place.
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.
I want a javascript framework that allows me to update a page incrementally, but also always works correctly and contains full content from the first server-side page load.
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's no longer cool on HN to use it, but jQuery-Pjax (https://github.com/defunkt/jquery-pjax) solved this problem years ago in a minimally intrusive way. I build all my projects with it. It's the only SPA framework that allows for full server side rendering after minimal configuration.
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'd really like to see this too. Most of what I've seen is something like "use node.js on the server and make use of the framework's server-side rendering capabilities". For me that's a problem, because I don't want and can't use node.js on the server.
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.
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".
I've been trying to find a solution for this problem. Basically, most of these suggestions here are "rewrite everything in NodeJS" (ignoring the requirement not to) or don't actually come close to meeting your requirements. Great news, I probably won't do better, but I'll post some things I haven't seen yet:
- 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.
Have you looked at intercooler (http://intercoolerjs.org)? I do not typically work on front end stuff and I know very little about the ecosystem but I recently used intercooler to build a pretty simple site with some AJAX stuff going on and it worked really well for me. At least the way I did it, it fits your criteria since my pages are fully rendered by the server (django in my case) for the initial request.
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.
I'm experimenting with a hybrid approach, where the server injects a JSON string into a hidden div's data attribute, containing all the data the front end would have traditionally received through an ajax call on initialization.
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.
If you are talking about an app shell and lazy-loading page fragments when you need them, check the PRPL pattern. Polymer provides an easy way to do it.
Great list! But I was perplexed by the text editors mentioned. Author claims to be looking at trend data, but seems to have a bias against Subljme Text editor. I don't know if there is some connection to Atom or VSCode, but it seems easily verifiable that Sublime and vim are vastly more popular than other editors mentioned, yet Sublime is inexplicably absent and vim is mentioned last and sort of offhand as more of just a tool you have to know for ssh sessions.
Sublime is absent because a lot of previous sublime users are now Atom users, and it is now the more popular editor by a large margin. Those comfortable with Sublime will find Atom very inviting.
React is mature and robust now, and still growing in popularity like a rocket. It's not going to be gone tomorrow. Angular 2 is just starting to become stable, but it still uses some ideas pioneered in Angular 1 going on 4 years ago.
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.
I must be honest, my experience with node was very short but this article suggests me that working with js may be really more complicated than working with java. Too many frameworks (which often lives too shortly), too many things to learn, it's overwhelming...sometimes it seems to me that working with js has become so difficult that working with java and jquery is still easier and better (i know lot of people will throw me hate for this comment!)
Apples and oranges.
You're comparing SPA paraphernalia with a library that basically gives you a sane cross browser JS API's and some goodies.
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).
I agree. The explosion of new ideas is also an explosion of learning curves.
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.
Or wait another year and pick the winner of the JavaScript framework war. It's unlikely that we will see new and relevant(!) JS frameworks over the next few years as we have seen in the past. 20 - 25 years ago dozens of Windows frameworks appeared on the market. Eventually VB won. History is repeating itself.
TypeScript is definitely by far the most important thing mentioned in the article. And no I didn't even read the article. I just searched it for the word TypeScript to see what it said. However, the author apparently is pretty clueless because he implied TypeScript has something to do with Angular. It doesn't. TypeScript is needed ANY time the runtime is JavaScript. Namely, in the browser. The only other technology TypeScript has ANYTHING do to with is JavaScript itself.
If you click through the links and actually read the content, I have plenty more to say about TypeScript, and why I consider it optional learning for JS developers.
I'm curious what people think about type checkers in JS. I've been doing full stack development for the last few years and BE development before that. Type safety has always been worth it to me, we adopted Flow and haven't looked back, although some FE developers aren't big fans of it.
[+] [-] dictum|9 years ago|reply
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.
[+] [-] d2xdy2|9 years ago|reply
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.
[+] [-] jessaustin|9 years ago|reply
[0] http://rollupjs.org/
[+] [-] gamesmaxed|9 years ago|reply
[+] [-] eranation|9 years ago|reply
[+] [-] sgdesign|9 years ago|reply
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.
[+] [-] Ka-Ching|9 years ago|reply
[+] [-] fenomas|9 years ago|reply
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.
[+] [-] stephenhuey|9 years ago|reply
[+] [-] Bahamut|9 years ago|reply
[+] [-] moxious|9 years ago|reply
[+] [-] faceyspacey|9 years ago|reply
[+] [-] daenney|9 years ago|reply
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.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] alistproducer2|9 years ago|reply
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.
[+] [-] heavenlyhash|9 years ago|reply
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.
[+] [-] bigmanwalter|9 years ago|reply
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.
[+] [-] DougWebb|9 years ago|reply
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.
[+] [-] paradite|9 years ago|reply
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".
[+] [-] Can_Not|9 years ago|reply
- 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.
[+] [-] caconym_|9 years ago|reply
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.
[+] [-] count_zero|9 years ago|reply
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/
[+] [-] gbrits|9 years ago|reply
[+] [-] rk06|9 years ago|reply
[+] [-] pomber|9 years ago|reply
[+] [-] doomtop|9 years ago|reply
[+] [-] ericelliott|9 years ago|reply
[+] [-] aeosynth|9 years ago|reply
[+] [-] ericelliott|9 years ago|reply
[+] [-] jaseemabid|9 years ago|reply
JavaScript as an ecosystem needs mature robust solutions rather than a new way to do things every other week.
[+] [-] ericelliott|9 years ago|reply
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.
[+] [-] Kiro|9 years ago|reply
[+] [-] thomasrognon|9 years ago|reply
[+] [-] progx|9 years ago|reply
[+] [-] andretti1977|9 years ago|reply
[+] [-] erik14th|9 years ago|reply
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).
[+] [-] tambourine_man|9 years ago|reply
The will to learn vanishes completely.
[+] [-] jasonthevillain|9 years ago|reply
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.
[+] [-] andrew_wc_brown|9 years ago|reply
[+] [-] roryisok|9 years ago|reply
[+] [-] ExpiredLink|9 years ago|reply
[+] [-] adamnemecek|9 years ago|reply
[+] [-] ClayFerguson|9 years ago|reply
[+] [-] ericelliott|9 years ago|reply
[+] [-] voltagex_|9 years ago|reply
[+] [-] jim_d|9 years ago|reply
[+] [-] ericelliott|9 years ago|reply
[+] [-] macpete|9 years ago|reply
[+] [-] amelius|9 years ago|reply
[+] [-] jgord|9 years ago|reply
I would say Ramda.js is most deserving of much wider adoption.