7 ms·
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
by gtsteve 9y ago
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.
- ythn 9y ago> Frameworks don't rust Unless the framework is iron [1], of course [1] https://github.com/iron/iron https://github.com/iron/iron
- shados 9y agoAgreed. 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.
- Prefinem 9y agoThe 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.
- shados 9y agoThe 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 :)
- Prefinem 9y agoTrue. 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.
- madamelic 9y ago>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.
- lanna 9y ago> 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.
- davedx 9y agoThis 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.
- fatbird 9y agoFrameworks don't rust, but skillsets do.
- StavrosK 9y ago> 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.
- amelius 9y agoThe problem is that everybody publishes bugfixes alongside new features. This practice should be stopped, because it leads to dependency hell.
- gras 9y agoIt'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.
- eropple 9y agoOpen-source maintainers should totally leverage this opportunity to make their projects sustainable. Sell your backports. Enterprises want them.
- bbatha 9y ago> 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.
- sooheon 9y agoWhen 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.
- sixsence 9y agoWith 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.
- gtsteve 9y agoIs 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.
- jonny_eh 9y agoA 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.
- dceddia 9y agoAlso, WordPress is dumping React - https://ma.tt/2017/09/on-react-and-wordpress/ 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.
- deleted 9y ago[deleted]
- morgancmartin 9y agoI 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.
- shangxiao 9y agoAt 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.
- watwut 9y agoDo 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.)