4 ms·

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

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.

FuzzyDunlop 14y ago
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."
- pserwylo 14y ago
  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.
  - vidarh 14y ago
    What makes you keep it that way, given that breaking out large chunks and including the new files back in shouldn't be hard?
    - pserwylo 14y ago
      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.
Cthulhu_ 14y ago
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.
- PommeDeTerre 14y ago
  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.
  - kevincennis 14y ago
    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 http://wiki.ecmascript.org/doku.php?id=harmony:modules
bjhoops1 14y ago
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.
eta_carinae 14y ago
There is no easy way to include .js file that are stored on your server.
- Groxx 14y ago
  huh? post-process them with something like Jammit. Or just `cat file file file file > final.js` and shove it through a minifier.
  - streptomycin 14y ago
    Depends what your definition of "easy" is. It's harder in JS than in most languages.
    - Groxx 14y ago
      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.
      - streptomycin 14y ago
        Why is it harder? Things like "as long as you build them intelligently", "bash", and "deploy script".
        Groxx 14y ago
        >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?

FuzzyDunlop 14y ago

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

pserwylo 14y ago
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.
- vidarh 14y ago
  What makes you keep it that way, given that breaking out large chunks and including the new files back in shouldn't be hard?
  - pserwylo 14y ago
    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.

Cthulhu_ 14y ago

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.

PommeDeTerre 14y ago
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.
- kevincennis 14y ago
  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 http://wiki.ecmascript.org/doku.php?id=harmony:modules

bjhoops1 14y ago

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.

eta_carinae 14y ago

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

Groxx 14y ago
huh? post-process them with something like Jammit. Or just `cat file file file file > final.js` and shove it through a minifier.
- streptomycin 14y ago
  Depends what your definition of "easy" is. It's harder in JS than in most languages.
  - Groxx 14y ago
    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.
    - streptomycin 14y ago
      Why is it harder? Things like "as long as you build them intelligently", "bash", and "deploy script".
      - Groxx 14y ago
        >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?