Ask HN: How to write a web app that will outlast the latest JS trends? | Hacker News Reader

Ask HN: How to write a web app that will outlast the latest JS trends?

19 pointschaimkut22 comments

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?

View on HN

How do you write a modern web app and be sure it will still be maintainable in the 2-3 year time frame?

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.

"you can do more things quickly at first with these tools, but at the expense of introducing portability and maintenance overheads"

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.

I'd definitely be interested in reading how you organize and maintain your codebase. Have you developed an in-house framework?

Yeah everything was in house. I can't remember how I came about my build solution, but it works amazingly well. If I do a quick find on my JS code base, I see that I have 343 JS files, which is spread over 44 directories.

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.

A blog post would be great -- I really like lightweight dev processes.

Do you use map files for debugging unminified JS?

"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.

Oh that's really interesting -- thanks for explaining it!

My suggestion - you can't predict the future. Evaluate the best of what's currently available based on momentum, user base, and community. Pick the best for your current use cases. You can decide not to use the latest and greatest- observe what will stay constant, and use that.

The way I look at it, I will not switch frameworks just because the web community says so. I will switch only when the current framework is causing issues (loss in productivity, stability issues, performance issues etc) and most importantly how does it better solve the problem your application was trying to solve in the first place. IMO, code, programming styles, frameworks (js or server side)and IT in general needs to align with the problem its trying to solve. Just changing because the community thinks its cool is for the birds.

"The best way to predict the future is to invent it". - Alan Kay

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.

Please, no more JavaScript frameworks unless you're doing something truly interesting, ala React with its virtual DOM or Angular with its.. everything.

There are enough to go around already.

I was being facetious.

I am actually using AngularJS to rewrite an old project for a client. The reason I chose it is not because of popularity alone, but because it makes my code easier to read and it adds responsive interface to it.

Don't aim for a growing trend in regards to frameworks, aim for productivity and user experience.

Why would you be "in a rut" if the way you built your site is no longer the latest fad in 3 years?

Sometimes a need arises for browser-based apps that are not on the net, usually as part of a system installed at a location without access to public internet for various reasons.

If 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?

What makes you think that AngularJS isn't going to involve in that time? Looking at the plans for AngularJS 2.0 and you see discussion about Polymer, Dart, and using ES6/ES7 features and polyfilling anything missing nowso the framework will last for 5-10 years.

Because in 3 years the frameworks, tools, etc. will have a much weaker base of developers than it its heyday (now). So in 3 years the framework will fall behind in browser compatibility, integration with newer tools, etc. Left to rot in the bit bin of history. And if I need to make changes in the web app, add new features, it'll be much more challenging if I also have to be dealing with framework maintenance in parallel.

Simple.

Build something people want.

Nobody cares what JS framework you use. Look at Craigslist.

Why limit yourself to a client side JS framework?

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.

How is Rails different from any other server side solution in creating apps that feel like applications?

Because it has mechanisms in place to make server side driven templates feel like they are client side for most use cases. I carefully included "such as rails" because I'm not saying only rails can do it.

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.

use vanilla.js

Reply on news.ycombinator.com