4 ms·

There is no solution to large scale JS apps. Large systems are inherently problematic. The only way to "fix" them is to break them into smaller modules and sub

There is no solution to large scale JS apps. Large systems are inherently problematic. The only way to "fix" them is to break them into smaller modules and subsystems. Fancy abstractions and features will never solve large system issues. The large system issue is that it's large.

manyoso 11y ago
This is too clever by half. Some tools/languages are more amenable than others to creating and maintaining large apps. Very large applications have been written and maintained in C/C++ for decades. My contention is that Javascript is particularly ill-suited to the creation and maintenance of large scale apps in the long run for the reasons explained. Any new language which purports to be an improvement upon Javascript should at least attempt to rectify these issues. That's my thesis.
- j42 11y ago
  This is actually quite fascinating (and part of my upcoming book...) Despite the obvious high/low-level language differentials, people have been managing multi-million-line C code-bases since the 80's. Then again, think of how little the build tooling has actually changed -- instead of fragmenting, you're left with llvm, gcc, make at the core of most compiled software. JavaScript is the exact opposite with the lowest possible barrier to entry (built-in to every web browser...), and the proliferation of frameworks and libraries may be due to this in combination with the lack of fundamental understanding of design patterns that can scale. Lots of people trying to partially solve symptoms, missing the forest for the trees. Theoretically there's nothing preventing good patterns in high-level UI development, but I'm not quite sure it's been done right, yet and have no idea when the dust will settle.
  - manyoso 11y ago
    Javascript and other dynamic language like it are very good prototyping languages and for developing a quick mock-up to explore the pros/cons of a potential solution to a problem. But the lack of type checking and proper encapsulation turn into big headaches when scaled to a large app with even a few more junior developers. Without a compiler/type checker to help spot obvious problems in code runtime exceptions explode. This happens even for senior developers. And the lack of proper encapsulation other than by convention can/does lead to an explosion of the surface area of source code that a dev needs to know and be familiar with in order to refactor and make changes to large codebases which makes for very brittle large apps. Hence, I look forward to new languages targeting web assembly that will be more amenable to creating/maintaining large scale and long lived apps.
- EdSharkey 11y ago
  JavaScript is a toy language wherein I shake my head in disbelief every day that it is my primary language, but I have found it is possible to write typesafe code with vanilla JavaScript. With tooling and a rigid coding style observed by all developers, I'd say medium-to-large codebases (100K and up) can be maintained and extended just as well as other C-like languages. Using ultrastrict tools like Google Closure Compiler in conjunction with JSDoc comments gives you type checking along with minification and closure elimination. If you don't want the harsh taskmaster that Closure Compiler can be, IDE's like IntelliJ are able to navigate (with plugin helpers) your Node.JS codebase and build a useful type library. Again, JSDoc comments are critical here, and if you markup your JavaScript accurately and completely, you wind up with an editor that gives you very good type correctness warnings and inspections. Just keep your eyes peeled for yellow highlights and squiggly lines, and you can have confidence that your codebase is clean. JSDoc is very verbose, which is a shame, and you have to get good at forming types that are conducive to its tags. A good coding style document can go a long way to making that possible. I've found boring JavaScript groks best for all tooling. I stay away from mixins and mostly stick to boring old JS prototype definitions where the mutable bits are @type'd and assigned in the constructor to 'this'. Chrome can JIT these types of prototypes the best. Of course, there's no substitute when maintaining a large code base than to run with a comprehensive test suite.
wtetzner 11y ago
Well, by combining small systems, you can still end up with a large system. Abstractions absolutely can help solve the problem, by providing ways to modularize better.

manyoso 11y ago

This is too clever by half. Some tools/languages are more amenable than others to creating and maintaining large apps. Very large applications have been written and maintained in C/C++ for decades. My contention is that Javascript is particularly ill-suited to the creation and maintenance of large scale apps in the long run for the reasons explained. Any new language which purports to be an improvement upon Javascript should at least attempt to rectify these issues. That's my thesis.

j42 11y ago
This is actually quite fascinating (and part of my upcoming book...) Despite the obvious high/low-level language differentials, people have been managing multi-million-line C code-bases since the 80's. Then again, think of how little the build tooling has actually changed -- instead of fragmenting, you're left with llvm, gcc, make at the core of most compiled software. JavaScript is the exact opposite with the lowest possible barrier to entry (built-in to every web browser...), and the proliferation of frameworks and libraries may be due to this in combination with the lack of fundamental understanding of design patterns that can scale. Lots of people trying to partially solve symptoms, missing the forest for the trees. Theoretically there's nothing preventing good patterns in high-level UI development, but I'm not quite sure it's been done right, yet and have no idea when the dust will settle.
- manyoso 11y ago
  Javascript and other dynamic language like it are very good prototyping languages and for developing a quick mock-up to explore the pros/cons of a potential solution to a problem. But the lack of type checking and proper encapsulation turn into big headaches when scaled to a large app with even a few more junior developers. Without a compiler/type checker to help spot obvious problems in code runtime exceptions explode. This happens even for senior developers. And the lack of proper encapsulation other than by convention can/does lead to an explosion of the surface area of source code that a dev needs to know and be familiar with in order to refactor and make changes to large codebases which makes for very brittle large apps. Hence, I look forward to new languages targeting web assembly that will be more amenable to creating/maintaining large scale and long lived apps.
EdSharkey 11y ago
JavaScript is a toy language wherein I shake my head in disbelief every day that it is my primary language, but I have found it is possible to write typesafe code with vanilla JavaScript. With tooling and a rigid coding style observed by all developers, I'd say medium-to-large codebases (100K and up) can be maintained and extended just as well as other C-like languages. Using ultrastrict tools like Google Closure Compiler in conjunction with JSDoc comments gives you type checking along with minification and closure elimination. If you don't want the harsh taskmaster that Closure Compiler can be, IDE's like IntelliJ are able to navigate (with plugin helpers) your Node.JS codebase and build a useful type library. Again, JSDoc comments are critical here, and if you markup your JavaScript accurately and completely, you wind up with an editor that gives you very good type correctness warnings and inspections. Just keep your eyes peeled for yellow highlights and squiggly lines, and you can have confidence that your codebase is clean. JSDoc is very verbose, which is a shame, and you have to get good at forming types that are conducive to its tags. A good coding style document can go a long way to making that possible. I've found boring JavaScript groks best for all tooling. I stay away from mixins and mostly stick to boring old JS prototype definitions where the mutable bits are @type'd and assigned in the constructor to 'this'. Chrome can JIT these types of prototypes the best. Of course, there's no substitute when maintaining a large code base than to run with a comprehensive test suite.

wtetzner 11y ago

Well, by combining small systems, you can still end up with a large system. Abstractions absolutely can help solve the problem, by providing ways to modularize better.