I've said it before here and I'll say it again: the JS ecosystem is moving in the wrong direction.
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.
I get where you're coming from but your comment boils down in favor of unoptimized and insecure code. And I can't agree with that.
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.
> 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.
I assure you, the same is definitely true of VBA.
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).
It's interesting to contrast how Google and Facebook both approach open source for the web.
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.
Google tends to release code and promote it without really using it much internally first.
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.
Except for the tons of counterexamples at Google...
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.
> Google tends to release code and promote it without
> really using it much internally first.
Is this actually true? My understanding (from watching many AngularJS presentations) is that Angular was developed with input from many teams at Google.
The company is not at risk. Their open source work reflects that.
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?
This reminds me of the excellent episode of Changelog in which Facebook's head of open source discussed the logistics of managing React so that the public version is exactly the same as the version used by Facebook itself: https://changelog.com/211/
Really drove home the concept that open-source requires significant thinking and discipline when a library becomes heavily used.
Your first foray into web development and you picked a large, unfinished (it wasn't final) framework to learn with? Then you are complaining that there were breaking changes you had to deal with?
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.
>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.
He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake. A release candidate is a "release candidate", that is to say "we're pretty sure we could release this whole thing right now, but we want to send it out to the community to make sure there are no catastrophic bugs we haven't noticed". In other words feature-complete, and with most of the kinks ironed out.
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.
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.
Unfinished because they essentially announced Angular 2 as the "we got the first so wrong we're throwing away huge chunks". It literally got announced with gravestone images and tolling bells for various features. As web devs we know this.
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.
To me this is still why React feels like the first front end UI framework that got it "right." It stays close to vanilla Javascript. There's a tiny API surface area to learn, and the rest is vanilla Javascript classes and functions. Angular's API, and apparently Angular 2.0's API, is still large, and strays far from vanilla Javascript
I find it hard to take this article seriously when it's about issues with a framework:
* 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.
I've found that learning new technologies from first principles is better than starting with frameworks, unless you're willing to put up with a lot of ambiguity. For example with Javascript I'd start with basic manipulations (e.g. get to know the prototype model, the debuggers, the DOM, etc.), work up to a make-life-easier library like JQuery, then try a framework. It may depend on your learning style, of course.
This is fundamentally because every Javascript tool is an incredibly leaky abstraction.
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 love that approach myself; methodically learning the building blocks is the only way to get solid understanding.
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.
This is exactly the path I've taken. I figured if I start out with <ShineyNewJSFrameworkMVC> right off the bat, and not understand the foundation, I'd be screwed in the long run. My reasoning is that once I grasp JS's quirks/ins/outs (I'm looking at you 'this'), well I'd be ready to see the light and better choose a framework. So far, I think ReactJS nailed it, but keep in mind I am fairly new to Web Dev (coming from PC/Console/C++ world) so YMMV.
Also, I would like to thank the good folks at Twitter for Bootstrap, I don't know how my frontend would look like without it!
Yeah, I thought something similar as I was reading it - I don't think necessarily that the author's problem was in trying to learn Angular, but in trying to learn Angular from the "5-minute quick start guide" that's posted on the web site. That's not realistic, even if you're already an expert in Javascript, jQuery, CSS, HTML, Node.js, npm and even Angular 1!
Sorry, but sometimes I feel like the only sane person in the madhouse. It’s a blog! It’s literally just an index page and some display pages! Why could that possibly need 100s Kb of JS to run it? Of course you’re going to have trouble, you’ve picked a JCB to do a screwdriver’s job.
The point is to use the blog as an example to learn the tech, typically. Picking a familiar, not-too-big problem to solve is a good way to understand how new tech works.
On a related note -- is there a StackOverflow-like site where you can ask questions about basic app architecture so you don't get stuck on a shitty ecosystem?
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.
As someone who has been using Aurelia for over 12 months now, I am happy to see someone post this. A great framework that hasn't really had any major breaking changes, even when it was alpha, then beta and release candidate. Keeping it up-to-date has been no effort at all and I have been building with it since it was basically announced.
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.
I've used both Aurelia and Angular 2. I enjoy Angular 2 very much despite its feistiness and the community around it is huge, but Aurelia just seems cleaner, easier to use and lightweight. If I were to pick one, it would be Aurelia, but I would never suggest someone abandon an established Angular 2 project in favor of Aurelia.
I've pretty much had the same experience with the JavaScript back end. The npm ecosystem is overwhelming, on several fronts. In many ways, it's great: 70,000+ libraries available with one command. But, my gods...grokking how they all interact, getting a stack of several libraries to work together, and rolling that stack into production, are astronomically more complicated than any other language/platform I've ever used. It makes the Java world seem simple.
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.
Honestly, upgrading npm modules is never fun. This person is trying to learn the language at the same time -- you just can't expect that to work. You want to shrinkwrap / freeze your dependencies as soon as you can, and upgrade when it's clear that you are missing out and the effort to upgrade is worth the work that it takes to update.
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.
Upgrading dependencies can be a total pain in the ass, and in the end is why I've been so frustrated with TypeScript. My solution in the end was to just ignore typing for any 3rd party libraries that don't have them to begin with. As nice as a d.ts file, dealing with all the type definitions that need updating along with all the issues with updated the dependencies in the first place was just too much.
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 never used Angular 2, but that sounds like the biggest issue is a release candidate that should have been called a beta or alpha release.
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.
Release candidate to me means "We think this software is pretty much done. Does anybody in the community think otherwise?". You don't expect new features or breaking changes. That wasn't what happened during angular2 development.
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.
In general, if I understand correctly, "Release candidate" implies "unstable." The emphasis is on "Candidate," not "Release," i.e. "This bundle could end up being the final version, but it probably won't."
Exactly this. I also just started using Angular 2. Unlike the OP I have a lot of web development experience, but this is the first time I've used Angular or Typescript. While I really like Angular and am really enjoying working with it, it is pretty exasperating to have loads of breaking changes between release candidates. That's not what release candidates are for. Forms are the worst. You're not supposed to introduce, deprecate and then remove whole modules between release candidates. There are even major, breaking changes between the final release candidate and the release version 2.0.0.
That's sort of the problem that the article was addressing. By the time things have been built, they are old news to the JS community - or at least those that you see on HN, Medium, blogs, etc. If you mention learning Angular 1 anywhere you get shouted at that it's old and should not be used and to instead look at Angular 2 and React. By the time those are established, it'll be on to something else.
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 hear the author's pain. So much churn as I attempted to keep pace with RC changes. I'm sticking with NG2 cause for the rare times I was writing app code instead of fighting with NPM I enjoyed the developer experience...
...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 think as you yourself have said, it's the pain that comes with using something that's currently in alpha/beta/etc. True, Google's approach is different, but the end product is something that has gotten so much input from the wider community, as apposed to how FB does it. Now I'm not saying one is better than the other. I'm just saying it's the price for depending and using some thing thats still literally being worked on. As far as I know, thats pretty much a wavier on ease of use.
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 :)
The best thing about Angular 2 is that Angular 1 is now stable. I say this as a web developer currently coding apps in Angular 1 for production. This is gonna be a python 3 moment all over again.
NPM and semantic versioning allows to manage all the dependencies. However the fine granular nature of js packages, the large number of dependencies, lack of governance and possibly discipline result in an experience that is very different from the Java environment.
I'm going to cry foul.
Lines like "has a umd now. whatever a umd is.... "
Stack Overflow copy pasta developers. If you're an associate level developer; the project should be setup for you. If you are above that, you should understand some of the internals and build tools to the point where you are comfortable wiring them.
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.
I don't get how come this item has received (at the time of this writing) 204 upvotes, whereas an earlier item on the very same blog post only received 6:
[+] [-] janfoeh|9 years ago|reply
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.
[+] [-] Andrex|9 years ago|reply
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.
[+] [-] lmkg|9 years ago|reply
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).
[+] [-] jkkramer|9 years ago|reply
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.
[+] [-] jbigelow76|9 years ago|reply
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...
[+] [-] argonaut|9 years ago|reply
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.
[+] [-] jt2190|9 years ago|reply
(edit: Angular was first used on an internal app at Googel: https://www.youtube.com/watch?v=r1A1VR0ibIQ&feature=youtu.be...)
[+] [-] automatwon|9 years ago|reply
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?
[+] [-] danso|9 years ago|reply
Really drove home the concept that open-source requires significant thinking and discipline when a library becomes heavily used.
[+] [-] plexicle|9 years ago|reply
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?
[+] [-] WalterSear|9 years ago|reply
>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.
http://juristr.com/blog/2016/09/ng2-released/
[+] [-] OskarS|9 years ago|reply
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.
[+] [-] mooseburger|9 years ago|reply
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.
[+] [-] cmdkeen|9 years ago|reply
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.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] stevebmark|9 years ago|reply
[+] [-] seangrogg|9 years ago|reply
* 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.
[+] [-] lemmsjid|9 years ago|reply
[+] [-] meredydd|9 years ago|reply
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).
[+] [-] copperx|9 years ago|reply
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.
[+] [-] kelvin0|9 years ago|reply
[+] [-] clifanatic|9 years ago|reply
[+] [-] robin_reala|9 years ago|reply
[+] [-] mkozlows|9 years ago|reply
[+] [-] copperx|9 years ago|reply
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.
[+] [-] randomsofr|9 years ago|reply
[+] [-] Marazan|9 years ago|reply
[+] [-] goatlover|9 years ago|reply
[+] [-] dkarapetyan|9 years ago|reply
[+] [-] DigitalSea|9 years ago|reply
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.
[+] [-] y-c-o-m-b|9 years ago|reply
[+] [-] SwellJoe|9 years ago|reply
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.
[+] [-] morinted|9 years ago|reply
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.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] charrondev|9 years ago|reply
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.
[+] [-] fabian2k|9 years ago|reply
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.
[+] [-] dermotbrennan|9 years ago|reply
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.
[+] [-] fixermark|9 years ago|reply
[+] [-] ascorbic|9 years ago|reply
[+] [-] adrianpike|9 years ago|reply
[+] [-] lghh|9 years ago|reply
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.
[+] [-] jbigelow76|9 years ago|reply
...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.
[+] [-] ausjke|9 years ago|reply
I have been trying all three recently back and forth and now leaning back to vuejs while waiting for its 2.0 release.
[+] [-] kindlep|9 years ago|reply
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 :)
[+] [-] andrewclunn|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] heisenbit|9 years ago|reply
[+] [-] georgefrick|9 years ago|reply
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.
[+] [-] oferzelig|9 years ago|reply
https://news.ycombinator.com/item?id=12529981