Hacker News Reader

Comment by Silhouette | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com