Hacker News Reader

Comment by gtsteve | Hacker News Reader

I don't think there's that big a problem with how many front-end frameworks there are, and the pace of development. I think the problem is people who feel they have to use the latest and greatest feature and they have to know all the frameworks.

At my company we picked a stack and stuck with it. That happened to be React and Redux. I hear Angular 2 and Vue are really great frameworks but I feel under no pressure to really investigate them because we're doing fine as it is.

Two years later and we've barely changed aside from some package versions. We've got a very stable front-end with high code quality and component reuse.

You don't have to listen to the hive-mind. Frameworks don't rust.

View on HN

> Frameworks don't rust.

Ah, the optimism of youth. Frameworks don't rust if you don't mind sticking with the security bugs of 10-year-old kernels. If you need to upgrade your OS, you need to upgrade your programming languages, which means you need to upgrade your frameworks.

Everything rusts pretty quickly. Maybe you don't need the new features, but you definitely need the new bugfixes.

The problem is that everybody publishes bugfixes alongside new features. This practice should be stopped, because it leads to dependency hell.

It's either that or backporting bugfixes to every single past release, right? Is that what you propose? Or a "middle way" with LTS releases?

I mean, you could have separate bugfix and feature releases for a relatively low cost, but that would only alleviate the problem for the duration of a release cycle.

Open-source maintainers should totally leverage this opportunity to make their projects sustainable. Sell your backports. Enterprises want them.

That actually sounds like an interesting business model.

What form would the transaction take?

Yes, and how would maintainers know which versions of their software are actually still used?

You mark releases as "Stable and supported" and have corporations subscribe against releases. If you are subscribed to a release, you get bug fixes for that release. If someone does not have a subscription to a release, it does not get updated, and if there is no current subscription for that release, you don't accept new ones.

You always allow people to move forward their subscriptions, but never backwards. You provide migration paths for each supported release.

People will pay for it.

https://railslts.com/

http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...

https://news.ycombinator.com/item?id=5893961

"Here are the keys to a private artifact repo. We will update N major/minor/whatever versions."

I am low-key building a marketplace for this, because this really should exist. The problem, as a marketplace, is identifying projects both important enough that people will pay for it and aren't* already functionally owned by a company that has a vested interest in their own project management.

(Are you a maintainer who's interested in something like this? Are there projects you would pay for this for? I want to hear from you. com dot edropple at ed)

I work at one such large org. We would pay good money for a 5 year support contract for a fixed version of a framework getting backported security (and maybe a few feature) updates.

Shoot me an email with details? Like I said in a sibling, this is a project I'm digging into. Email's in my profile.

The problem with publishing bugfixes separate from new features is that you end up with an ever expanding tree to maintain, and you eventually run into problems where bugs become intertwined with features and the right thing to do is extremely hard.

It's a little much to ask from an unpaid open source maintainer, and if you really want it that bad you should be willing to pay for it. Companies like Red Hat have made a living off of people willing to make that tradeoff.

This is why you should choose a frontend framework with a LTS (long-term support) program. (For example, Angular 4 or Ember.) You don't have to upgrade to the latest version of the framework, just the latest LTS version which will have all the relevant bug/security fixes. Only when the framework starts to drop support for the LTS version do you have to deal with upgrading and learning whatever new features they have added since then.

Maybe it is worth to add that a LTS release in JS land isn't what non JS developers would expect. LTS releases with support for 6 months? Seriously?

For comparison Red Hat supports their servers for a minimum of 10 years and you can buy extended support after that.

6 months for v.4, then 1 year. Which is still absurdly short. That's not even long enough for sane, normal versioning (e.g. Python 2.6 through 2.6.9 was like 5+ years). These people are crazy.

For Ember at least, the LTS is 4 releases, however all versions are backwards compatible up to the point at which they bump the major version. So you can just keep upgrading whiteout changing code for potentially years.

You make a good point, although I was exclusively referring to front-end JS frameworks. Of course you'd want to update Spring, .NET and whatever else you're using due to vulnerabilities.

But to the point you were making - it's not impossible that browsers could evolve to the point where our current version of React is unusable and it's been long relegated to the buzzword graveyard. Of course in that situation we'd have to maintain our own React branch or rewrite in whatever was a popular front-end framework at the time.

My point is that getting stressed out about the front-end JS framework churn isn't helpful to anyone. Pick a stack and stick with it, and only move when it's simply not productive to stay.

Agreed. Honestly at this point I'll take boring. I'd welcome boring. People really need to stop upgrading 0.1 second after something comes out. Take the Java world. You can have a lot of criticism for the language or the platform, but the reality is people get shit done without upgrading right away. It's not even part of the culture. This allows people to master the platform and tools.

In the JS world, there's no mastery. People just keep jumping to newest versions and spend all of their time fighting the new problems. Just. Stop.

The company I work for almost standardized on react/redux. We're not done getting rid of our old stack that people are already looking at Relay Modern, Apollo, MobX, etc. If it wasn't for our investment in a massive home grown React component library, there would probably be VueJS all over the place.

So we lose the ability to help each other. Every team is different, dealing with different problems. We can't build libraries since we don't have a platform to target. That to me makes us much weaker.

So I welcome boring. I welcome the day when people are no longer interested in it so they stop spamming npm to check if a new version of their favorite library is out to upgrade to it when the existing one is working fine.

The issue is leadership. If someone high enough forces standardization, then you are good to go. Just like the old days of only being an 'X' language shop and using only 'Y' framework.

I think the irony is that all the freedom I used to see frontend people using is coming back to bite them and their mindset is slowly moving towards what backend people have been doing for a long time.

The issue is leadership, you're right. But it's not leadership at an individual company level. It's at a community level.

Right now, if you're in a tech hub and you tell FE people "Sorry, we're standardizing on <thing from last year> and we're gonna hold off on major release upgrades without a good reason", you're gonna lose some people and have trouble hiring or deal with constant internal complains. Why? Because their buddies in <other company across the street> aren't dealing with that restriction.

You need some serious charisma to tell people you're sticking with last year's tech and get away with it. If you're in an environment where you can do that AND still hire fast enough to grow, consider yourself lucky and hope your boss never quits :)

True. In the Midwest I guess we are a little more conservative. I have hit the latest and greatest fatigue and am happy to stabilize on something for day to day work. If I want to try something new, I can start a side project.

>In the JS world, there's no mastery. People just keep jumping to newest versions and spend all of their time fighting the new problems. Just. Stop.

The frontend framework we use has had six major releases in a year and a half. And I am talking, rip the guts out and change how it works major releases (How semantic versioning is supposed to work).

Like I appreciate that they are doing active development and making it better (because it is getting better, to be honest), but I still feel like you could fix bugs in some minor versions and do like cut major releases to like every six months at least.

Agreed - I've often thought that having to learn these new frameworks will ultimately lead to terminal juniority. I get that each framework does things differently, and you can learn new patterns from each one, but ultimately you're just re-learning the wheel. Not advancing your skillset.

With all due respect, React and Redux are still "in" and one of those buzz word frameworks right now. Your sentiment would mean a lot more if you were still having success with something like Angular 1.

You aren't proving you are resilient to changes by using one of the most current buzz-word filled frameworks out there for two years. The real test happens when your framework of choice truly becomes obsolete, like with what happened to Angular 1.

Is React still "in"? I thought the recent BSD+Patents furore had made it uncool, but perhaps this doesn't bother developers as much as I originally thought.

A lot of that was overblown, I haven't seen a change in sentiment in the projects I work on. It's not like the patents clause was new, it was just Apache Foundation deciding to ban it that way. So as long as you're not working on an Apache project, you're unaffected.

Also, WordPress is dumping React - https://ma.tt/2017/09/on-react-and-wordpress/

But I agree, I do not think everyone is jumping ship to Vue (or whatever) over the license.

I completely agree. We are using Angular 1.x at my day job and my team and I are feeling the pain. Manual DOM manipulation compared to React's virtual DOM feels like what it must have used to feel like comparing jQuery to Angular 1.

Perhaps frameworks don't rust in the sense that they deteriorate in terms of capabilities over time. But that doesn't mean that they don't become obsolete. Especially when you're building a product and trying to stay competitive, all the while all the the innovation surrounding a framework has packed up and left for a nicer camp.

We're using Angular 1 too, chosen just over two years ago.

The two-way binding/digest nature has really become our enemy. Everything we write has to account for digests and we've wound up with some terribly ugly code to account for digest problems.

Angular 1 is great for hobbyists and it makes implementing simple forms easy but when you use it for an enterprise app, it hurts.

Our app is still vastly better than decade-old 1.0 we've replaced, but we sure hate the digest now.

>We're using Angular 1 too, chosen just over two years ago.

Good god. You chose Angular 1 two years ago? As in 2015? When its horrific shortcomings were already known and the Angular devs were working on Angular 2.x?

> I think the problem is people who feel they have to use the latest and greatest feature and they have to know all the frameworks.

The problem is the marketplace and the companies that will demand the skills when one is job searching.

This works both ways.

When we evaluated what tech to migrate to from Angular 1.4, we looked at React and Angular 2. We were also hiring, and the overwhelming majority of devs we spoke to had experience or wanted to work with React.

The marketplace is directed by both buyers and sellers.

At my old workplace we had a few legacy Meteor projects that absolutely _nobody_ wanted to maintain. In addition to that we could not hire anyone who was both suitably qualified and excited enough to work on Meteor.

We still had to maintain them though as the clients had no money to what would effectively revamp the entire stack to something a lot more maintainable.

Working with a (relatively) unpopular & outdated framework seriously took its toll on both the quality and the developer passion. We had a few really talented people leave simply to avoid working on these projects.

Edit: To echo sixsence's sentiment: Our React & Redux projects have proven themselves to be very resilient over the past few years.

Do you state in you job ads that it is meteor position? Some self selection of applicants might help - you don't need someone super excited, just someone responsible and willing to do that work. At least, that is how our company found long term people for unpopular positions. Turned out they exists, just are hidden and don't know your job is match.

(I personally don't mind working with less popular tech part of time as long as I also work with something that sounds good in CV.)

> That happened to be React and Redux.

To be fair, I would put react in the same generation of frameworks as Angular 2 and Vue. It just got to the same basic virtual dom + modular components design earlier than the rest. Vue and Angular 2 don't really offer much besides marginal performance boosts (react fiber, preact etc erase this) and a more familiar way of programming for programmers in the last generation of frameworks angular 1/ember.

When people downvote enough to grey out what seems to me to be a decent opinion, I wish they'd at least offer a counterpoint. I agree with bbatha, if this is such a downvote worthy sentiment, I'd like to hear why so I can improve my own thinking.

Frameworks don't rust, but skillsets do.

> Frameworks don't rust

Unless the framework is iron [1], of course

[1] https://github.com/iron/iron

Reply on news.ycombinator.com