Hacker News Reader

My maybe controversial opinion is that a lot of these hype problems, fatigue, ... come from one thing : Angular is a bad framework which beneficiated from an ENORMOUS buzz. I clearly remember 2-3 years ago when there was still no big apps written in it but everyone wanted to use it because "the JavaScript framework from Google! It will rule them all!". Meetups were full, enterprise catched on, and everyone invested huge amount of time learning this very hard and convoluted framework, and rewrote their app. Now we have a more natural, simpler, battle tested and better evolution with React, but everyone is understandably tired. I blame all this fatigue on this Angular mess, which is the definition of adopting technology because of hype and a lot of people fell in the trap

You nailed it. I feel like I've been permanently damaged from digest cycles, ng-filters, providers, transclusion etc... I feel like others must have been damaged enough to write off new Javascript frameworks entirely, which is unfortunate given how great React is.

;permanently damaged...

The good news is that Angular 1.x will work fine. It'll get the job done, there's a huge pool of talent to pull from, and it's proven to work at scale. However there are newer, better technologies now, and in 2 years time, there will be better ones still. It's a tradeoff like any other.

And while certain fads do come and go, there are also larger shifts and it's pretty clear by now that React's declarative-reactive style is the direction the industry as a whole is going.

The aggregate community is always searching for better solutions, it just so happens that this aggregate community is now huge and that means lots of people thinking about the same problems, meaning we make faster progress.

Old things don't stop working, but new things can be made better! What's the harm? Why so angry?

I think there are frustrations borne from two main places:

- Code is fashion; for some (especially on HN) there is inherent value in using technologies that are bleeding-edge and in vogue. Additionally, the necessity to use things that are bleeding-edge and/or in vogue is amplified when you're on HN or similar communities, much in the same way that the quality of your raw denim is amplified when you're on a fashion forum or with a bunch of stylish people.

- Fashion fades; building something when it's in vogue in 2015 for the sole reason that its in vogue in 2015 feels a lot worse when its in 2016 and suddenly the underlying technologies are not so shiny.

I think it can be easy to muddle 'progress' in the sense of "how do we move web technologies forward?" and 'progress' in the sense of "how do we deliver value to clients and customers?" As someone who is fairly shy of the current fashion (namely the React + Redux stack, which I've had the pleasure of working with the past couple weeks and whoa is it cool!) -- I'm not entirely convinced that the value delivered by using these technologies always outweighs the risk that they'll be obviated in less than a years' time. And so, there is a risk inherent in rapid progress, if rapid progress necessitates (as it seems to) the abandonment of anything that isn't pushing forward.

Choosing your technologies is a value proposition: every choice has positives and negatives. It can be frustrating to realize in retrospect that the positives weren't that positive and that there were negatives you didn't even imagine.

"It's pretty clear... is the direction the industry as a whole is going".

You or anyone else posting hasn't identified this "industry", it appears to be "quickly built apps that have no lifespan". I mean no offense; but we're back to saying it should be used because people are using it.

I'm upset at exactly that; it's not like anyone replied with objective software development reasoning that justifies this constant shift of frameworks, or addresses the need for enterprise software to have a longer horizon for support and talent.

It's also more than a little frustrating when you come to HN and people say "Angular/Node/whatever is bad, and you're a bad person if you use it" all while I'm actually making neat stuff using the aforementioned tools.

Well, I thought they were neat before at least.

While other people are busy writing blog posts, I've been shipping successful projects with Angular. I'm getting paid to write code, and I don't get paid to write blog posts defending Angular, so I don't bother. Also, I've shipped some very complex apps built with Angular, and it's very obvious to me that many of the common complaints about it are nonsense written by people who have just used it for a few days.

This !!!!

> While other people are busy writing blog posts, I've been shipping successful projects with Angular.

I've got no dog in the Angular fight, but I will point out a problem with the 'while others have been arguing I've been shipping' line: while it does optimise for productivity ('shipping'), it ignores correctness. Imagine someone writing, 'while others were fighting over crypto, I was shipping [ROT13-using code].'

My problem is that these arguments are important: e.g. we know that the halting problem is not generally computable, so a product which relies on computing it cannot be right. And oftentimes 'just shipping' ignores the lessons learnt by those with more experience than oneself: 'I've been shipping' can really mean 'I've been busy putting myself in a position to learn' and 'others writing blog posts' can really mean 'folks who've learnt the hard way trying to warn others.'

Like I said, I really have no clew if Angular is a problem or not; I don't really write any JavaScript these days. My only concern is the form of your argument.

You're entirely correct about the form of my argument being weak. Too busy shipping code to make a more coherent argument. :P

I definitely do worry sometimes that spending too much time getting things done takes away from time spent learning how to do things better. I hope that I've found a good balance between the two, but it's easy to get it wrong, and your point is an important one.

"I don't get paid to write blog posts defending Angular, so I don't bother."

I really like this comment; because it resonates with my Backbone experience. I kept reading these hit pieces by Angular fans as part of my daily info gathering; but I had code to write and a project to deliver.

But not writing those blog posts may have been an error on our part; we avoided the discussions and it leads to the cool kids changing the rules all day.

I can't force you or I to write these posts; but maybe we have to face that there is a cost to not contributing.

That's really interesting to know. I didn't read those blog posts back in the day, so I never realized how much history has repeated itself. There's a lesson to be learned here.

I just shipped another of many successful projects using Angular. There are lots of blog posts out there complaining about it, such as that it's over-hyped, or that it causes messy HTML templates. I didn't start using it because of the hype, and I don't find it hard to write clean templates. The complaints are mostly nonsense, as far as I'm concerned, and I'm highly suspicious of any argument in favour of React that's simply based on saying it has "won" or that it is the "next generation".

I just don't get the reactjs hype either. If you look at the data[1], it's still in the early phases of the adoption cycle while angular is a very broadly used technology. I guess if you just look at the bay area it looks like it's getting some traction, at least in San Francisco[2].

[1] https://www.google.com/trends/explore#q=angularjs%2C%20react... [2]https://www.google.com/trends/explore#geo=807&cmpt=q&q=angul...

For me, at least, it is a helpful reminder that HN is disproportionately enamored with the bleeding edge, and that at any given time around a thousand people are exploring Java for every one person exploring React.

(Put another way: hype, even valid hype, can fall victim to an echo chamber.)

"state of the art" is the keyword in the title.

It does mean bleeding edge, most hyped, etc...

Right. My point is more that the relative importance of using 'state of the art' technologies is overhyped on sites like HN, and that its role in the overall zeitgeist of computing is not as large as HN would have you believe.

That data looks messed up to me. The Reactjs search is most common among Russia, China, US, Australia, Canada, France, UK, Germany. The Angular search is most popular in India, Sri Lanka, Bangladesh, Belarus, Israel, South Korea, Hong Kong ,Singapore, Tunisia, Ukraine. I suspect it may be because the angular search includes the term 'angular', whereas the equivalent for react is 'react js' (and not just 'react').

No one is saying that no one should still use tech that was previously state of the art. No one is saying that you need to rewrite existing apps if there's no business need to.

I use Backbone models in a React app because Backbone is still the best library for models. I haven't tried Redux because it doesn't solve any problem I know I have.

Plenty of people skipped Angular because they knew it wasn't going to be on top of the hill for very long in the evolution of the frontend ecosystem.

Out of curiosity, what's wrong with backbone?

I don't think anything is "wrong" with Backbone. It's dated in its ideologies though. Backbone comes from an era of script tags and a global "Backbone" namespace. Until recently, it required jQuery to do its "innerHtml/append" DOM manipulation. As a way to add structure to a jQuery app, it's great. It leaves a lot of freedom to the implementer. I did find that I required something like Marionette to assist with views however. Many developers are starting to stray from the MVC pattern toward other (perhaps more interesting) patterns and I think this is where some of the koolaid-style "hate" comes in.

Yeah, I use Backbone with Marionette on a project that's a few years old ( demo.enterprisejazz.com ). The "freedom to the implementer" part is very important to someone like me.

I don't think it would be productive to switch to something new even if that new thing was better.

Nothing is wrong with Backbone. I thought it was beautiful. We don't always pick our tech though. It's part of the problem here; the hype engine is used to steer non-technical people, or more managerial technical people. While the engineers and technical leads might be completely comfortable; the next project starts and you are told it should use X since that is what the client kept mentioning when they called.

Also, some people love this. It means they can show up at work and talk about how they learned React and it's better and they can do a pretty good job of using the hype train to stand out from their peers.

AMEN

Absolutely. React creates a dependency at the worst possible place, the view/component level. That's the one part of your code that should be the most re-useable. How many times do we have to re-write the same image galleries?

The only clear winner can be vanilla JS web components, especially custom elements. A temporary polyfill is fine, but we need to say no to the extra dependencies like React and Polymer that trap us in dependency hell and minimize re-useability.

> The only clear winner can be vanilla JS web component

It cannot work since some browsers have different support for different features. You think people stopped using Android 2.x or old iphones ? So you end up with polyfills and since polyfills become dependencies you end with abstractions akin to frameworks, even worse since you now need to maintain your own mess.

Javascript isn't scoped in an HTML page, that's its first "sin". Therefore, any component architecture needs to work against the natural workflow of a webpage. So no ,the winner is certainly not "vanilla JS" and you know it. unless you are dealing with some trivial apps, I bet you'd use framework X or Z in an heartbeat.

The custom element polyfill is 2KB gzipped. All browsers are on board with supporting it. No, polyfills are not akin to frameworks, and yes, I am building a large SPA using just custom elements (no framework) and it's amazing.

I'm on the Polymer team, so admittedly biased here, but I don't understand your comment about Polymer minimizing reusability.

Polymer is designed to _mazimize_ reusability and interoperability via standards. Polymer elements just elements and you use them via standard API - set properties, attributes, listen for events, add children. The only wrinkle is that Shadow DOM is a little slow to polyfill, so we're using a wrapper on the DOM API. This will eventually go away.

Polymer is also extremely small compared to other libraries, and has no external dependencies: 34k gzipped without polyfills and 42k with. This will get better as native Custom Elements arrive across browsers later this year.

My main point is that in the Web Components future, it will not matter so much what libraries are used to implement components, as long as they are standard elements on the outside. The guts can be Polymer, some future web-component supporting React, Angular, etc., or just plain JS.

Using Polymer(...) instead of document.registerElement(...) means that for anyone to re-use a component I build, they will need Polymer as a dependency. There will likely be more web component based libraries popping up, so then I'm going to need to download half a dozen identical libraries to use different components for my site? Then there's hacked components like React that don't even use the web components spec...

Yes, to use any component you will need that component's dependencies. That's just true of any software component. The Polymer() call has nothing to do with it, as in the end it just calls document.registerElement(). Raw elements that call into a template library in attachedCallback() will depend on that template library.