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.
I appreciate your position, I really do. It's not like I am clear-cut on this myself, even if my frustration makes it sounds like I am. I appreciate that the language, the platform and the web itself needs to evolve.
But I object to the argument that people can just continue to do their thing, because people in that position are overwhelmingly dependent on the ecosystem. Guidance, libraries, tools. And that ecosystem has left them behind, or is at least very far along that road.
Of course reasonable people might disagree, but to me, that people might write unoptimized (or just plain horrible) code is a very, very small price to pay for the empowerment the web delivers to them. And as to "insecure" - Jane and Joe want to show a slideshow of their hand-baked Macarons, not write banking auth systems. If they manage to open up a security risk, the attack surface is usually rather small, and the fault lies with the platform.
No, I stand by this: Javascript was our generations Hypercard, on steroids, and we've almost completely squandered its potential.
It's certainly an interesting conundrum, and I agree that eventually without ecosystem support Alice and Bob might find things a little tough.
However, it's important to realize that the way the web is moving is to not only benefit the working professionals being paid to write it, but also the consumers who experience it.
Why do we have minifiers and transpilers and modules and font icons? Why do we aim for one script tag instead of 50?
Because for a consumer, the web sucked (and still sucks to an extent, but less so with AMP and offline APIs.) For "prosumers" like Alice and Bob, it was a buffet, but for people browing their web pages it sucked. It was slow and unresponsive and that's even before the rise of the mobile web.
And whether the ecosystem leaves them behind or not, Alice and Bob can always create a new slideshow.js file on any given platform they want.
The web is moving towards being better for professionals and consumers, and I agree that those in the middle might lose out a little, but they are very small peanuts. I'd rather optimize for the next billion users in Africa, India and beyond, most of whom are on sub-2G speeds, than for the script kiddies making an easy living pilfering jQuery widgets without learning the platform.
I miss the days of the plain-old html web. It might have been ugly, and there might have been marquees and blink tags, and under construction signs, and webrings and webmasters, but it loaded over my 56k modem, nobody was screwing with my back button, or messing up scrolling, or popping modals in my face, or pestering me with anti-anti-anti-ad-blocking nag modals and interstitials.
There are embedded YouTube videos, MP3s, and code samples to illustrate what he's writing about. He's implemented their ideas using the Web Audio API and you can run the code from within the page and listen to the music being generated in real-time. It's a real testament to how great the web can be.
I think being able to do things like that is worth all the annoying parts of the modern web, in the end. For the developer and the end user. I wouldn't want to go back to the old way. I think it's easy to focus on the annoying parts and take the good parts for granted.
True. But users don't care. Not only that, such ease had only created more noise and less expertise. Piss all you want about MS and Apple back in the day but they understood quality control. Today? Ha. We just have lower expectations. We accept shite because we have no other choice.
Furthermore, free isn't free when my privacy is sold and/or my eye balls are subjected to even more ads. This is progress? No fucking way.
> Piss all you want about MS and Apple back in the day but they understood quality control
I don't know what you are on about as there weren't any app stores controlled by Apple or MS. Anyone was able to release crap software on floppy disks or BBS, and they did.
Which platforms don't have good package management? Linux has, if anything, too many. Windows has chocolatey. Apple has homebrew. Writing portable applications can be done in a variety of ways and packaged for each platform.
Windows might have chocolatey, one among a small number package managers for Windows (including the bleh Windows 10 Store), but not being baked into the OS distribution means the average user isn't going to install it.
Users want what's already in the Start menu/page, not something they have to go to a site, copy some (as far as they know) random text, paste it into a power shell, and then hope it works. You effectively need a package manager to install the package manager.
That might be ok for your power users, but the average person what wants to install GIMP because he's been told by his mate down the pub that it's "like a free Photoshop", would rather go to the GIMP site and download it, he won't even know about chocolatey because he's so used to using Windows without a package manager that he'll just Google "GIMP" and hope the fist link is the right one.
Windows missed the boat on package managers and the Windows 10 Store definitely does not make it any easier.
the advance of minifies and transpilers and modules doesnt seem to increase page performance. one of the effect of it being so efficient to minify and transpile is that large imports and frameworks are easier to use, and that boosts the total JS lines of code, making the JS parsing take a long time, and the page performance get "janky"
Mediocrity expands to fill the space and time available.
Mediocre solutions are fixed with an endless array of tools. Learning tools takes time. And that's just to break even. And around we go again.
Can we really say the average web experience is better than the average of 10 or just 5 years ago? (Hint: Nope.) Find someone who is less frustrated with technology and you'll find someone who has given up on technology.
jQuery still exists. IMO, the ecosystem has just moved towards rich-client front end applications. There was no good tool/framework for that and people started fulfilling that need. Of course you could write like you said "unoptimized (or just plain horrible) code" which in an actual application is huge price to pay. I think it all boils down to being able to use the right tool for the job. I wouldn't advise using React or Angular to show static content e.g an splash page.
The catch is that using NPM and CommonJS modules for front end packages makes it so that tools like Rollup and the Closure compiler can't do the kinds of optimizations they are capable of. The code we ship is doing a lot of runtime dependency resolution that could be done at compile time if we constructed our modules properly.
I think that many of the front end tools we use now result in an optimized developer workflow, but usually not optimized code.
> 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).
Sure, Mr. Bakery, do everything in jQuery in a <script> tag. I'd even argue that's probably the correct approach.
But I don't work for a bakery -- I work for a large company with a complex tech stack writing web applications that will have to be maintained by some poor sucker long after I move on. Tools like React/Angular, Webpack, and npm allow me to do that in a way I couldn't as little as 3-4 years ago.
I see comments like this in every one of these threads. It's shocking to me how misunderstood web development really is. If the web was meant to be strictly utilitarian we never should have moved off gopher.
> But I don't work for a bakery -- I work for a large company with a complex tech stack writing web applications that will have to be maintained by some poor sucker long after I move on.
Or rewritten because the flavor of the month has changed.
>Tools like React/Angular, Webpack, and npm allow me to do that in a way I couldn't as little as 3-4 years ago.
What exactly couldn't you do 3-4 years ago that you can now?
The big shift has been from managing complexity to avoiding it where possible, encapsulating it when not. In my current favorite webstack, every logical view is abstracted behind an API (which happens to be a React Component). Internally, everything about that component is encapsulated -- the internal implementation, the sub-components, even the CSS thanks to CSS Modules. In fact, if I really had a reason to write a specific component in Angular or jQuery I would be able to: it's easy to embed non-React code inside React, and as long as it exposes a top-level React Component I'm hunky dory. I refer to React because that's my library of choice -- but you can say similar things about Angular and Aurelia.
This has only been something we've gotten right over the last few years. jQuery trampled all over the DOM, data-binding heavy frameworks like Backbone were impossible to reason about, Closure Library turned your Javascript into Java-flavored spaghetti, Coffeescript was basically Perl, and CSS was global by default. Now React lets me write perfectly performant abstractable code. Redux lets me manage state in a functional, reproducible way. Webpack supports CSS modules which let me write sane styles and code-splitting so I don't need to worry about managing resources. Typescript lets me write code that's safe and easy for others to consume. ES6 modules allow me to actually architect my codebase without shoving everything onto window. And the ringer is I'm not married to any of these technologies -- I can scalp out Redux for another data store, Typescript for Babel, go back to global CSS, etc.
Writing UI code is hard, and I'm not sure why some HN folks assume web developers are ignorant. Web apps are a HUGE hack, and it's funny to me that a forum dedicated to hackers has so many who shun it for that reason. It's not "flavor-of-the-month", it's finally making progress towards a really hard problem in really exciting ways.
Writing UI code is hard, and I'm not sure why some HN folks assume web developers are ignorant.
But it really isn't and the proof is HyperCard from the 1980s. It's only hard because you have made it hard, for no reason that anyone can fathom (apart perhaps from job security).
I'm very curious what kind of web apps you think people are building. HyperCard was great for demoware -- and if you were to try and make it into a real production-ready tool you'd get VBA.
Do you really think everybody -- from Android/iOS to Swing to qt to Web 2.0 -- just had no idea what they were doing?
Sorry, I missed that, I was replying to the parent comment only.
But yes, I do advocate avoiding javascript altogether whenever possible (which is more often than current trends). There were a number of other transpilers too, all of which were a pain and I don't see how typescript is going to improve on that.
I sometimes yearn for the days of the simple script tag that seemingly gave us the world at our fingertips. Especially when I have spent hours trying to get tooling to work alone. The constant updates, deprecation of libraries and tools before they even hit version 1.0, it can be tedious.
Having said that, I think in the case of the direction of Javascript itself: I believe it is going in the right direction. ECMAScript 2015 was a mammoth release that really took Javascript in a nice direction, the smaller ES2016 release adds a few minor features and ES2017 is shaping up to be another monumental release for Javascript. The ecosystem as you mention is really in a confusing state at present.
The only constant in all of this is Javascript. We are living in an era where things are being deprecated before they even hit 1.0. The one part of front-end development heading in the wrong direction is the questionable design choices of frameworks like Angular and React. The only framework I have seen which is abiding by actual web standards is Aurelia. The lack of Aurelia specific concepts means you're not committing to something proprietary you're stuck using, like the case with Angular 2 and ReactJS.
Then you have the elephant in the tooling room: Webpack. People are using it, it is becoming increasingly popular in the front-end space, but it has basically no documentation and it is incredibly confusing. People are using it, without even understanding it or knowing how to use it. Mostly learning from blog posts and StackOverflow. Webpack 2 looks promising, but it probably won't have any documentation either.
It is almost like nobody seems to plan anything, choosing to develop and release off of the cuff. Even when Babel dramatically broke things out and changed the way it works for v6, that was a painful experience for the ecosystem in itself. Then you have System.js, JSPM and other tooling/module loaders breaking things every release.
I don't see browsers dropping ES5 support any time soon, and jQuery isn't going to disappear.
There will still be plenty of opportunity for people to jump in seize great market opportunities using PHP, jQuery, and chewing gum while all of us full-time professionals are here on HN arguing about Angular vs React and whether npm is insane, awesome, or both.
Again, don't get me wrong - when I was writing what was called DHTML almost fifteen years ago, I would have killed for the APIs, capabilities and cross-platform stability we have today. It's a good thing. Lots of shiny.
I simply feel that this is a concern that doesn't get enough attention, certainly not around circles like these that in the end drive the further evolution of development on the web platform. And that we collectively would do well to at least acknowledge the trade-offs we're making in the process.
I feel the same. I've just straight up stopped using frameworks. I refuse to use ES6 or any module which depends on it. No more coffeescript, no SASS. No promises, no templates.
And really, what all of this boils down to is: avoid declarative control structures at all costs. Procedural design by default. There are a handful of situations where I will build a declarative API, but they are rare. I will use libraries, but only if they have a single well defined purpose and are largely procedural.
The result? It's wonderful. All of my code is completely traceable. If something doesn't work, I never have to go read online for an hour, dig around in the source code for random modules trying to understand boot and build processes well enough that I can form a hypothesis about where a bug is. I just start at whatever point my expectation is violated, and work directly back to whatever is broken.
I can always insert a debugger statement, and instantly stop state either in Node or in the browser. The execution path and data handoffs never disappear into a mysterious framework or executable. The code in production is always in . or ./node_modules.
The entire class of headaches so prevalent in Rails/Ember/every other declarative-is-best system are just gone. Granted, I deal with other headaches. I have to really think about how data moves through the system. I can't just add a flag to access data from one end of the system in a totally different part of my app, because there's no magical framework code using light AI to figure out how to marshal data around based on some declarative configuration conditions.
Essentially what I've decided is it's better to sacrifice convenience in order to get inspectability. You lose speed in your initial hacking, but you gain a predictable pace of debugging. Bugs never really stay mysterious longer than 15 minutes or so. I never have those instances where I spend a whole workday scratching my head about framework internals.
I do spend a day scratching my head about how my data should be structured and how it should flow through the system. But that's effort that will continue to pay dividends. It generally leads to better interfaces that require less maintenance. Work that is often continually put off when you have a framework that offers every shortcut that could be sanely crammed into it.
You can still do all of those things you're talking about. In most cases you don't even need jQuery anymore and can just use browser APIs.
Why do you argue about something that clearly doesn't interest you? From a so-called professional: It's perfectly fine to continue doing websites the way you do if that works for you and your client. End of story.
Everything else that confuses you is just the world of software getting bigger, Javascript being used in different places, people trying out things and promoting them, good stuff, bad stuff, you know – like the real world. Imagine knowing every aspect (political, economical, social) of a larger city and you would go crazy as well. Breathe and relax.
Complex frameworks have historically made up for a lack of capabilities, starting with the lack of a component model and composition facilities.
This is changing for the better with web components. Now you'll be able to have just a `<script>` tag and define a component and use it in markup. It'll be even simpler than jQuery, and saner at the same time.
jQuery isn't dead - they're still releasing new versions. You can still do everything you used to be able to. But now you can also do more - you can sensibly modularise your code. Virtual DOMs bring huge performance boosts with very little work.
IMO, the JavaScript ecosystem has matured. Sometimes in weird ways that aren't great, but it's still better to have an irritating package manager than no package manager at all. But there's no price to be paid here - if you don't want to use any of it, you don't have to.
The problem is, it has become popular in our industry to equate new with "quality". So, while you're correct that jQuery isn't dead and in fact is more mature, there are too many who won't use it almost because its mature. Its not the new shiny that it once was. But frameworks like React and Angular are very shiny. Even though, in my opinion, they're quite simply a mess.
I think there is an element of people using things because they are new and shiny, yes. But plenty of people use React and Angular over jQuery because they make 1000x more sense when putting together a large web application with multiple developers contributing to the codebase.
Sure, for larger projects a good, well-thought out and consistent framework is a godsend. No doubt about it that plenty of people make very good use of the frameworks and libraries at our disposal.
But on the other hand I cannot count the number of times I've seen Angular included for a simple contact form with validation on a static site, React to render a single trivial dynamic list or a nice, but basic JS lib that only works in module form via NPM exports.
Sorry if I sound like a fortune cookie, but it's true - if all you've got is a hammer, everything looks like a nail.
Since 2001 or so, I can count on three fingers the number of variable collisions I have experienced in small- to medium scale projects. That I as a newbie now have to understand and manage various module systems in order to embed a lightbox on my site is a huge jump in complexity for a gain that is at best negligible in practice.
And while you and I probably have worked on some higher-complexity use cases, I think we would be kidding ourselves if we assumed that this constitutes the majority of the web.
Because that's not Facebook-scale, it's the dude around your corner selling dishwashers and reparing washing machines, trying to get his inventories's prices from an Excel sheet onto his page with a minimum of fuzz.
And the number of Aurelia users is rapidly rising not only because it's new and shiny and easier to build complex web apps, but also because it's more natural and standards-compliant than frameworks such as Angular. A natural reaction to seeing what's missing or going down the wrong path (as in the case of Angular 2).
It's also a lot less necessary than it was because browser compatibility has improved. Last time I did a mobile web app I seriously considered removing it because it was heavyweight and I was only using a few functions. I didn't, due to time constraints, but I could have.
You can still do the exact horrible thing you're describing.
However, JavaScript now gets used by real programmers for real applications, and has therefore evolved to accomodate for that.
You're saying (incorrectly) that now inexperienced programmers can't put crappy scripts online without knowing what they're doing and hope the thing works. Well, you can still do that, but you can also actually learn the language and build serious stuff.
I can't see how this is the wrong direction for JavaScript.
If it were impossible to trivially build low-function websites, you'd have more impact with your point. As it stands, it comes off more like union guys complaining that hardworking people make them look bad.
Seems to me OP is stating the exact opposite. That the JS ecosystem used to be more egalitarian with a much lower barrier to entry than (ironically) what frameworks like React and Angular provide.
If the OP is stating that it is possible to trivially create low-function websites then I am befuddled. Why complain that what is wanted is achievable?
Or perhaps this is one of those things where people assert that the existence of things they don't want to use is somehow offensive. Still isn't a very helpful point to make.
> Or perhaps this is one of those things where people assert that the existence of things they don't want to use is somehow offensive.
It could be related to the signal-to-noise ratio. If I'm a non-dev looking to throw something together and 98% of the information I find is about some pro-level frameworks, it'll be hard for me to sort through that and find information appropriate to my skill level, level of interest, and needs.
Maybe it's still a net-gain for the world as a whole, but it's certainly a loss for the non-dev. It makes the learning curve (perhaps needlessly, perhaps not) more regressive.
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 does not actually do much with JavaScript. Sure they have gmail, but they put a lot more effort into graceful degradation than most web companies.
Google has larger and more complex JS apps than most other companies on the planet. They do a lot with Javascript besides gmail. Maps, Docs, Photos, G+, are all large Javascript applications. And those are just a few.
These are all separate applications which sit in their own silos. They are individually complicated, but they don't need to fit into some company wide framework.
I think this is an age thing. People who grew up using the web before javascript started destroying it are more likely to accept professional responsibility for progressive enhancement, and Google skews older than many competitors.
> 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.
"with input" != actually using it. There are very few public-facing Google apps/sites that use Angular, whereas a large chunk of the Facebook frontend uses React and their other libraries like Relay. That said, I have no idea if/how Google uses Angular internally, so it might get more use than we see from the outside.
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.
I've been told directly by multiple Angular team members that over 70% of Google apps uses Angular in some fashion.
They have said the usage of Angular off of HEAD of master publicly in the past as well, but I don't recall off the top of my head where they have said this.
Well, this thread definitely shined some new light on the area for my. I was actually under the impression that Angular (at least 1.*) wasn't really used within Google. I guess I'm just that stupid and naive.
Yeah I think that's the key difference: the size of the production apps. Though to be fair, Angular is a much bigger part of the front-end stack than React and not something that would be feasible to retrofit GMail/YouTube/etc. with.
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.
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.
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.
This makes the improper assumption that you're forced to upgrade. The code for Angular 2 will not evaporate when Angular 3 appears - at that point the choice to upgrade to the latest version is just that: a choice. You are free to wait until Angular 4 comes out before you adopt Angular 3 if you want to make sure the ecosystem around it is solidified.
I've been 'forced to upgrade' in the past by issues in dependencies that won't be fixed, with other dependencies not updated yet. It's a sticky wicket.
That said, breaking changes every six months seems to be commonplace in major open source packages. My initial reaction was 'OMG, now they want to repeat the Angular 2 debacle every 6 months?!?', which doesn't seem to be the case.
It sounds odd to me that an app would include packages that have dependencies on a framework. I'm having a hard time picturing an example, can you provide one?
I'd like to point out that React has had breaking changes roughly 6 or less months apart also. This is a red herring of an argument, we see lots of successful libraries make breaking changes that often doing fine.
The scope of the breaking changes matter more, and that story has yet to be told.
> I'd like to point out that React has had breaking changes roughly 6 or less months apart
When? Can you cite an example? Keep in mind that for most breaking changes React typically goes to a deprecation warning for the duration of a major release instead of hard-breaking changes, so in reality you have roughly double the time between truly breaking releases, generally speaking.
Rails introduces some breaking changes now and then. The only troublesome upgrade was when they added the asset pipeline. Was that 3.0 or 3.2? If Angular is adding some features while deprecating others it won't be a big problem. If they break compatibility in a big way every six months, maybe it's not the place to be. High maintenance costs means that it's hard to sell to customers and even for internal projects one should evaluate if it's wise to allocate resources on rewriting the same code again and again. We'll see.
One other project comes to mind that also updates every six months: Ubuntu. Last I checked, their ecosystem was doing fairly well. I wouldn't consider Ubuntu "unfinished" unless we're talking about the state of all software everywhere.
Does Ubuntu ship breaking changes every six months?
Do Ubuntu developers rely on other developers to keep their shared code updated and/or fork their repositories to support both new and old versions of the framework, every six months?
But, of course, Ubuntu also has LTS (Long Term Support) versions for people who don't want to upgrade frequently (you get security patches and the like but otherwise things stay stable for years).
Ok, now try to find at least one framework without breaking changes after initial release. Code should evolve, planned changes is a graceful evolution.
Breaking changes are to be expected. Breaking changes every six months are how you ruin an ecosystem.
React releases every 6 months or so, and puts deprecation warning on anything that is breaking in the next update, so you have a full year between any breaking features, and six months for everyone to update before they land.
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.
He didn't pick up a pre-alpha nightly build of the framework, he used the release candidate for christ's sake
Quoted for emphasis.
Release Candidate means "The API is considered finished and we are stabilizing the code before our final release"
Release Candidate doesn't mean "Beware! Don't you dare to build a real world application with our library since we will be breaking the API on a whim".
If I wanted a dependency to have unpredictable breaking changes every minor version I would pick an Alpha version, not a Release Candidate one.
Although to be fair, in my particular case it was my fault, seeing "Breaking Changes" in the changelog of a Release Candidate was a red flag I decided to ignore.
RCs should IDEALLY not have breaking changes. You can dice it up any way you want, but it wasn't a final build and there were obviously some rough edges.
Angular 2 is final now and they've committed to no more breaking changes until the next major build (at least 6 months away). If s/he started learning with it today, then ~90% of what s/he was complaining about in this post wouldn't have been a thing. That was my only point.
Not that I find the debate particularly productive, but "there will be no breaking changes" doesn't mean "final", it usually means (at most) release candidate. Or even beta. While "it works but we might still introduce breaking changes" is not a release candidate but maybe a technology preview.
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.
It was the TypeScript team that invited the Angular team to build Angular 2 on top of TS (at the time, they were planning their own JS dialect called AtScript), so I would be surprised if they later changed in a way that seriously broke compatibility with Angular 2.
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
Tell me about it! Literally all you need is React.
Oh, plus react-router for routing, I guess. And Redux, obviously. Plus react-router-redux to link them together, and react-router-scroll for scroll history. Also react-intl to handle internationalisation. And react-helmet to do document header stuff. You'll need to use immutable as well, obviously, so you'll need redux-immutable. And redux-saga. Hmm, you'll definitely need a selector library like reselect. Better throw in reactcss too. Gotta get them inline styles going!
Anyway, just those and a couple dozen other libraries and you're good to go. Then once you've set up Flow types, Babel compilation, isomorphism, bundling with hot module reloading in Webpack, linting and testing, you've got a rockin' React app. Easy as that!
I've used React by itself for over a year before I ever reached for anything else you mentioned there. I eventually picked up many of the other things you mentioned too, and they were very useful, but they were very far from being necessary to make use of React, and I probably would've wanted them or something close if I didn't use React.
they may not have been necessary for your projects, but they're absolutely necessary for any real-world production grade apps. Angular is solely targeted in that direction. 90% of the React examples I see when I interview people are handlebars/mustache 2016, and would be better solved with server-side rendering in the first place.
I think OP has made a mistake calling it a framework as it is not a framework, it is a library. People have added more libraries to it. On the contrary, yes Angular is a bonafide kitchen sink framework missing the major advantage of a framework: A STABLE somewhat opinionated stack. You are correct though that making React into a "framework" is a hot mess.
While React is certainly more lightweight in many respects that something like Angular or Ember, I still think it qualifies as a framework.
For me, the primary difference between a library and a framework is the the typical direction of instantiation and calls between your own code and that of the library/framework, and the ownership of the main workflow / event loop. E.g. does it feel like your code uses the 3rd party code, or that the 3rd party code uses yours?
Putting it more concretely, when you code is executed, does the 3rd party code tend to come after it in the stack, or before it?
With a library, you're mostly calling its methods. So, a library is something like jQuery, where you're just making a lot of calls to its methods. Those libraries might do some very complicated things, but they're still just operations that you have launched, and which eventually return control to your code.
With a framework, you're inheriting from framework classes, and conforming to a workflow that the framework controls. For me, that describes React. You write in its JS dialect (jsx), your classes inherit from React.Component, and you hand over control of the rendering workflow to ReactDOM.Render and the virtual DOM.
I agree. React is far too opinionated for me to treat it as just a library. I use it as a framework just as I would use Angular, and it fits the bill. That it can also be used as just a library is a bonus, but doesn't define its identity.
I'd much rather select the libraries and frameworks I want to use than some huge monolithic beast of a framework. Oh did I mention that all the libraries I select in the react echo system are just JS? Not some massively proprietary framework like angular? yeah.
Lmao, this is exactly how I've felt, and why I'm using ordinary js with closures and a bit of jquery for the time being while I get up to speed and figure out wtf is going on.
If what you're trying to accomplish is feasible and maintainable with "ordinary js ... and a bit of jquery" then using a full React+Flux stack like the OP outlined is complete overkill. If someone has experience with those libs and tools then they'll probably use it even for trivial projects. However that does not mean it's prescribed for _everyone_ to use _every time_ they need to write a bit of javascript functionality.
I really wish people would qualify what they're trying to accomplish when they bang on about things being "needlessly complex". Maybe for what they're doing it totally is and they shouldn't be distracted with React, Flux, Webpack, etc. There's nothing wrong with that. However, when taking on a project where these sorts of things are immensely useful, it's nice they exist.
Sure, but tell me what isn't feasible? Ok, I'm not creating photoshop in a browser, but there have been some non-trivial highly interactive apps I've built and they are still modular and serve their purpose well.
I'm not saying we shouldn't get on react - I'm sure in the end it will serve myself and others well, but it's a bit of a headf*ck trying to figure out the whole ecosystem, and how to write a good solid app in it. For anyone that tries to say "but it's only react with x" - No it's not! Not for anyone that cares about the quality of their app, theres a whole heap to learn.
And I am learning, but at the same time I'd rather create a well designed app with the crummy tech I know than a crummy app in something I just haven't figured out yet. Luckily I'm doing my own thing so have that choice.
Eh, it really is not that bad. With just React and a fetch polyfil (to replace jquery's ajax) you can get pretty much the same power as with just jquery.
This will all settle down in a year or two, once we get the most basic features built-in into browsers. Like for example modules + HTTP2 will probably mean no more bundlers or build tools (which is where the vast majority of this craziness is coming from)
Made the switch to HTTP/2. Using push with minified/gzipped/cached assets. Loading all my assets is typically a 6ms affair for all of react, react-dom, redux, custom JS, custom CSS, and additional PWA files. Mind you, dev machine.
... and this is how major diversity spawned in the frontend business the last couple of years... Seriously, though, a lot of companies still gets it on with mediocre frontend developers that still rocks jquery solo. It might be down to down company culture or just an unlucky set of colleagues.
I'm no frontender, but lucky to be in a team that got that sh!t under control, luckily.
This is exactly why I don't buy the argument that frameworks are so much easier to use and learn than languages. I look at the state of JS these days and shake my head in disbelief. When did it get so needlessly complex? More importantly, WHY?!?!
People who aren't doing complex things start using libraries that are designed to manage complex things, even though they don't need them, then complain that they're overcomplicated. Repeat ad nauseam.
That's one of the pros often mentioned about React. In practice, I haven't found it to be true so far. Once you start using React, you'll almost certainly have to use one the Flux implementations. So let's say you use Redux. Suddenly you also have Actions, Reducers and Stores that you have to learn. If you want to use Async Actions (which is very likely in a web application), you'll probably need Redux Thunk, so that's another concept to understand.
Then there's routing, which is not present in the React core, so you'll need a routing library as well. Again your API surface increases.
In the end, if you want to write a larger application with React, you'll often have a similar or even larger API surface than Angular. I can understand that some people prefer the conceptual model of React (with its focus on Components) over that of Angular. The claims about a smaller "API surface" have always felt wrong to me, though.
Absolutely this. While it might be tedious to put those pieces together at first the knowledge that you gain is very transferable to the other app that you build instead of being one-trick pony in angular.
I've been using React for small projects in my personal time, and I haven't needed anything like Flux at all. Maybe you'll need it for complex apps, but React can be used for small ones without that added complication.
I still firmly believe Angular 1 got the right pieces into the framework (directives and services), but that the community latched onto some of the extraneous pieces (controllers, controllerAs, etc), which don't offer enough cost/benefit and simply make things much harder to grok. You often end up babying references and being bitten by implementation details of JS and somewhat-confusing names for things (e.g. $scope does not behave like the variable scope of any ES version).
Angular 1 still beats the pants off of everything else in my experience, if you know how to trim the fat. I'd very much like to write more about my approach in the near future.
Is the comparison fair? I haven't tried Angular 2, but it seems much more full-featured than React. For example, I guess that Angular 2 includes a router, while React doesn't, and just a few days ago there was a vitriolic thread just here on HN about the state of react-router.
If you look at react-redux-starter-kit [1], I would absolutely not say that it's simple. This file [2] is only 12 lines of code but can you call it simple? I don't think so.
It's not a fair comparison. React is just a view layer. It's not trying to offer everything that you'd need to write a web application.
React has become synonymous in some people's minds with "React + a bunch of other stuff", but this wasn't intentional. It's an unfortunate side effect of its popularity.
Or the alternative component API that has componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentDidUpdate, componentWillUnmount, and render.
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!
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.
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.
Personally, I think Mithril.js has done a better job than React of "nailing it" in terms of elegance, but it had the advantage of React bulldozing the path.
I'm not new to JS, and React's approach was the first one in years that I found very interesting in a way that didn't feel bloated or over-engineered out of the gate.
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.
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".
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.
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.
Well I don't think any significantly sized project in any framework can be expected to move to another framework without a major rewrite effort. I wasn't suggesting that. But if you are gonna start with something new then Aurelia is the way to go.
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.
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.
> 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.
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."
"Release candidate" != "Release" but in my understanding "RC" is "almost finished, but we might have some bugs to fix before"
Anyway my personal attitude is to keep away from alphas, betas, RCs and stable-from-yesterday. Applies to frameworks, operating systems and virtually everything, and each time I don't follow that rule, I regret.
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.
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.
It certainly means API changes are not anticipated, and that there should be a very significant problem with an API to lead to an API change at that point; certainly one would hope that fundamental flaws in an API that make it unsuitable for release would be identified well before an RC.
But its certainly possible to have reasons to make a breaking change from an RC (e.g. -- not necessarily relevant to a front-end framework, obviously -- a security vulnerability uncovered that reveals a critical flaw in the logical design, rather than implementation, of an API.)
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.
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.
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.
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.
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?
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 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.
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.
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.
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.
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:
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.
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.)
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.
> A release candidate is NOT supposed to have breaking changes....
A release candidate isn't a release, and the release may have breaking changes from the RC, and obviously an RC of anything that would be a semver major release may have breaking changes from the previous actual release. So, in either direction, an RC may have breaking changes.
Ideally, the last RC should not have breaking changes between it and the actual release, but we wouldn't need a "candidate" if we knew things would be ideal.
No no and no. Breaking changes are not ok, not even slightly!
It's not acceptable after an alpha release,
It's especially not acceptable after a beta release.
And it is offensive against developers to have breaking changes from the first release candidate and onwards.
Even for major releases, breaking changes is a VERY BAD thing. But sometimes it is unfortunately unavoidable.
It's ok if the first RC had breaking changes but after that you should have only bug fixes between RC versions. It seems unusual that some breaking feature got for some reason left out from an earlier build that was considered a potential candidate for release.
"Things that may still change" is generally expected to be bug fixes.
"RC" is not an excuse to flush semver down the toilet. If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.
> "RC" is not an excuse to flush semver down the toilet.
That's true. Then again, an RC in semver is a prerelease version and "A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version." (SemVer 2.0.0, para. 9)
Breaking changes from an RC isn't flushing semver down the toilet, its fairly explicitly permitted in the semver spec.
> If somewhere in the RC process you realize "this is never gonna work", you call off the 2.0 release ASAP and start working on 2.1 or 3.0 as appropriate.
No, if anywhere before the 2.0 release, including in any prerelease version in the 2.0 line (even an RC) you discover the need for a breaking change, that's fine per SemVer, and the major release that comes out of resolving those issues will still be 2.0.
Yes if you clarify a few wrinkles in the API from one RC to the next that is expected.
If you have a bunch of active, unmerged, and API-breaking branches where you're not sure which one is going to make it into the release, don't call it a release candidate because you're planning to change the API. (I don't know whether this was the case with Angular, I just assume it after reading the rant.)
I 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.
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 ...
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.
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.