9 ms·

Why Learning Angular 2 Was Excruciating

204 points by MilnerRoute 10y ago

adrianpike 10y ago
I, too, would probably have a bad time if I was trying to learn a framework as it was being built.
- lghh 10y ago
  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.
  - adrianpike 10y ago
    Yep, I've been burned by that many times. Eventually you have to trust in authors' use of semver or other versioning systems, and that _too_ has bitten me poorly. 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.
    - fixermark 10y ago
      This wouldn't be a problem if people recognized that every version they release into the wild ends up used by someone, and backwards-breaking changes should be weighted appropriately. 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?
  - vertex-four 10y ago
    On the other hand, frameworks like Ember are still chugging along quite happily, and swallowing up any actually good ideas the rest of the community has. For example, isomorphic apps spawned "fastboot", where with one plugin you can generate an isomorphic app from your existing Ember project (with some tweaking), talking to your existing API server.
    - flukus 10y ago
      Knockout is stall my goto, ember seems pretty similar to this. I still don't see what angular react bring to the table that isn't mush simpler with these tools.
morinted 10y ago
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.
- deleted 10y ago
  [deleted]
- charrondev 10y ago
  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.
fabian2k 10y ago
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.
- fixermark 10y ago
  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."
  - ygra 10y ago
    It tends to imply that the API is stable, though. RCs tend to get a few bug fixes and other polishing, but not complete API overhauls.
  - fabian2k 10y ago
    The old definition I learned is that it is a version that you think could be released, unless any major bugs appear that you don't know about yet. It's not something where you would expect major API changes. But those definitions have become much more fluid, and it's hard to find out which definitions everyone is using.
  - kevindong 10y ago
    To me personally, "release candidate" implies "almost ready". After all, it is a candidate for release. In other words, it's released to the public for some final testing and bug fixes with no chance of additional features, API changes, etc. between the RC and the final release.
  - tomnipotent 10y ago
    RC absolutely means non-breaking API changes. Bug fixes yes, but the API will be stable.
lemmsjid 10y ago
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.
- kelvin0 10y ago
  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!
  - Udik 10y ago
    You'll certainly have a hard time if you think you can use any javascript framework without knowing javascript itself. Not understanding how 'this' works is like not understanding how classes work in an oo language, and no framework will ever hide that from you.
    - kelvin0 10y ago
      Although what you mention seems obvious, you have to remember that is quite easy nowadays to cobble up some functionality with minimal knowledge by applying ready-made 'recipes' and following the ton of tutorials available in any language/framework (especially as an experienced programmer). The gotchas become painful when you start to dig through without prior knowledge of the nuts and bolts for debugging/profiling/scaling your application. 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.
jbigelow76 10y ago
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.
stevebmark 10y ago
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
- aarpmcgee 10y ago
  Ember shares this problem, imo.
- nichochar 10y ago
  "tiny" nope.
  - mythz 10y ago
    The surface area you have to learn to be useful in React is tiny, much so compared with Angular2.
  - brentvatne 10y ago
    import React from 'react'; import ReactDOM from 'react-dom'; 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
    - alexbecker 10y ago
      I believe they are complaining about the ~150kb minified filesize, rather than the API surface area.
      - barryhoodlum 10y ago
        It's under 40kb gzipped. If that's a sizeable percentage of your total JS code, you probably didn't need React in the first place.
JohnnyConatus 10y ago
TL;DR - developer learns the meaning of Release Candidate or rather...does not: "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.)
- geldan 10y ago
  You do so in a derogatory manner, but you bring up a decent point. This doesn't really seem to be a JavaScript issue so much as an open source issue.
  - collyw 10y ago
    Using libraries in Perl and Python, they are generally a lot more finished that JavaScript in my experience.
- BurningFrog 10y ago
  Yeah, but a Release Candidate should be very close to what is finally released.
- olavgg 10y ago
  A release candidate is NOT supposed to have breaking changes.... its a friggin "release candidate". 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.
robin_reala 10y ago
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.
- mkozlows 10y ago
  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.
  - nanny 10y ago
    A to-do list would've been a better choice. It's the classic choice for working with SPA frameworks. I thought the same thing as your parent's commenter when I read the word "blog".
    - bicknergseng 10y ago
      To be honest, TodoMVC is the idea-that-needs-to-die™ for SPAs. IMO, if all the framework needs to be able to do is described by TodoMVC, you probably don't need a framework at all. It probably takes way less time to write a todolist in a vanilla language than to learn an entire application framework to build it.
      - barryhoodlum 10y ago
        And you can write a simple and clean TODO app in any framework. You really need to see how it manages complexity to evaluate it properly.
- Marazan 10y ago
  I felt the Post suggested an entire blogging platform.
- goatlover 10y ago
andrewclunn 10y ago
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.
- mrits 10y ago
  I liked Angular 1. It only took a few days to get the hang of it. If Angular 2 or React are really the future of front end then I'm not going to go back. I'm happy doing some backend dev in Go right now. After I finally figured out all the parts of modern front end development I was already sick of it all.
  - Ygg2 10y ago
    I hate Angular and how it makes simple code hard to debug. Not to mention stupid behavior, like Angular app behavior depend on order of components clicked.
plexicle 10y ago
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. Am I missing something obvious?
- WalterSear 10y ago
  Unfinished? How about never finished. >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/ http://juristr.com/blog/2016/09/ng2-released/
  - plexicle 10y ago
    I don't think the idea of "planned" breaking changes every 6 months to be such a bad thing. A major release twice a year that you can upgrade to when you're good and ready. 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.
    - WalterSear 10y ago
      This release cycle is fine so long as you don't rely on anything but Angular 2. 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.
      - seangrogg 10y ago
georgefrick 10y ago
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.
ausjke 10y ago
I have been wondering why a one-person project like vue.js seems to be saner than the big guns such as angularjs and even react-ecosystem? I have been trying all three recently back and forth and now leaning back to vuejs while waiting for its 2.0 release.
- zzguy 10y ago
  Linux was started by one dude. Good software is not dependent on the amount of developers. In fact, in my experience, more cooks in the kitchen just causes more fires.
- rmason 10y ago
  I was an Angular fanboy but one look at version 2 had me reconsidering. I was introduced to Vue at a local JS developers meeting. 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.
Zyst 10y ago
I was reading and stopped half way, it really comes across as disingenuous when you yourself picked an ecosystem that wasn't stable, then the main complaint in the article was about the lack of stability and how the JavaScript ecosystem "Sure is crazy!". I seriously do not understand what your expectation was.
dkarapetyan 10y ago
I'm just gonna leave this here: http://aurelia.io/ http://aurelia.io/. Aurelia is truly a professional operation.
- DigitalSea 10y ago
  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.
  - adamnemecek 10y ago
    What do you mean by "greentea oriented framework"?
    - stickfigure 10y ago
      Greentea is the codename of the internal CRM application at Google that spawned Angular.
- y-c-o-m-b 10y ago
  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.
jkkramer 10y ago
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.
- danso 10y ago
  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/ https://changelog.com/211/ Really drove home the concept that open-source requires significant thinking and discipline when a library becomes heavily used.
  - Bahamut 10y ago
    That's not any different from how Google uses Angular - Google runs off of HEAD on master, in 1 & 2
    - mewm 10y ago
      Can you enlighten me where Google uses Angular in their own apps?
janfoeh 10y ago
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. Bah.
- lmkg 10y ago
  > 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).
SwellJoe 10y ago
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.
- fernandopj 10y ago
  IMHO the Node/npm ecosystem is far more stable than Angular 1&2/bower. 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.
  - flukus 10y ago
    > IMHO the Node/npm ecosystem is far more stable than Angular 1&2/bower. 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.
resmote 10y ago
jQuery Mobile got it right. You can have a powerful, RWD site and barely have to muck with the JavaScript nightmare.
deleted 10y ago
[deleted]
heisenbit 10y ago
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.
crispyambulance 10y ago
Honestly, what framework (web or otherwise) has ever NOT been a complete CF to get started with-- especially when one is "winging-it" by themselves doing new things using new tools? How much frustration is "normal"? How much "confusion" is normal? I say A LOT of both.
kindlep 10y ago
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 :)
wstrange 10y ago
I'd urge folks to give Angular Dart a try. It avoids much of the pain of Javascript and Javascript tooling.
carapace 10y ago
"2.0.0-alpha.8–2"
seangrogg 10y ago
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.
deleted 10y ago
[deleted]
shitgoose 10y ago
now you understand how some of us feel about Java... ironically, JS is just a natural evolution of Java, taken to a logical conclusion, so to speak.
- aikah 10y ago
  You forgot an important difference between JS and Java : the tooling is inferior. Sure you can use Typescript which makes thing a little bit better, but good luck with out dated type definitions or libraries that do not have type definitions, good luck with templates can't be validated ( forgot some directive ? misspelled a component name ? too bad you're fucked ... ). Java is verbose but there is a fairly large number of tools and IDE that make programming painless. JS on the other hand, good luck maintaining those 1 million LOC codebases ...
  - shitgoose 10y ago
    this is all true, but i think the problem of JS is not the lack of generics and types, but the mindset - an honest conviction that one should pile up one layer of code on top of another like there is no tomorrow. this is the common trait between Java and JS developers. the sheer complexity of the system is the problem, not tooling. old farts like me think that complexity is bad and we try to avoid it at all cost. young generation thinks that complexity is good and try to increase it at every opportunity they have.
iLemming 10y ago
keep calm and learn Clojurescript. it will make you happy, I guarantee it.
DeAndre222 10y ago
Contact codebake247@cyberservices.com for any type of hacking /database services we offer diffrent services on different range of hacking issues and also helps to retrieve accounts that have been taken by hackers or message at +1 480 439 6115
oferzelig 10y ago
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: https://news.ycombinator.com/item?id=12529981 https://news.ycombinator.com/item?id=12529981
Dorisb85 10y ago
hi, am Doris, i had my friend help me hack my ex's email, facebook, whatsapp,and his phone cause i suspected he was cheating. all he asked for was a his phone number. he's email is (cyberlord7714@gmail.com)..IF u need help tell him Doris, referred you to him and he'll help. Am sure his going to help you do it, good luck

204 points by MilnerRoute 10y ago

adrianpike 10y ago

I, too, would probably have a bad time if I was trying to learn a framework as it was being built.

lghh 10y ago
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.
- adrianpike 10y ago
  Yep, I've been burned by that many times. Eventually you have to trust in authors' use of semver or other versioning systems, and that _too_ has bitten me poorly. 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.
  - fixermark 10y ago
    This wouldn't be a problem if people recognized that every version they release into the wild ends up used by someone, and backwards-breaking changes should be weighted appropriately. 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?
- vertex-four 10y ago
  On the other hand, frameworks like Ember are still chugging along quite happily, and swallowing up any actually good ideas the rest of the community has. For example, isomorphic apps spawned "fastboot", where with one plugin you can generate an isomorphic app from your existing Ember project (with some tweaking), talking to your existing API server.
  - flukus 10y ago
    Knockout is stall my goto, ember seems pretty similar to this. I still don't see what angular react bring to the table that isn't mush simpler with these tools.

morinted 10y ago

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.

deleted 10y ago
[deleted]
charrondev 10y ago
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.

fabian2k 10y ago

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.

fixermark 10y ago
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."
- ygra 10y ago
  It tends to imply that the API is stable, though. RCs tend to get a few bug fixes and other polishing, but not complete API overhauls.
- fabian2k 10y ago
  The old definition I learned is that it is a version that you think could be released, unless any major bugs appear that you don't know about yet. It's not something where you would expect major API changes. But those definitions have become much more fluid, and it's hard to find out which definitions everyone is using.
- kevindong 10y ago
  To me personally, "release candidate" implies "almost ready". After all, it is a candidate for release. In other words, it's released to the public for some final testing and bug fixes with no chance of additional features, API changes, etc. between the RC and the final release.
- tomnipotent 10y ago
  RC absolutely means non-breaking API changes. Bug fixes yes, but the API will be stable.

lemmsjid 10y ago

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.

kelvin0 10y ago
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!
- Udik 10y ago
  You'll certainly have a hard time if you think you can use any javascript framework without knowing javascript itself. Not understanding how 'this' works is like not understanding how classes work in an oo language, and no framework will ever hide that from you.
  - kelvin0 10y ago
    Although what you mention seems obvious, you have to remember that is quite easy nowadays to cobble up some functionality with minimal knowledge by applying ready-made 'recipes' and following the ton of tutorials available in any language/framework (especially as an experienced programmer). The gotchas become painful when you start to dig through without prior knowledge of the nuts and bolts for debugging/profiling/scaling your application. 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.

jbigelow76 10y ago

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.

stevebmark 10y ago

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

aarpmcgee 10y ago
Ember shares this problem, imo.
nichochar 10y ago
"tiny" nope.
- mythz 10y ago
  The surface area you have to learn to be useful in React is tiny, much so compared with Angular2.
- brentvatne 10y ago
  import React from 'react'; import ReactDOM from 'react-dom'; 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
  - alexbecker 10y ago
    I believe they are complaining about the ~150kb minified filesize, rather than the API surface area.
    - barryhoodlum 10y ago
      It's under 40kb gzipped. If that's a sizeable percentage of your total JS code, you probably didn't need React in the first place.

JohnnyConatus 10y ago

TL;DR - developer learns the meaning of Release Candidate or rather...does not: "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.)

geldan 10y ago
You do so in a derogatory manner, but you bring up a decent point. This doesn't really seem to be a JavaScript issue so much as an open source issue.
- collyw 10y ago
  Using libraries in Perl and Python, they are generally a lot more finished that JavaScript in my experience.
BurningFrog 10y ago
Yeah, but a Release Candidate should be very close to what is finally released.
olavgg 10y ago
A release candidate is NOT supposed to have breaking changes.... its a friggin "release candidate". 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.

robin_reala 10y ago

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.

mkozlows 10y ago
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.
- nanny 10y ago
  A to-do list would've been a better choice. It's the classic choice for working with SPA frameworks. I thought the same thing as your parent's commenter when I read the word "blog".
  - bicknergseng 10y ago
    To be honest, TodoMVC is the idea-that-needs-to-die™ for SPAs. IMO, if all the framework needs to be able to do is described by TodoMVC, you probably don't need a framework at all. It probably takes way less time to write a todolist in a vanilla language than to learn an entire application framework to build it.
    - barryhoodlum 10y ago
      And you can write a simple and clean TODO app in any framework. You really need to see how it manages complexity to evaluate it properly.
Marazan 10y ago
I felt the Post suggested an entire blogging platform.
goatlover 10y ago

andrewclunn 10y ago

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.

mrits 10y ago
I liked Angular 1. It only took a few days to get the hang of it. If Angular 2 or React are really the future of front end then I'm not going to go back. I'm happy doing some backend dev in Go right now. After I finally figured out all the parts of modern front end development I was already sick of it all.
- Ygg2 10y ago
  I hate Angular and how it makes simple code hard to debug. Not to mention stupid behavior, like Angular app behavior depend on order of components clicked.

plexicle 10y ago

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. Am I missing something obvious?

WalterSear 10y ago
Unfinished? How about never finished. >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/ http://juristr.com/blog/2016/09/ng2-released/
- plexicle 10y ago
  I don't think the idea of "planned" breaking changes every 6 months to be such a bad thing. A major release twice a year that you can upgrade to when you're good and ready. 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.
  - WalterSear 10y ago
    This release cycle is fine so long as you don't rely on anything but Angular 2. 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.
    - seangrogg 10y ago

georgefrick 10y ago

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.

ausjke 10y ago

I have been wondering why a one-person project like vue.js seems to be saner than the big guns such as angularjs and even react-ecosystem? I have been trying all three recently back and forth and now leaning back to vuejs while waiting for its 2.0 release.

zzguy 10y ago
Linux was started by one dude. Good software is not dependent on the amount of developers. In fact, in my experience, more cooks in the kitchen just causes more fires.
rmason 10y ago
I was an Angular fanboy but one look at version 2 had me reconsidering. I was introduced to Vue at a local JS developers meeting. 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.

Zyst 10y ago

I was reading and stopped half way, it really comes across as disingenuous when you yourself picked an ecosystem that wasn't stable, then the main complaint in the article was about the lack of stability and how the JavaScript ecosystem "Sure is crazy!". I seriously do not understand what your expectation was.

dkarapetyan 10y ago

I'm just gonna leave this here: http://aurelia.io/ http://aurelia.io/. Aurelia is truly a professional operation.

DigitalSea 10y ago
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.
- adamnemecek 10y ago
  What do you mean by "greentea oriented framework"?
  - stickfigure 10y ago
    Greentea is the codename of the internal CRM application at Google that spawned Angular.
y-c-o-m-b 10y ago
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.

jkkramer 10y ago

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.

danso 10y ago
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/ https://changelog.com/211/ Really drove home the concept that open-source requires significant thinking and discipline when a library becomes heavily used.
- Bahamut 10y ago
  That's not any different from how Google uses Angular - Google runs off of HEAD on master, in 1 & 2
  - mewm 10y ago
    Can you enlighten me where Google uses Angular in their own apps?

janfoeh 10y ago

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. Bah.

lmkg 10y ago
> 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).

SwellJoe 10y ago

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.

fernandopj 10y ago
IMHO the Node/npm ecosystem is far more stable than Angular 1&2/bower. 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.
- flukus 10y ago
  > IMHO the Node/npm ecosystem is far more stable than Angular 1&2/bower. 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.

resmote 10y ago

jQuery Mobile got it right. You can have a powerful, RWD site and barely have to muck with the JavaScript nightmare.

deleted 10y ago

[deleted]

heisenbit 10y ago

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.

crispyambulance 10y ago

Honestly, what framework (web or otherwise) has ever NOT been a complete CF to get started with-- especially when one is "winging-it" by themselves doing new things using new tools? How much frustration is "normal"? How much "confusion" is normal? I say A LOT of both.

kindlep 10y ago

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 :)

wstrange 10y ago

I'd urge folks to give Angular Dart a try. It avoids much of the pain of Javascript and Javascript tooling.

carapace 10y ago

"2.0.0-alpha.8–2"

seangrogg 10y ago

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.

deleted 10y ago

[deleted]

shitgoose 10y ago

now you understand how some of us feel about Java... ironically, JS is just a natural evolution of Java, taken to a logical conclusion, so to speak.

aikah 10y ago
You forgot an important difference between JS and Java : the tooling is inferior. Sure you can use Typescript which makes thing a little bit better, but good luck with out dated type definitions or libraries that do not have type definitions, good luck with templates can't be validated ( forgot some directive ? misspelled a component name ? too bad you're fucked ... ). Java is verbose but there is a fairly large number of tools and IDE that make programming painless. JS on the other hand, good luck maintaining those 1 million LOC codebases ...
- shitgoose 10y ago
  this is all true, but i think the problem of JS is not the lack of generics and types, but the mindset - an honest conviction that one should pile up one layer of code on top of another like there is no tomorrow. this is the common trait between Java and JS developers. the sheer complexity of the system is the problem, not tooling. old farts like me think that complexity is bad and we try to avoid it at all cost. young generation thinks that complexity is good and try to increase it at every opportunity they have.

iLemming 10y ago

keep calm and learn Clojurescript. it will make you happy, I guarantee it.

DeAndre222 10y ago

Contact codebake247@cyberservices.com for any type of hacking /database services we offer diffrent services on different range of hacking issues and also helps to retrieve accounts that have been taken by hackers or message at +1 480 439 6115

oferzelig 10y ago

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: https://news.ycombinator.com/item?id=12529981 https://news.ycombinator.com/item?id=12529981

Dorisb85 10y ago

hi, am Doris, i had my friend help me hack my ex's email, facebook, whatsapp,and his phone cause i suspected he was cheating. all he asked for was a his phone number. he's email is (cyberlord7714@gmail.com)..IF u need help tell him Doris, referred you to him and he'll help. Am sure his going to help you do it, good luck