Hacker News Reader

Comment by typicalrunt | Hacker News Reader

Seeing the slide about one file that had 8500 lines in it surprised me. Maybe it's a JS thing (I'm not one of those guys) but I've been pushed to make smaller files instead of one large god file. It's hard to traverse a file with that many lines in it, as well as do any meaningful diffs on it.

View on HN

I've encountered a few ~10K sloc files, in PHP. One ex-colleague preferred them, on the basis that "it makes it easier to use Ctrl+F."

We have some legacy files with > 20K in PHP. I'm yet to find a PHP IDE which will happily consume these files and let me work them. I just jump into VIM when I need to edit them.

For arguments sake, I'm talking an IDE in the model of Eclipse/IntelliJ/Netbeans, not vim/emacs/etc. I'm aware that people have some pretty awesome configurations for such editors, but I'm for the most part extremely happy with IntelliJ.

What makes you keep it that way, given that breaking out large chunks and including the new files back in shouldn't be hard?

Each file represents a module in our business management software (e.g. documents/contacts/memberships/events/etc). Historically, we have replace entire modules with ones that fulfill new/improved/different needs. For example, we have a module called "membership 3", because as we have obtained new clients, "membership" and "membership 2" just were not structured to do the things the new clients needed.

When the company started, we were full of inexperienced devs with no official programming education/experience. Now we have a team that is more aware of things like design patterns. As such, the newer modules are easier to extend and add new features to, so we anticipate that rewriting entire modules should not be necessary when the newer versions need new features.

So to answer your questions, we are just waiting for the old versions to die, and for somebody to pay enough for a job that we can rebuild the old module from scratch :)

Of course, contributing factors such as time, blah, blah, man power, etc. come into play also. Always things that need to be done, never the time to do them.

Well, that's one point where Javascript should - and will! - improve, modularization. At the moment there is no default dependency framework - you can't say 'my module X depends on modules Y and Z'. Well, not by default anyway; there's CommonJS's modules, AMD, and in Javascript Harmony another 'standardized' module framework.

I personally use requireJS in a rather large Backbone project, and it works remarkably well.

People with experience dealing with large-scale software development have been pointing out this flaw with JavaScript for years. It's clear that it just doesn't support modularity properly, and there are severe consequences to this.

Yet there have still been those JavaScript developers who insist that it's a good language to use for anything beyond small (that is, a few lines of code) scripts. They go right ahead creating large amounts of extremely unmaintainable code.

I don't think the solution is to extend JavaScript. Realistically, the only sensible thing to do is to discard JavaScript for anything serious. Sure, maybe the language being used instead will compile down to JavaScript and try to fake properly modularity support, for instance, but this should only be a temporary measure.

All I think it would take is for a major player, like Google or Mozilla, to embed a more capable programming language in their browser. Python, for instance. It's has decent support for modularity, and has been proven with very large systems, yet it still offers the benefits of a scripting language.

The situation wouldn't improve over night, but after a few years we'd likely see Python support in the other major browsers, even if it's just the open source ones, and Opera. These days, that'd likely be enough to gain some good traction. Then we'd at least have a viable option for large-scale, client-side scripts within the browser. It'd be a far better situation that what we've got with JavaScript currently.

Call me crazy, but I think adding modules to JavaScript seems a little more pragmatic than entirely discarding it in favor of Python.

Also: http://wiki.ecmascript.org/doku.php?id=harmony:modules

especially if imports over http in a browser aren't a solved problem in Python either and would also require language extensions

Yeah, I've dealt with 10000 line JS files before. You know, the master JS file that gets included on every page in the application. Too risky to change anything in it. Ever.

There is no easy way to include .js file that are stored on your server.

huh? post-process them with something like Jammit. Or just `cat file file file file > final.js` and shove it through a minifier.

Depends what your definition of "easy" is. It's harder in JS than in most languages.

Why is it harder? Concatenating the files is literally all that's necessary, as long as you build them intelligently:

  (function() { /* your code */})()

I'd argue that's significantly easier than most languages. But still - this can easily be a single bash line in your deploy script, or you can run `make` before copying the files over FTP. It's not easy, it's trivial.

Why is it harder?

Things like "as long as you build them intelligently", "bash", and "deploy script".

>There is no easy way to include .js file that are stored on your server.

So lets assume you have a totally-static website. That involves copying files over e.g. FTP at worst. So you have an FTP application, editing tools, etc. How unlikely is it that either A) the tools don't offer JS minification, or B) you're using flat text editors, and can't find someone who can write `cat /.js > all.js` or apparently the Windows equivalent `copy /b file+file+file all.js` in an executable text file? Then it's a double-click and drag the all.js file over.

Remember, we already have multiple source files which are included everywhere or this wouldn't be a debating point. So your files must be include-able in every page, which are either order-agnostic or must always be in the same order. Either you maintain that by hand, or you run one of those scripts or you use your editing application. Is editing every file by hand easier or harder than a single double-click?

You might look into preprocessing tools like grunt, which are designed for precisely this

I've been using PHP Minify [1], a simple script to concatenate, minify, and send out my backbonejs project.

Works well.

[1] - https://github.com/mrclay/minify

That doesn't address my point, which was about includes at runtime of .js files.

The reason why you see big .js files is that it's not easy to split your code in a.js and have it include b.js from the server.

Reply on news.ycombinator.com