News for hackers. Stuff that matters.
Re:The end of Framework Churn by kitotik on Monday September 18, 2017 @02:27PM (#15278270)
In my experience, the biggest cause of framework churn is bad architecture and development patterns - no clear separation of business logic and 'framework', which forces these all-or-nothing rewrites with the sexy framework of the day in the hopes of a massive productivity boost.

If you can manage to get >50% of your core logic in a 'vanilla' language(js, python, good ol' C) with minimal external dependencies, these yearly framework shifts become much less of a big deal.

I just wish I had internalized this lesson way, way, way earlier in my career...

Re:The end of Framework Churn by autokad on Monday September 18, 2017 @02:59PM (#15278524)
I was once using angular, and I wanted to use a common thing I had done in the past (autocomplete for a form I think it was). I already had a simple and effective way of doing it in jquery, but getting angular and jquery to work together is kind of a pain.

at the time, it wasn't implemented in angular very well, and there were some specific things I wanted to do that was incompatible to the way angular did it.

when I posted to the community how to get it working, their response was 'using jquery is not the angular way'. my way is getting things done with code I have used time and time again.

it took a bit of wrestling, but I was able to get it done with jquery and angular.

Re:The end of Framework Churn by ergo14 on Monday September 18, 2017 @02:49PM (#15278443)
Thats what web components aim to do, take Polymer - you get only minimal library on top of the spec, and with more browsers supporting the standard you just shed the polyfills for missing bits.