Why Learning Angular 2 Was Excruciating
hackernoon.com
hackernoon.com
Sometimes I feel that with Javascript, we developers have taken something that wasn't ours, and we're in the process of destroying the best thing there ever was about it.
One of its best qualities used to be that you could have absolutely no idea what you're doing, read a few bad tutorials somewhere on the web, mash your head onto the keyboard and end up with something horrifying that was nevertheless close to what you wanted to achieve. It was beautiful, egalitarian. Like the web is supposed to be.
I've spent quite a bit of time on Stackoverflow, coaching people who you would not call developers (nor would they themselves) on how to do that one tiny thing they wanted to add to the site for their bakery, yoga studio or blog. And almost got it working themselves. I know of no other language that can tell a similar success story, with that high an impact.
Just insert that <script> for that jQuery plugin here and modify that initializer over there with a vague understand of how it needs to be adapted to your situation. Voilà!
But we couldn't let that stand, could we? Because what works for Alice and Bob doesn't work for somebody writing that 200.000 line image editor or CRM in JS, and let's face it, that's what the web is about.
So here we are, the single <script> tag having been replaced with compilers, transpilers, five mutually incompatible build systems, three different module systems in God knows how many implementations, frameworks changing their API every ten minutes and five thousand lines of NPM module code to be installed for even the simplest of tasks.
We did it, gals and guys! The web is safely back in the hands of full-time professionals (with Hindu cow-like frustration tolerance). Where it belongs.
Bah.
I would also point out that the web is the most backwards-compatible platform of all time and Alice and Bob can continue doing their thing for as long as they want.
The tools that professionals use today are an abstraction to increase efficiency and reduce code reuse, in the same way most programmers don't code assembly or C anymore. I'm not sure every part of the modern web stack is a universal good, but I'd be lying if I didn't say I'm more pleased coding on the web today than I was hacking together a Geocities page in my teenage years.
But I object to the argument that people can just continue to do their thing, because people in that position are overwhelmingly dependent on the ecosystem. Guidance, libraries, tools. And that ecosystem has left them behind, or is at least very far along that road.
Of course reasonable people might disagree, but to me, that people might write unoptimized (or just plain horrible) code is a very, very small price to pay for the empowerment the web delivers to them. And as to "insecure" - Jane and Joe want to show a slideshow of their hand-baked Macarons, not write banking auth systems. If they manage to open up a security risk, the attack surface is usually rather small, and the fault lies with the platform.
No, I stand by this: Javascript was our generations Hypercard, on steroids, and we've almost completely squandered its potential.
However, it's important to realize that the way the web is moving is to not only benefit the working professionals being paid to write it, but also the consumers who experience it.
Why do we have minifiers and transpilers and modules and font icons? Why do we aim for one script tag instead of 50?
Because for a consumer, the web sucked (and still sucks to an extent, but less so with AMP and offline APIs.) For "prosumers" like Alice and Bob, it was a buffet, but for people browing their web pages it sucked. It was slow and unresponsive and that's even before the rise of the mobile web.
And whether the ecosystem leaves them behind or not, Alice and Bob can always create a new slideshow.js file on any given platform they want.
The web is moving towards being better for professionals and consumers, and I agree that those in the middle might lose out a little, but they are very small peanuts. I'd rather optimize for the next billion users in Africa, India and beyond, most of whom are on sub-2G speeds, than for the script kiddies making an easy living pilfering jQuery widgets without learning the platform.
There are embedded YouTube videos, MP3s, and code samples to illustrate what he's writing about. He's implemented their ideas using the Web Audio API and you can run the code from within the page and listen to the music being generated in real-time. It's a real testament to how great the web can be.
I think being able to do things like that is worth all the annoying parts of the modern web, in the end. For the developer and the end user. I wouldn't want to go back to the old way. I think it's easy to focus on the annoying parts and take the good parts for granted.
Doing something in a browser that we could do 30 years ago on a desktop isn't that great a testament.
Is this that much more efficient than "apt-get install foo"?
Not every platform/OS even has a (good) package manager. So I think this alone is what makes the web great.
Furthermore, free isn't free when my privacy is sold and/or my eye balls are subjected to even more ads. This is progress? No fucking way.
I don't know what you are on about as there weren't any app stores controlled by Apple or MS. Anyone was able to release crap software on floppy disks or BBS, and they did.
I'm not sure it's completely comparable though, file sizes would have increased even without minification.
Mediocre solutions are fixed with an endless array of tools. Learning tools takes time. And that's just to break even. And around we go again.
Can we really say the average web experience is better than the average of 10 or just 5 years ago? (Hint: Nope.) Find someone who is less frustrated with technology and you'll find someone who has given up on technology.
I think that many of the front end tools we use now result in an optimized developer workflow, but usually not optimized code.
Or perhaps this is one of those things where people assert that the existence of things they don't want to use is somehow offensive. Still isn't a very helpful point to make.
It could be related to the signal-to-noise ratio. If I'm a non-dev looking to throw something together and 98% of the information I find is about some pro-level frameworks, it'll be hard for me to sort through that and find information appropriate to my skill level, level of interest, and needs.
Maybe it's still a net-gain for the world as a whole, but it's certainly a loss for the non-dev. It makes the learning curve (perhaps needlessly, perhaps not) more regressive.
I don't see browsers dropping ES5 support any time soon, and jQuery isn't going to disappear.
There will still be plenty of opportunity for people to jump in seize great market opportunities using PHP, jQuery, and chewing gum while all of us full-time professionals are here on HN arguing about Angular vs React and whether npm is insane, awesome, or both.
Again, don't get me wrong - when I was writing what was called DHTML almost fifteen years ago, I would have killed for the APIs, capabilities and cross-platform stability we have today. It's a good thing. Lots of shiny.
I simply feel that this is a concern that doesn't get enough attention, certainly not around circles like these that in the end drive the further evolution of development on the web platform. And that we collectively would do well to at least acknowledge the trade-offs we're making in the process.
However, JavaScript now gets used by real programmers for real applications, and has therefore evolved to accomodate for that.
You're saying (incorrectly) that now inexperienced programmers can't put crappy scripts online without knowing what they're doing and hope the thing works. Well, you can still do that, but you can also actually learn the language and build serious stuff.
I can't see how this is the wrong direction for JavaScript.
IMO, the JavaScript ecosystem has matured. Sometimes in weird ways that aren't great, but it's still better to have an irritating package manager than no package manager at all. But there's no price to be paid here - if you don't want to use any of it, you don't have to.
But on the other hand I cannot count the number of times I've seen Angular included for a simple contact form with validation on a static site, React to render a single trivial dynamic list or a nice, but basic JS lib that only works in module form via NPM exports.
Sorry if I sound like a fortune cookie, but it's true - if all you've got is a hammer, everything looks like a nail.
Since 2001 or so, I can count on three fingers the number of variable collisions I have experienced in small- to medium scale projects. That I as a newbie now have to understand and manage various module systems in order to embed a lightbox on my site is a huge jump in complexity for a gain that is at best negligible in practice.
And while you and I probably have worked on some higher-complexity use cases, I think we would be kidding ourselves if we assumed that this constitutes the majority of the web.
Because that's not Facebook-scale, it's the dude around your corner selling dishwashers and reparing washing machines, trying to get his inventories's prices from an Excel sheet onto his page with a minimum of fuzz.
Do they? In most tests I've seen straight javascript / jquery on the DOM is faster. eg. https://objectpartners.com/2015/11/19/comparing-react-js-per...
> One of its best qualities used to be that you could
> have absolutely no idea what you're doing, read a few
> bad tutorials somewhere on the web, mash your head
> onto the keyboard and end up with something
> horrifying that was nevertheless close to what you
> wanted to achieve.
> I know of no other language that can tell a similar
> success story, with that high an impact.
And I agree with your overall point. Shitty code often makes the world a better place. It gets a bad rap from developers because we compare it to good code. But shitty code written by non-devs is not replacing good code, it is replacing an absence of code. And shitty code, for all its sins, is still often better than no code at all (which usually has the same sins).
That's one of those things I have probably read - and agreed with - a hundred times before, but never that succinct.
I will make that mine; I hope you don't mind.
This is changing for the better with web components. Now you'll be able to have just a `<script>` tag and define a component and use it in markup. It'll be even simpler than jQuery, and saner at the same time.
So you can do this:
<script>
class MyElement extends HTMLElement {
constructor() {
super();
console.log('yay!');
}
}
customElements.define('my-element', MyElement);
</script>
<my-element></my-element>
Having said that, I think in the case of the direction of Javascript itself: I believe it is going in the right direction. ECMAScript 2015 was a mammoth release that really took Javascript in a nice direction, the smaller ES2016 release adds a few minor features and ES2017 is shaping up to be another monumental release for Javascript. The ecosystem as you mention is really in a confusing state at present.
The only constant in all of this is Javascript. We are living in an era where things are being deprecated before they even hit 1.0. The one part of front-end development heading in the wrong direction is the questionable design choices of frameworks like Angular and React. The only framework I have seen which is abiding by actual web standards is Aurelia. The lack of Aurelia specific concepts means you're not committing to something proprietary you're stuck using, like the case with Angular 2 and ReactJS.
Then you have the elephant in the tooling room: Webpack. People are using it, it is becoming increasingly popular in the front-end space, but it has basically no documentation and it is incredibly confusing. People are using it, without even understanding it or knowing how to use it. Mostly learning from blog posts and StackOverflow. Webpack 2 looks promising, but it probably won't have any documentation either.
It is almost like nobody seems to plan anything, choosing to develop and release off of the cuff. Even when Babel dramatically broke things out and changed the way it works for v6, that was a painful experience for the ecosystem in itself. Then you have System.js, JSPM and other tooling/module loaders breaking things every release.
Sure, Mr. Bakery, do everything in jQuery in a <script> tag. I'd even argue that's probably the correct approach.
But I don't work for a bakery -- I work for a large company with a complex tech stack writing web applications that will have to be maintained by some poor sucker long after I move on. Tools like React/Angular, Webpack, and npm allow me to do that in a way I couldn't as little as 3-4 years ago.
I see comments like this in every one of these threads. It's shocking to me how misunderstood web development really is. If the web was meant to be strictly utilitarian we never should have moved off gopher.
Or rewritten because the flavor of the month has changed.
>Tools like React/Angular, Webpack, and npm allow me to do that in a way I couldn't as little as 3-4 years ago.
What exactly couldn't you do 3-4 years ago that you can now?
This has only been something we've gotten right over the last few years. jQuery trampled all over the DOM, data-binding heavy frameworks like Backbone were impossible to reason about, Closure Library turned your Javascript into Java-flavored spaghetti, Coffeescript was basically Perl, and CSS was global by default. Now React lets me write perfectly performant abstractable code. Redux lets me manage state in a functional, reproducible way. Webpack supports CSS modules which let me write sane styles and code-splitting so I don't need to worry about managing resources. Typescript lets me write code that's safe and easy for others to consume. ES6 modules allow me to actually architect my codebase without shoving everything onto window. And the ringer is I'm not married to any of these technologies -- I can scalp out Redux for another data store, Typescript for Babel, go back to global CSS, etc.
Writing UI code is hard, and I'm not sure why some HN folks assume web developers are ignorant. Web apps are a HUGE hack, and it's funny to me that a forum dedicated to hackers has so many who shun it for that reason. It's not "flavor-of-the-month", it's finally making progress towards a really hard problem in really exciting ways.
Probably because every feature you listed was achievable before react.
How did you do type checking before TypeScript (or the like) in JS? give me a real answer.......
One very common way though was to avoid the need for it altogether in javascript, by rendering html on the server.
What does server-side rendering have to do with Typescript? Are you advocating avoiding javascript all together?
But yes, I do advocate avoiding javascript altogether whenever possible (which is more often than current trends). There were a number of other transpilers too, all of which were a pain and I don't see how typescript is going to improve on that.
But it really isn't and the proof is HyperCard from the 1980s. It's only hard because you have made it hard, for no reason that anyone can fathom (apart perhaps from job security).
Do you really think everybody -- from Android/iOS to Swing to qt to Web 2.0 -- just had no idea what they were doing?
And really, what all of this boils down to is: avoid declarative control structures at all costs. Procedural design by default. There are a handful of situations where I will build a declarative API, but they are rare. I will use libraries, but only if they have a single well defined purpose and are largely procedural.
The result? It's wonderful. All of my code is completely traceable. If something doesn't work, I never have to go read online for an hour, dig around in the source code for random modules trying to understand boot and build processes well enough that I can form a hypothesis about where a bug is. I just start at whatever point my expectation is violated, and work directly back to whatever is broken.
I can always insert a debugger statement, and instantly stop state either in Node or in the browser. The execution path and data handoffs never disappear into a mysterious framework or executable. The code in production is always in . or ./node_modules.
The entire class of headaches so prevalent in Rails/Ember/every other declarative-is-best system are just gone. Granted, I deal with other headaches. I have to really think about how data moves through the system. I can't just add a flag to access data from one end of the system in a totally different part of my app, because there's no magical framework code using light AI to figure out how to marshal data around based on some declarative configuration conditions.
Essentially what I've decided is it's better to sacrifice convenience in order to get inspectability. You lose speed in your initial hacking, but you gain a predictable pace of debugging. Bugs never really stay mysterious longer than 15 minutes or so. I never have those instances where I spend a whole workday scratching my head about framework internals.
I do spend a day scratching my head about how my data should be structured and how it should flow through the system. But that's effort that will continue to pay dividends. It generally leads to better interfaces that require less maintenance. Work that is often continually put off when you have a framework that offers every shortcut that could be sanely crammed into it.
Why do you argue about something that clearly doesn't interest you? From a so-called professional: It's perfectly fine to continue doing websites the way you do if that works for you and your client. End of story.
Everything else that confuses you is just the world of software getting bigger, Javascript being used in different places, people trying out things and promoting them, good stuff, bad stuff, you know – like the real world. Imagine knowing every aspect (political, economical, social) of a larger city and you would go crazy as well. Breathe and relax.
Google tends to release code and promote it without really using it much internally first. Documentation is prolific but confusingly organized and often fragmented among several versions simultaneously (cough, Google Analytics).
Facebook, on the other hand, actually seems to use their code before releasing and promoting it. Look at how they handled GraphQL: spec and reference implementation released a year ago, clearly labeled as a "Technology Preview". A lot of design work went into it before that, informed by the problems of internal product teams. Only a few days ago was it promoted as ready for production. The spec hardly changed it the last year. Documentation is good, and they work with the community to improve DX.
Why the difference? Hard to say, but my feeling is that there's a more direct link between Facebook's product-driven open source work and their bottom line. There are other startups constantly nipping at their heels, so they need to be on their game product-wise. Better code -> better products -> profits.
Google is largely impervious in the search and ad space, which is their cash cow. It almost doesn't matter how good or bad their other products are. The company is not at risk. Their open source work reflects that.
Really drove home the concept that open-source requires significant thinking and discipline when a library becomes heavily used.
They have said the usage of Angular off of HEAD of master publicly in the past as well, but I don't recall off the top of my head where they have said this.
> Google tends to release code and promote it without
> really using it much internally first.
(edit: Angular was first used on an internal app at Googel: https://www.youtube.com/watch?v=r1A1VR0ibIQ&feature=youtu.be...)
Bazel, Tensorflow, protobufs, GWT (a web/JavaScript project!), dozens of utility libraries, etc.
You are forgetting that Google is a huge company, much bigger than Facebook. It's more a collection of disparate entities than a monolithic giant. Each open source project is run differently.
According to Brad Green, the Engineering Director over Angular, Google AdWords, Google Fiber, and some internal tools are all built with NG2. AdWords is kind of big deal to Google.
Edit: source for AdWords reference, http://angularjs.blogspot.com/2015/11/how-google-uses-angula...
Angular came out 2.5 years before React. Facebook had a predecessor to flesh out what does and doesn't work. Google started the autonomous car, and now other companies are following suit. Google starts the race, but they might not be in first place at the end. Ultimately, consumers win.
Better code -> better products -> profits.
What about Golang? Considering this conclusion is out of scope from the premise 'open source for the web', anyways.
Is it the documentation that is the essence of 'better code'? If not, then what? Left to my own devices, I will summon functional programming constructs such as Monads or Catamorphisms in personal projects. Keyword: personal projects. I think it's elegant, but someone unfamiliar with these constructs might abhor it. Analogously, what's the best programming language?
Do the arrows imply: if better code then better products, and if better products then more profits? If that's the logical structure, I can easily think of examples of companies enjoying great profits but bad code / bad products. Moreover, the direction of causality could also be profits -> better products -> better code. In reality, it's most likely to be a complex / dynamical relationship involving many other variables.
Google is largely impervious in the search and ad space, which is their cash cow. It almost doesn't matter how good or bad their other products are.
What other products from Facebook did you have in mind? I genuinely cannot think of anything other than the social network, Instagram, and Facebook messenger. Facebook is largely impervious in the social networking and ad space. Does it matter how good or bad their other products are?
I get your beef with the ecosystem, but this is a very unfair knock on Angular 2. Angular 2 was not the problem here at all.
Am I missing something obvious?
>Angular 2 is going to have breaking changes only every 6 months from now on. So the next one would be around February with Angular 3. Yes exactly, they’re also finally switching to semantic versioning which is a huge win in my opinion.
IMHO, breaking changes every six months is the recipe for an shitshow of an ecosystem.
Sounds like a way to prevent having to completely rewrite from the ground-up to keep up with the web a la angularjs.
I like React because it's a lot smaller but I totally see the advantages of Angular 2 and I kinda dig the major release cycle.
As soon as you rely on packages that support Angular 2, the 'good and ready' argument breaks, since you can't start till all the packages you rely upon have already made the upgrade, and you can't take to long either, because you can't expect further work or fixes to be made to older versions of the packages.
12-month breaking changes, that would have made sense.
That said, breaking changes every six months seems to be commonplace in major open source packages. My initial reaction was 'OMG, now they want to repeat the Angular 2 debacle every 6 months?!?', which doesn't seem to be the case.
http://tech.shantanugoel.com/2008/05/21/ubuntu-what-exactly-...
The scope of the breaking changes matter more, and that story has yet to be told.
The more I reflect, the more I see this as about poor expectation management and messaging from the Angular team than an actual story.
When? Can you cite an example? Keep in mind that for most breaking changes React typically goes to a deprecation warning for the duration of a major release instead of hard-breaking changes, so in reality you have roughly double the time between truly breaking releases, generally speaking.
That is true about the deprecation, although some of the earmarked breaking changes have been quite painful too.
Hopefully the Angular team takes this route for planned breaking changes & apply engineering to ease compatibility.
React releases every 6 months or so, and puts deprecation warning on anything that is breaking in the next update, so you have a full year between any breaking features, and six months for everyone to update before they land.
For someone coming from the Java world seeing a very popular framework with a release candidate of their 2.0 release - that would portray a very different story.
It's sheer insanity to make breaking changes or upgrade the dependencies between a release candidate and a final version. The upgrade from a release candidate to a final version should be the easiest upgrade in the world.
Angular 2 is final now and they've committed to no more breaking changes until the next major build (at least 6 months away). If s/he started learning with it today, then ~90% of what s/he was complaining about in this post wouldn't have been a thing. That was my only point.
He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake
Release Candidate means "The API is considered finished and we are stabilizing the code before our final release"
Release Candidate doesn't mean "Beware! Don't you dare to build a real world application with our library since we will be breaking the API on a whim".
If I wanted a dependency to have unpredictable breaking changes every minor version I would pick an Alpha version, not a Release Candidate one.
Although to be fair, in my particular case it was my fault, seeing "Breaking Changes" in the changelog of a Release Candidate was a red flag I decided to ignore.
I also recall there being around 30 issues for Angular 2 Final on github milestones the day they announced the release, but they were mysteriously gone in the afternoon.
Angular 2 Final seems to be anything but.
function App(props) { return <div>Hello {props.name}</div>; }
ReactDOM.render( <App name="nichochar" />, document.getElementById('root') );
Or the alternative component API that has componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentDidUpdate, componentWillUnmount, and render.
That's pretty much all there is
Then there's routing, which is not present in the React core, so you'll need a routing library as well. Again your API surface increases.
In the end, if you want to write a larger application with React, you'll often have a similar or even larger API surface than Angular. I can understand that some people prefer the conceptual model of React (with its focus on Components) over that of Angular. The claims about a smaller "API surface" have always felt wrong to me, though.
For instance if you've already spent time learning about Redux you'll have a very easy time re-using those in Angular 2 (with ngrx).
By coincidence Dan Abramov just posted this: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Angular 1 still beats the pants off of everything else in my experience, if you know how to trim the fat. I'd very much like to write more about my approach in the near future.
If you look at react-redux-starter-kit [1], I would absolutely not say that it's simple. This file [2] is only 12 lines of code but can you call it simple? I don't think so.
[1] https://github.com/davezuko/react-redux-starter-kit
[2] https://github.com/davezuko/react-redux-starter-kit/blob/mas...
React has become synonymous in some people's minds with "React + a bunch of other stuff", but this wasn't intentional. It's an unfortunate side effect of its popularity.
Oh, plus react-router for routing, I guess. And Redux, obviously. Plus react-router-redux to link them together, and react-router-scroll for scroll history. Also react-intl to handle internationalisation. And react-helmet to do document header stuff. You'll need to use immutable as well, obviously, so you'll need redux-immutable. And redux-saga. Hmm, you'll definitely need a selector library like reselect. Better throw in reactcss too. Gotta get them inline styles going!
Anyway, just those and a couple dozen other libraries and you're good to go. Then once you've set up Flow types, Babel compilation, isomorphism, bundling with hot module reloading in Webpack, linting and testing, you've got a rockin' React app. Easy as that!
For me, the primary difference between a library and a framework is the the typical direction of instantiation and calls between your own code and that of the library/framework, and the ownership of the main workflow / event loop. E.g. does it feel like your code uses the 3rd party code, or that the 3rd party code uses yours?
Putting it more concretely, when you code is executed, does the 3rd party code tend to come after it in the stack, or before it?
With a library, you're mostly calling its methods. So, a library is something like jQuery, where you're just making a lot of calls to its methods. Those libraries might do some very complicated things, but they're still just operations that you have launched, and which eventually return control to your code.
With a framework, you're inheriting from framework classes, and conforming to a workflow that the framework controls. For me, that describes React. You write in its JS dialect (jsx), your classes inherit from React.Component, and you hand over control of the rendering workflow to ReactDOM.Render and the virtual DOM.
I'm no frontender, but lucky to be in a team that got that sh!t under control, luckily.
"Javascript the good parts" has served me well.
This will all settle down in a year or two, once we get the most basic features built-in into browsers. Like for example modules + HTTP2 will probably mean no more bundlers or build tools (which is where the vast majority of this craziness is coming from)
I really wish people would qualify what they're trying to accomplish when they bang on about things being "needlessly complex". Maybe for what they're doing it totally is and they shouldn't be distracted with React, Flux, Webpack, etc. There's nothing wrong with that. However, when taking on a project where these sorts of things are immensely useful, it's nice they exist.
I'm not saying we shouldn't get on react - I'm sure in the end it will serve myself and others well, but it's a bit of a headf*ck trying to figure out the whole ecosystem, and how to write a good solid app in it. For anyone that tries to say "but it's only react with x" - No it's not! Not for anyone that cares about the quality of their app, theres a whole heap to learn.
And I am learning, but at the same time I'd rather create a well designed app with the crummy tech I know than a crummy app in something I just haven't figured out yet. Luckily I'm doing my own thing so have that choice.
I mean why use one package manager/module loader when you can use 4?
* that was still in beta/upgrading to the official version that was released last week
* that was redesigned from the ground up by a company that is pretty intent on not doing things in JavaScript (see Dart, TypeScript docs but no ES5 docs)
* whose original announcement of versional incompatibility was one of the major reasons its competition became popular
* has clearly been attempting to frankenstein a lot of ideas from other libraries/frameworks in awkward ways
The JavaScript community definitely has warts - I have zero issue with that statement. But the real problem comes from developers from other language-communities making blanket statements about the JS community while using tools that are clearly marked as unstable when they could've just as easily (actually... much more easily) written said app with any library/framework that wasn't released literally a week ago or even used raw JS - an API that hasn't had many breaking changes or compatibility issues in quite a while.
So I completely agree with you, but I've seen many programmers whip up something in a weekend and not be able to extend the functionality of their app because they had no idea how everything fit together in the 'magical framework' of their choice.
I'm not new to JS, and React's approach was the first one in years that I found very interesting in a way that didn't feel bloated or over-engineered out of the gate.
However, that's very hard to do if your time is limited and you need to add a feature to an existing app or get something working ASAP. Stumbling through the API is the norm if you're doing something fast.
It reminds me of when I was trying to get Photoshop to do something before really sitting down and learning the principles. So much wasted time.
In the end, it's always worth it to learn the basics first, but your team will not always agree.
The problem isn't so much that "raw" Javascript has a lot of problems; it's that every solution requires you to fully understand the problem and the architecture of the solution.
Promises ease the pain of async in JS, but you've got to understand async well enough to implement Promises yourself in order to accurately predict their behaviour.
JQuery eases the pain of the DOM, but you've got to understand how the DOM (and events) work to use it properly.
Angular eases the pain of structuring large applications, but you've got to understand...everything...before you can use it properly. And also jQuery. And also the DOM. And also a build tool to manage the heap of complexity you've just bought.
This sort of thing does occurs in other ecosystems: for example, I love Clojure, but you're going to have a bad time with it if you don't grok how Java works. But the JS ecosystem is absolutely teeming with it - often nested several layers deep!
The JS community seem to have Stockholm syndrome about this. In other contexts it is just not normal to have to operate simultaneously at all levels of the abstraction hierarchy, at all times. Joel Spolsky wrote his famous "leaky abstractions" essay because it was not immediately obvious that when (eg) using a TCP connection, you'll eventually want to know about how IP works. If TCP/IP had been written in the modern JS ecosystem, you'd need to have a working knowledge of ICMP packet types before you finished debugging "Hello, World" in TCP v2.0.1-rc4(deprecated).
I'm building a simple front end and I had settled on Angular. But there are too many choices out there. I know there's no simple answer, but there ought to be "rules of thumb" out there to consider. e.g., does your team know Typescript? do you want to use plain old Javascript? etc etc etc.
The choices are staggering.
The thing I find funny about Angular 2 is all of the breaking changes they made during the release candidate. The whole point of a RC is no breaking changes and just bug fixes to get it stable before final release. They rewrote the router component 3 times alone. Updating from each RC release in itself was a nightmare for many.
The whole misconception that because Angular 2 is Google affiliated it is the best framework around needs to die. Angular 2 is a Greentea oriented framework that isn't built for the public and first and foremost, for Google's own internal needs first.
Aurelia is incredibly underrated and many of the developers I know who come from a background in Java and .NET where concepts like dependency injection are very important absolutely love Aurelia for introducing those concepts in an easy to use and understand manner.
It may settle down with time. I hope it settles down with time. JavaScript has evolved a lot just in the past couple of years, and so it feels like everybody kinda went, "Oh, wait, we're doing all of this wrong, we have to start over!" But, the ecosystem has done it several times now for almost every problem that needs solving, and it's starting to get old. At some point, shouldn't things settle on a Best Practices solution that is stable and predictable? I mean, not for everything, obviously...but, how many times and ways does, say, routing, need to be solved in incompatible ways?
I dunno. I try to just be excited about all of the amazing building blocks what I get for free when I buy into the JavaScript ecosystem...but, "free" starts to look really expensive when it is so painful to deploy it and keep it running reliably over a period of months and years.
Node core modules have been remarkably stable since 0.12.x, so most of npm packages one would install are libraries, with very narrow responsibilities. A few popular frameworks have also been fairly stable and well understood (Express, Bluebird).
With Angular, you also have a myriad of libraries available to you, easily pluggable via Angular DI, but the very core framework has changed a lot... so in the Javascript frontend, things are much further away from a "battle-tested best practices" than the backend.
I can't say if it's more stable than bower, but IME it's not stable at all. My simple blog static site generator breaks every time I write a new blog post.
I am using deprecated libraries at work. I just recently upgraded to React Router v2 when they are already gearing up for v3 (and refactoring for v4). It's just part of how the ecosystem works. We are lucky that a side effect of its business is the abundance of useful libraries.
I had a pet project with react and redux that I didn't touch for a few months as I was busy with other things. I came back to it recently and there are new major version of: react-redux, redux, react-router, webpack and various plugins, react-router-redux, react-hotloader, babel, and I'm sure a couple other things. It was a PITA to set up in the first place, and just a few months later, it all needed to be reconfigured.
I sometimes tend to try out beta releases when learning something new and interesting, but that does tend to backfire now and then when it's unstable enough that I can't tell if I'm doing something wrong, the framework is buggy or the documentation is simply outdated.
But those definitions have become much more fluid, and it's hard to find out which definitions everyone is using.
It certainly means API changes are not anticipated, and that there should be a very significant problem with an API to lead to an API change at that point; certainly one would hope that fundamental flaws in an API that make it unsuitable for release would be identified well before an RC.
But its certainly possible to have reasons to make a breaking change from an RC (e.g. -- not necessarily relevant to a front-end framework, obviously -- a security vulnerability uncovered that reveals a critical flaw in the logical design, rather than implementation, of an API.)
Sure. After which you issue a new RC, not the final release.
Anyway my personal attitude is to keep away from alphas, betas, RCs and stable-from-yesterday. Applies to frameworks, operating systems and virtually everything, and each time I don't follow that rule, I regret.
I started a project at around RC4. It's my own fault to some extent for doing that and not waiting or using angular1.
I found that most of the core functionality like component annotations, ngInit, template syntax didn't change - although I wasnt trying to use the router or forms modules which did experience large changes over the 6 months.
For me most of the pain was in keeping up with changes in the boilerplate stuff in the root of the app like main.ts, modules and and the same keeping up with recent big changes in angular-cli.
And that isn't just the case for frameworks, it extends to tooling as well. JS is a mess - one that I am involved in first hand - and it's hard to find stable footing.
I think a big portion of pain is around the sheer depth of the dependency trees we wind up in npm/js land these days - a trivial little service can wind up with hundreds of disparately maintained dependencies, and you just have to shrinkwrap, hope, and cross your fingers things work out.
I don't know that we're at that point in the ecosystem yet. Is there a good JavaScript framework that is operated by a team committed to keeping its API stable?
...except for Zone.js errors. Everytime I saw a zone.js error in the call stack my brain perceived it as a giant middle finger rendered in ASCII in my console.
I have been trying all three recently back and forth and now leaning back to vuejs while waiting for its 2.0 release.
I'm having little problem learning the language. My problem was trying to bite off the CLI - Webpack is a huge learning curve for me.
From what I understand in Vue 2 they're tackling that by having two different versions of the CLI, but I haven't checked it out yet. Vue listens to their developers and really does try harder.
As far as your other conclusions around how this sort of problem exists in general in the JS community, I think you are wrong :) That's like me saying the Java community is chaotic because I experienced problems installing Java.
Unfortunatly, I think you may have bitten off more than you can chew with jumping in to web development with an in-progress framework which is also using completely new build/development workflow. But I guess the rewards are worth it since you really are at the bleeding edge :)
Not to mention stupid behavior, like Angular app behavior depend on order of components clicked.
Also, this has already been discussed; we get it. RC5/6/7 sucked for everyone (well, except those of us who were eagerly waiting for forms 2.0). Must we do daily "omg rc5 was painful" posts?
The change to ngModule took 15 minutes btw, more if you count all the code you got to remove from other components.
How much frustration is "normal"? How much "confusion" is normal? I say A LOT of both.
"To be fair, I have been using versions of the library that have thus far not been officially released. Maybe, you say, it’s my fault for trying to download and use a version of the library that is still in alpha/beta/release candidate and expecting it to work and be relatively easy to use. Perhaps you are right. But, considering the fact that hundreds of thousands of developers are already using Angular 2, we should ask ourselves the question: is it responsible to release libraries that are still very much a work in progress?"
They told you it was an RC, but now that a lot of people have started using it, you want them to no longer treat it as an RC. (And like a true whiner who likely will never contribute a single line of code, you want this all for free, of course.)
Projects with lot of breaking changes for minor releases should raise red flags, so steer away! Instead of wasting valuable time being bleeding edge, take a deep breath, turn your focus 180 degrees and say to yourself: I think will check it out in 5 years. There are a lot of other great, stable and mature web frameworks out there.
A release candidate isn't a release, and the release may have breaking changes from the RC, and obviously an RC of anything that would be a semver major release may have breaking changes from the previous actual release. So, in either direction, an RC may have breaking changes.
Ideally, the last RC should not have breaking changes between it and the actual release, but we wouldn't need a "candidate" if we knew things would be ideal.
It's not acceptable after an alpha release, It's especially not acceptable after a beta release. And it is offensive against developers to have breaking changes from the first release candidate and onwards.
Even for major releases, breaking changes is a VERY BAD thing. But sometimes it is unfortunately unavoidable.
Maybe I'm old-fashioned but if you're still planning on changing the API, don't call it a release candidate.
If you are planning on changing anything it shouldn't be a release candidate.
OTOH, the reason for the "candidate" part of "release candidate" is that things may still change from the plan.
"RC" is not an excuse to flush semver down the toilet. If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.
That's true. Then again, an RC in semver is a prerelease version and "A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version." (SemVer 2.0.0, para. 9)
Breaking changes from an RC isn't flushing semver down the toilet, its fairly explicitly permitted in the semver spec.
> If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.
No, if anywhere before the 2.0 release, including in any prerelease version in the 2.0 line (even an RC) you discover the need for a breaking change, that's fine per SemVer, and the major release that comes out of resolving those issues will still be 2.0.
If you have a bunch of active, unmerged, and API-breaking branches where you're not sure which one is going to make it into the release, don't call it a release candidate because you're planning to change the API. (I don't know whether this was the case with Angular, I just assume it after reading the rant.)
I seriously do not understand what your expectation was.