4 ms·

Doesn't solve any of the big problems with large scale javascript apps: 1) Lack of type checking leading to exploding runtime exceptions 2) Object inheritance

• programminggeek 11y ago
  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.
• wnevets 11y ago
  prototypal inheritance isn't a liability that needs to be fixed.
  • manyoso 11y ago
    Yes, it is and the first reason is related to #1. Prototypical inheritance doesn't make much sense outside of a dynamic language. The second reason is because Javascript is disguised to look like Java and hence people familiar with the C-family of languages are surprised and baffled because Javascript is using the C-family syntax and idioms for classical inheritance to mask the very different prototypical inheritance.
    • wnevets 11y ago
      Javascript is disguised to look like Java because people keep trying to "fix" it.
      • manyoso 11y ago
        It was designed from the very beginning by Eich to look like Java and not because subsequent people tried to "fix" it. Where are you getting this stuff?
        • wnevets 11y ago
          ES2015 just added the class keyword to make it look like java last year. IIRC the new keyword wasn't part of javascript in those first two weeks when javascript was released. Where are you getting this stuff?
          • nilliams 11y ago
            'class' wasn't added to make it look like Java. It was added as sugar for a common pattern that everyone was already using. Many languages other than Java have a class keyword.
• nerdwaller 11y ago
  Well put. I've been keeping an eye on elm (elm-lang.org) for a bit to see if it stands the test of enough time for me to decide to try it out. It, at least as far as I've seen, tries to address these concerns. But who knows, maybe it's just more noise.
  • manyoso 11y ago
    FWIW, having tried Elm, I was very impressed with: 1) Type checking... yay! 2) Awesome compiler error messages that help fix #1 3) Purely functional language with immutable data structures helping performance 4) Reasonably easy and well thought out encapsulation mechanism via modules On the other hand I was put off by: 1) Very opinionated about design patterns with a react style gui framework 2) Signals are hard to explain and don't easily map to more familiar patterns 3) Not much (if any?) server side development I think Elm would really benefit from something like built-in support for Qt-style signals/slots that are much easier for newcomers to grok and a much less opinionated focus on the one-true-react-style-design-pattern But I could very well have missed something. Just my two cents.
    • Drup 11y ago
      You could be interested by http://ocsigen.org/ http://ocsigen.org/
• TimJYoung 11y ago
  Yes, exactly: http://www.elevatesoft.com/blog?action=view&id=why_limit_web_development_to_javascript http://www.elevatesoft.com/blog?action=view&id=why_limit_web...
  • manyoso 11y ago
    Thanks for the link! Yes, I think this generation of Javascript developers will eventually need to come to grips with this.
• lisivka 11y ago
  JavaScript is syntax sugar for Scheme (Lisp variant). Lisp is proven to support large scale apps, but you need to cook it using another cookbook.
  • manyoso 11y ago
    I have a lot of respect for Lisp/Scheme, but I wouldn't regard Emacs as the most maintainable of large scale apps. Besides, the ability level of the average Lisp/Scheme developer and the average Javascript developer is likely not commensurate.
    • lisivka 11y ago
      It is funny that I downvoted on YCombinator site. :-) See few hints how to write efficient lisp: http://www.paulgraham.com/carl.html http://www.paulgraham.com/carl.html . You can apply them to JS too.