> 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.
You're all selling this as if it were some sort of philisophy. But it's not. Webpack just happens to be a piece of software that for reasons nobody will ever fully understand ended up being the de facto standard, all while being the most miserable to configure piece of software seen by mankind. (I. e. 4-level depth nested configuration with no indication of errors, a few different common patterns – ph, and there are two versions of webpack and the documentation rarely mentions which one it's talking about)[0].
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.
That's great, but it ain't there yet. [0] Incidentally, releasing a version 2 without deprecating version 1 seems a bit of a project smell... It might be the right thing to do in a particular situation, but what happened on the project that led to that situation?
Whole versions don't get deprecated. Visible features get deprecated when they are still present in the latest version but will be missing or incompatible in the next major version.
To my mind, the "semver way" would be to make tree-shaking an option on a new minor version. After some number of releases, it might become a default on a new major version, if the maintainers so chose. Splitting the project into multiple codebases is not required by semver.
I think you're being downvoted due to strawman ([s]he praised documenting concepts, not the documentation as a whole) but you're right though. I've never dived into my toolchain code (due to missing or frugal documentation) more than I've been forced to with Webpack.
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.
> ([s]he praised documenting concepts, not the documentation as a whole)
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).
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.
>> 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.
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.
> Learning the "philosophy" of Redux is a natural by-product of learning how to actually use Redux.
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)
That's a pretty apt analogy, really. If you just want to be a line cook at a no name franchise, then by all means, blindly follow recipes. If you want to understand what you're actually doing and have the ability to create new stuff without using a cookie-cutter template, yeah, you're going to need to go deeper.
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.
Programming is not complex. Frameworks make it complex, in the sense that they force you to use nontrivial concepts (I'm not against frameworks as a whole; when you're trying to do something complex it may be hugely useful to use one).
> 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.
This looks really cool! And simple. I am looking at it closely.
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 :)
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.
I wonder if you could get a build tool to dig in to the redux default state and compile the thing to index.html. Then you could use whatever you want for the backend.
That's basically the pattern my company is already using, implementing using our own plugin. We render the full page server-side (using ASP.Net MVC, which is hooked into our server-side Enterprise Application Framework), and then we hook up javascript handlers to manage client-side events. Those handlers can make AJAX requests for content updates, which we deliver either as pure data or server-side rendered html (which are rendered using the same partial templates that the initial page used.)
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.
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.
That's simply not true. I'm kind of tired of hearing about this kind of stuff said about JS. This comment adds absolutely nothing to the discussion about this article.
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.
From my personal experience what the parent comment stated is actually very true.
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 followed a gulp tutorial, continued using it. When webpack came out, the gulp community seemed like it's was just as alive as before. When webpack came out I didn't rewrite all my gulp code to webpack. I'm not sure how you got different results.
These are better points that actually have something to do with the article. I may have seen harsh in reply to the parent comment, but that's because that comment didn't address the article whatsoever, nor did it add anything to the discussion like you did.
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.
Reminds me of Gene Kranz's "Honest and Competent" speech he gave to his Mission Control team after the Apollo 1 fire in 1967. One thing he said in that speech has always stuck with me: "Nothing we did had any shelf life... he were too gung ho about the schedule... nobody said, 'dammit, stop!'"
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 think the interesting thing is that for 90% of what is being built most tools are overkill and JQuery is really good enough. I say that as someone that started using React/Flux almost 2 years ago, and as someone in the midst of moving from Flux stores to Redux. The power of these tools is when there are large teams involved, when the complexity of the state on the FrontEnd is extremely high, and when you absolutely need a Single Page Application. Most of the time all 3 of those conditions aren't true, and in those cases you're better off using something like jQuery which is boring, easy to reason about, and everybody already knows it well.
I agree and this is exactly what i feel: too much complexity that seems needless. I hardly have cases where i can't develop reasonably complex frontend and must use angular or react so i can't stand all this javascript frameworks useless (imo) complexity.
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.
Just remember that attention is a limited resource and there are very likely things you know that would trigger similar reactions in others.
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.
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.
Well you've definitely misguided everyone by suggesting TypeScript is in any way related to Angular. There is absolutely no relation. You should fix that.
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.
I think it's standing in the industry scratches the enterprise itch, so it's popular amongst professionals and corporates. You can't get fired for picking Angular, in other words.
As to how it came to be in that standing, it was and likely still is a very powerful platform.
I recently wrote an embed widget for a client, a simple 5 field form with some dynamic drop-down changing and a date picker. 40/50 lines of js maybe with a simple date picker (pickadate I think).
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.
Sometimes this can be a case of Maslow's hammer, though - if you work for a shop where they've standardised on Angular (or whatever) as their go-to solution for everything, you can end up with massive overkill in some scenarios while, overall, it's probably still cost-effective and perhaps somewhat sensible to have a standardised approach.
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).
Completely agree, you don't need a framework at all for a task like that. We have had some pretty crazy implementations of simple static sites. One had not a single line of HTML as it was all template engine tags instead, that one was silly.
thanks for taking my question seriously. seems like the only really good answer.
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 fairness, your question hardly reads as a question and much more like a halfhearted sigh from someone who hasn't given it much thought.
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.
"In fairness, your question hardly reads as a question and much more like a halfhearted sigh from someone who hasn't given it much thought."
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.
All I'm suggesting is that just because you are a self described 'react fanboy' (using your own words here from your comment history), it doesn't make Angular less useful in the real world.
I applaud your use of React, but we are using angular2 and it is going just fine. All the best.
> Because it solves real world business problems. Some people need to build large systems in a SPA framework
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.
I think you're wrong, but only because you went in the wrong direction. In my experience Angular is best for the "I don't care how, I just need it done" crowd. The architecture, data model, routing setup, etc are all defined for you. However I've found React/Vue/Ember are better for "I need to create a complex system with a long shelf-life that will be touched by many people".
Because it appeals to programmers coming from a background in C# and Java. It can feel out of place to programmers used to jQuery and Node but it's very appealing to the enterprise mindset.
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.
Personally I value mature, well understood solutions. Angular delivers that and the ecosystem around it is finally about there. I can use ui-bootstrap (Angular material not as much) on a relatively large application without running into defects at every step. And there is an enormously high probability that the answer to any issue my team runs into is one Google away.
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.
Because is a Built-in solution. I have not to look for extension libraries like I have with react, and everytime try to choose between a lot of crap alternatives to a single functionality I need on react. I just pick Angular and everything I need is already inside that framework, far far far less headaches.
Speaking as a Pivotal Labs employee who has done a shitload of Angular 1 development, this is not true. I still like Angular personally, but enthusiasm is definitely way higher in the React direction unless the client demands we do something else.
I'm looking for a React Admin/Dashboard template. There's various themes at https://wrapbootstrap.com/ but haven't been totally satisfied with the React offerings.
The article recommends learning both pure functions AND closure? So is the point of learning to use closure is just so that you know why you should never use it?
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.