Ask HN: How to write a web app that will outlast the latest JS trends?
HN is rife with JS framework wars, comparisons, latest feature news, libraries of the week, etc. What are surefire strategies for building a web app that won't have to be completely rewritten in 2-3 years? If I choose to write a web app in AngularJS and then in 2 years the Web community decides to coalesce around the new latest and greatest framework, technology, then it seems like I'll be in a rut.
How do you write a modern web app and be sure it will still be maintainable in the 2-3 year time frame?
22 comments
[ 6.9 ms ] story [ 66.3 ms ] threadIf these systems are planned to have a life time of say 5-7 years, it would be best to not start developing parts of them with libraries and frameworks that are due to be phased out in just 2 or 3 years.
E.g. AngularJS, the writing is clearly on the wall. Google are investing in a number of libraries and technologies that are the "next thing": Polymer, Dart, Web Components + Shadow DOM in Chrome etc. It appears that in the big picture AngularJS is a stepping stone, which is a problem when you plan on building something that should be supportable for 5+ years.
Remember GWT? 5 years ago it was all the rage. At the 2012 Google I/O event they announced they're handing over control to a steering committee - their way of letting go and moving on. Imagine if you needed to continue supporting GWT based code for another few years, when the catalyst for the technology are phasing it out themselves. The worst part of this is the lack of developers - they see Google dumping GWT and stop learning about it. How do you hire developers to continue maintaining your software? This should qualify as being "in a rut".
So it begs the question, should an organization start using AngularJS (or any other fashionable framework trend) for long-term support systems? If so, how should one decide?
Don't aim for a growing trend in regards to frameworks, aim for productivity and user experience.
Certain server side frameworks such as rails let you build apps that feel very similar to client side js apps without having to use them.
I can't speak for other frameworks but rails has turbolinks and also seamlessly handles the ability to send back pre-compiled html results to the client as a response to an xhr.
Basically you get the best of both worlds and it's all unobtrusive so all of your content is crawlable and you get a great user experience without having to do hacks or extra work.
Therefore, the obvious solution is to invent a new JS framework.
To me, it looks like the Google team is committed to staying relevant based on their roadmap to 2.0. I personally feel confident AngularJS will be around in 5 years. Web components and dart fit well with angular, so I doubt it'll go the route of GWT.
There are enough to go around already.
There is no magic.
1. Write your code using standard JavaScript, avoiding corner cases and features that aren't universally supported.
2. Use libraries (you decide the architecture and when to call them) instead of frameworks (they establish the architecture and your code has to fit within it).
Neither of these is a new argument, it's just the usual trade-off with using bleeding edge functionality or building around a framework, now applied to the world of front-end web development and JS: you can do more things quickly at first with these tools, but at the expense of introducing portability and maintenance overheads that might cost you further down the line. Whether the benefit outweighs the cost is something you have to consider on a case by case basis.
I totally agree with this. When I first started working on my product (http://gitsense.com), I decided to use extjs and it did the job in the beginning. However, as I got better with JavaScript and became more design savvy, I found extjs to be an anchor. Getting it to work the way I wanted, basically required overriding everything and it was at that point that I decided I was better off going my own route.
Now I'm sitting at around 180,000 lines of custom JavaScript code. I still have some extjs code, but 98% of my current JavaScript code is custom. And it should last as long as my product does.
It's a bit involved to explain how it works, and I probably should do a blog post to explain it in detail. I'm pretty sure the solution that I have is what other big JS code bases uses, but I could be wrong. What I really like about it, is it lets me debug individual un-minified JS code.
The more that I think about it, my overall build and development environemnt/process is rather unique. My Java code base is about 100,000 lines spread over 200 Java files and I don't use maven or any ide. It's good old makefiles and vim with ant sprinkled in there.
There is a lot to blog about, so I'll see what I can come up with next week.
Do you use map files for debugging unminified JS?
No its even simplifier than that, and it has to do with how the browsers JavaScript engine reads the JS files. Well at least modern browsers. When I generate my html file with the include JS lines, I make sure to put the minified version first, then the unminified files to debug.
If the unminifed version contains the same function, the browser will use that instead of the minified one. So when an error comes up, the browser will point to the unminified JS file in the stacktrace.
Build something people want.
Nobody cares what JS framework you use. Look at Craigslist.