
Ask HN: How to write a web app that will outlast the latest JS trends? - chaimkut
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&#x27;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&#x27;ll be in a rut.<p>How do you write a modern web app and be sure it will still be maintainable in the 2-3 year time frame?
======
Silhouette
_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.

~~~
sdesol
"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](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.

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

~~~
sdesol
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.

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

Do you use map files for debugging unminified JS?

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

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

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

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

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

~~~
sehr
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.

~~~
iends
I was being facetious.

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

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

~~~
habeanf
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?

~~~
iends
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.

------
AznHisoka
Simple.

Build something people want.

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

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

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

~~~
rartichoke
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.

------
justhw
use vanilla.js

