5 ms·

It is not difficult to implement all those features using plain Javascript, in fact I would recommend it as a great learning experience. What is difficult is do

by gbuk2013 7y ago

It is not difficult to implement all those features using plain Javascript, in fact I would recommend it as a great learning experience. What is difficult is doing it in way that is maintainable over a long period of time. The nature of the language is that without iron code discipline Javascript code inevitably turns into a mud-ball. Apart from the obvious “many-eyes” benefits, frameworks also provide structure that buys extra time before this happens.

capableweb 7y ago
> The nature of the language is that without iron code discipline Javascript code inevitably turns into a mud-ball. Could you outline what you think makes JS more likely to turn into mud-balls compared to other languages? In my experience, no matter what language you use, or with what pardigm, unless you model and design your software architecture with discipline, you gonna end up with a mud-ball. Has less to do with the language and more about the process you use to model your domain.
- adimitrov 7y ago
  > Could you outline what you think makes JS more likely to turn into mud-balls compared to other languages? Plain JS is hell to refactor. Between arbitrary autocasting, little tooling and no useful type system, if you don't have a very detailed test suite, you won't find the parts of your code that are broken now. Also, if you do, you now have to reimplement all those tests that did nothing else than to check your call signatures. Ease of refactoring is a major indicator for a good enterprise language, as constant refactoring is basically the main development process. If your devs are afraid to touch certain pieces of code because nobody knows what the ramifications are, your software is already dying. That's why TypeScript is taking off so nicely. People crave those static guarantees that JS doesn't have.
  - gbuk2013 7y ago
    When you have reached the stage of mud-ball it is already too late. ;) With the appropriate amount of skill and discipline, however, this stage can be postponed for longer than the life of the application. Typescript is absolutely not required.
    - adimitrov 7y ago
      But that's a truism. Good coders write good code. Heureka! The real gain is to be had in pushing the mudball stage as far into the product's life cycle in absolute terms as possible. In that sense, nothing is required, but some things help. I argue that TypeScript helps.
      - gbuk2013 7y ago
        If it helps you, great. I’m happy enough with plain JS, thanks. ;)
  - capableweb 7y ago
    I've seen exactly the same problems with large TypeScript codebases as the JavaScript codebases have. Refactoring becomes a hassle not because there is types or not, but because there are endless of useless unit tests testing implementation details, because the architecture is highly coupled in the wrong places and because little care was made when the architecture was dynamically created (because "agile" or what ever) without considerations. Having good and smarter tests helps more for ease of refactoring than having everything mapped to types. But I might just have seen bad examples of TypeScript codebases.
    - thrower123 7y ago
      Probably this is a side-effect of translating JS unit-testing techniques without adequate thought and reflection. I am sometimes amazed at the extent of trivial tests that do no more than double-check the compiler that I see from web developers that move up the stack.
      - capableweb 7y ago
        When I talk about shitty unit tests, I mean regardless of language (bad unit tests seems as prevalent in JavaScript, as TypeScript, as Ruby, as Python, Rust, Go and the list goes on)
- gbuk2013 7y ago
  It probably does apply to all languages, but I prefer to speak from experience, which in my case is mostly JS. Architecture and the related abstraction is definitely the hardest thing about programming in my experience, and what really separates good programmers from the bad. Loose types, pass by reference, near-limitless mutability, scoping rules (without “use strict” to save the day) and asynchronous nature of the things it is used for are some of the things that come to mind with JS. All of these are actually very powerful features that make it into the language I love, but care is definitely needed. ;)
  - chrismorgan 7y ago
    Yeah, I really wouldn’t link it in any way to the language. It’s just mostly more obvious when it’s in JavaScript, because that’s associated with the user agent having to fetch the code and run it from scratch every time, and as a user you can more easily inspect where the time is going, compared with an app or backend processes, which are both much more opaque to the user. It’s more about architecture and discipline, and far, far more about simply caring about performance. (And larger teams make it much harder to care about performance.) For personal background in my firm agreement with capableweb, I work primarily in JavaScript professionally, tend to use Rust privately, and have used a variety of other languages and worked with both good and bad code bases (mostly good); and I care very much about performance.
    - gbuk2013 7y ago
      Don’t get me wrong, I actually love Javascript. I have written code in quite a few languages but JS is the one I am most productive and happy in by far (within the area of network services and web apps that I work in). It has also been very profitable. :) But the language has such a low threshold that it allows for incredible productivity while writing shitty code. But by the time you realise just what you have done (or someone else realised when they have to work on your codebase) its too late and it’s time for a rewrite. What makes JS special is how accessible it is and just how much mess you can make before reality bites. That said, I will take a Javascript mud-ball over an enterprise Java one any time! ;)
  - 7y ago

capableweb 7y ago

> The nature of the language is that without iron code discipline Javascript code inevitably turns into a mud-ball. Could you outline what you think makes JS more likely to turn into mud-balls compared to other languages? In my experience, no matter what language you use, or with what pardigm, unless you model and design your software architecture with discipline, you gonna end up with a mud-ball. Has less to do with the language and more about the process you use to model your domain.

adimitrov 7y ago
> Could you outline what you think makes JS more likely to turn into mud-balls compared to other languages? Plain JS is hell to refactor. Between arbitrary autocasting, little tooling and no useful type system, if you don't have a very detailed test suite, you won't find the parts of your code that are broken now. Also, if you do, you now have to reimplement all those tests that did nothing else than to check your call signatures. Ease of refactoring is a major indicator for a good enterprise language, as constant refactoring is basically the main development process. If your devs are afraid to touch certain pieces of code because nobody knows what the ramifications are, your software is already dying. That's why TypeScript is taking off so nicely. People crave those static guarantees that JS doesn't have.
- gbuk2013 7y ago
  When you have reached the stage of mud-ball it is already too late. ;) With the appropriate amount of skill and discipline, however, this stage can be postponed for longer than the life of the application. Typescript is absolutely not required.
  - adimitrov 7y ago
    But that's a truism. Good coders write good code. Heureka! The real gain is to be had in pushing the mudball stage as far into the product's life cycle in absolute terms as possible. In that sense, nothing is required, but some things help. I argue that TypeScript helps.
    - gbuk2013 7y ago
      If it helps you, great. I’m happy enough with plain JS, thanks. ;)
- capableweb 7y ago
  I've seen exactly the same problems with large TypeScript codebases as the JavaScript codebases have. Refactoring becomes a hassle not because there is types or not, but because there are endless of useless unit tests testing implementation details, because the architecture is highly coupled in the wrong places and because little care was made when the architecture was dynamically created (because "agile" or what ever) without considerations. Having good and smarter tests helps more for ease of refactoring than having everything mapped to types. But I might just have seen bad examples of TypeScript codebases.
  - thrower123 7y ago
    Probably this is a side-effect of translating JS unit-testing techniques without adequate thought and reflection. I am sometimes amazed at the extent of trivial tests that do no more than double-check the compiler that I see from web developers that move up the stack.
    - capableweb 7y ago
      When I talk about shitty unit tests, I mean regardless of language (bad unit tests seems as prevalent in JavaScript, as TypeScript, as Ruby, as Python, Rust, Go and the list goes on)
gbuk2013 7y ago
It probably does apply to all languages, but I prefer to speak from experience, which in my case is mostly JS. Architecture and the related abstraction is definitely the hardest thing about programming in my experience, and what really separates good programmers from the bad. Loose types, pass by reference, near-limitless mutability, scoping rules (without “use strict” to save the day) and asynchronous nature of the things it is used for are some of the things that come to mind with JS. All of these are actually very powerful features that make it into the language I love, but care is definitely needed. ;)
- chrismorgan 7y ago
  Yeah, I really wouldn’t link it in any way to the language. It’s just mostly more obvious when it’s in JavaScript, because that’s associated with the user agent having to fetch the code and run it from scratch every time, and as a user you can more easily inspect where the time is going, compared with an app or backend processes, which are both much more opaque to the user. It’s more about architecture and discipline, and far, far more about simply caring about performance. (And larger teams make it much harder to care about performance.) For personal background in my firm agreement with capableweb, I work primarily in JavaScript professionally, tend to use Rust privately, and have used a variety of other languages and worked with both good and bad code bases (mostly good); and I care very much about performance.
  - gbuk2013 7y ago
    Don’t get me wrong, I actually love Javascript. I have written code in quite a few languages but JS is the one I am most productive and happy in by far (within the area of network services and web apps that I work in). It has also been very profitable. :) But the language has such a low threshold that it allows for incredible productivity while writing shitty code. But by the time you realise just what you have done (or someone else realised when they have to work on your codebase) its too late and it’s time for a rewrite. What makes JS special is how accessible it is and just how much mess you can make before reality bites. That said, I will take a Javascript mud-ball over an enterprise Java one any time! ;)
- 7y ago