Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My stance has been to take a more static view of an applications development life cycle. So you're on an Angular 1.x app, Angular 2 is coming out in a year, your project will be launched or is already launched and you're concerned with switching.

Stop, right now, just let it go, take a step back from the bleeding edge and see that you've got all the JavaScript libraries and tools you need to put together any application you could imagine. If your imagination is big enough then you'll be hand writing your own additions in no time. So long as your applications runs on the major browsers latest-1 without issue there isn't a reason to upgrade. If you're writing a project there isn't a reason to make a framework jump, and if Angular 1 to 2 is that different, consider it a framework jump. Why feel bad about not knowing your way around when you go from one framework to another, would you feel the same going from Drupal to Wordpress? They are both CMSs, both PHP, both extended far beyond their initial goals. Angular 1 will go into maintenance if Angular 2 is that different, development will slow, and eventually you'll upgrade to Angular 3, which is incompatible with Angular 2, but after years of having a working application.

I've gone from Angular, to Kendo, to Ember, to Backbone. If you want to make an 'investment' in knowledge of front-end development learn the plain JavaScript, read through the framework you're using. Walk through the execution, that will allow you as a developer-for-hire to pickup the newest shiny on a new team with less issues.

Web development has always had this pace, whatever tool or setup you commit too, the next week someone will call you an idiot for using it. Ignore them, make something maintainable, nothing in the new framework is ever mission critical, just nice to have.



Exactly... I worked on a project a couple years ago, and decided to use a beta version of bootstrap as the baseline for the project... I cloned the repo, merged the pieces into my project, and kept a copy of the docs at-that-time for reference.

The site still works great... the codebase is fine. It was before some later changes to bootstrap 3, so it isn't current with the released version, but it still works, and did better so than v2. The same goes for most things involving open-source tools. You can go through migration cycles, or accept and limit the scope of how you use it.

I always applied the same arguments for using Mono in places as a practical reasoning. So what if new development stopped/dropped or rolled.. as long as what I'm doing can keep running.

Your best bet is to keep your codebase modular so much as possible, and it makes it easier to replace certain pieces.

Today, I really like react + yahoo's flux implementation. There are some weird corner cases I've had to deal with, it's still nice. It really just depends on your needs.


I completely agree with this. Make sure you know the ins and outs of what's out there, but don't just follow trend blindly. Especially with a large team, or internal eco system.

I make a habit out of using smaller frameworks that gets the job done, and only that. Anything else or beyond, we code ourselves, or re-use from a different project. Or we just stick with older technology because we know it works. Sure, our productivity might initially be lower, but at least we save ourselves the pain of "the next big thi—oh wait, something new arrived let's switch".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: