4 ms·

>Really? There is no more "problem" with Node.js than there is a "problem" with any other platform. Javascript's type system really doesn't stand up well to sc

>Really? There is no more "problem" with Node.js than there is a "problem" with any other platform. Javascript's type system really doesn't stand up well to scrutiny. That's more crucial than you'd think - the type system is the foundation the rest of the language is built upon. I suspect this is partly why javascript cycles through technologies so often. The foundations are shaky.

lootsauce 10y ago
Is it a tradeoff or idiocy (bad idea)? Clearly you are in the "bad idea" camp. No worries, you can use TypeScript. Enjoy! (edited for clarity)
- Noseshine 10y ago
  > with Babel you can use TypeScript Be careful with throwing "idiocy" at otehrs when it seems you yourself don't even know what you are talking about. To write TypeScript you use... TypeScript (their compiler).
  - lootsauce 10y ago
    Thanks the Babel thing was incorrect, Typescript is separate. To clarify, I'm certainly not implying this person is an idiot. I'm saying, they lean toward thinking that the typing system is more of a bad idea (idiocy) than a valid tradeoff.
    - crdoconnor 10y ago
      Yes, that's accurate. I don't think typescript is necessarily the answer though. You don't fix the problems caused by weak implicit type casts with static typing, you do it by turning off weak implicit type casting and raising a lot more type errors.
- deleted 10y ago
  [deleted]
nostrademons 10y ago
It's dynamic typing with a prototype-based object model. This type system tends to be very good at iterating quickly and testing out many alternative approaches to solving a problem without committing to a data representation up-front. It tends to be pretty bad at communicating invariants to other programmers or nailing down APIs for other subsystems to build off. Small wonder, then, that the Node.js ecosystem tends to very good at iterating quickly and testing out many alternative approaches to solving a problem, and pretty bad at communicating invariants to other programmers or providing a stable API for other programs to build off. You tend to get what you ask for.
- crdoconnor 10y ago
  There exist strongly typed dynamic languages that are good at both.
  - nostrademons 10y ago
    Examples? If you're about to say one of SmallTalk/Lisp/Python/Ruby, then no, they are good at prototyping but have all the pitfalls of Javascript when used on large teams. If you're about to say one of Java/Go, then no, you give up a lot of prototyping flexibility for their explicitness.
    - crdoconnor 10y ago
      >Python/Ruby, then no, they are good at prototyping but have all the pitfalls of Javascript when used on large teams. No, they absolutely don't. >>> "1" + 1 Javascript: 11 Perl: 2 This is the kind of approach works ok for small programs. Where the code that does these implicit type casts isn't too buried. When it's buried 3 layers down in a dependency used by a dependency used by a dependency, you want this to happen instead: Python/Ruby: Type error
      - Terr_ 10y ago
        ... And? That's simply "not having unpredictable type-juggling." It does nothing to communicate invariants or guide API usage at design-time. Consider PHP, which does have some of those bizarre and frustrating conversions, yet at the same time it also has stuff like type-hints and interfaces that can be used for design-time checking.
vertex-four 10y ago
I really don't think that people have been coming up with new frameworks because you can add [1] to 5 and get nonsense. Javascript cycles through technologies quickly because web developers cycle through technologies quickly, and they do that because they get to work on greenfield projects with minimal expectation for them to be around in 5 years a lot. Check out all the different server side frameworks and infrastructure components that have been in vogue with web developers over the last decade. In comparison, people who aren't writing consumer-facing websites and webapps tend to have much more clearly-defined goals, longer lifespans of their apps, and don't often get the choice to use anything but industry standard technology. Because of the slower cycle, there's less opportunity to redesign frameworks and core technologies even when it's allowed.
- crdoconnor 10y ago
  >I really don't think that people have been coming up with new frameworks because you can add [1] to 5 and get nonsense. There's plenty more nonsense where that came from. That's just an easy to understand, concrete and obviously stupid example. >Check out all the different server side frameworks and infrastructure components that have been in vogue with web developers over the last decade. In python it's mainly been django and flask for a decade. In Ruby it's mainly been Rails. Why do they have sticking power? It's partly cultural but it's largely because they were built on far more stable foundations.
  - vertex-four 10y ago
    In web frameworks, over the past decade, we've had various PHP frameworks, Zope, Ruby on Rails, Django, a variety of microframeworks in various scripting languages, Play, node.js+express in a handful of configurations (though generally MVC-ish), and Phoenix. There's very likely more that I'm forgetting. In deployment, we've gone from SFTP scripts to Fabric-like software to PaaS to configuration management software to Docker, and then it seems every 6 months there's a different preferred way to make Docker do something useful. And of course there's the eternal argument over whether to deploy to VPSes, cloud platforms, or bare-metal hardware. The "hip" web companies at any given moment - the ones who need the latest and greatest components to impress investors and attract "rockstar" "10x" developers - aren't tied to any specific language. They'll pick whatever was the most popular at the time they needed to pick something. Hence, right now, you have a whole lot of companies building on Golang and node.js, where they'd've been building on RoR five years ago.

lootsauce 10y ago

Is it a tradeoff or idiocy (bad idea)? Clearly you are in the "bad idea" camp. No worries, you can use TypeScript. Enjoy! (edited for clarity)

Noseshine 10y ago
> with Babel you can use TypeScript Be careful with throwing "idiocy" at otehrs when it seems you yourself don't even know what you are talking about. To write TypeScript you use... TypeScript (their compiler).
- lootsauce 10y ago
  Thanks the Babel thing was incorrect, Typescript is separate. To clarify, I'm certainly not implying this person is an idiot. I'm saying, they lean toward thinking that the typing system is more of a bad idea (idiocy) than a valid tradeoff.
  - crdoconnor 10y ago
    Yes, that's accurate. I don't think typescript is necessarily the answer though. You don't fix the problems caused by weak implicit type casts with static typing, you do it by turning off weak implicit type casting and raising a lot more type errors.
deleted 10y ago
[deleted]

nostrademons 10y ago

It's dynamic typing with a prototype-based object model. This type system tends to be very good at iterating quickly and testing out many alternative approaches to solving a problem without committing to a data representation up-front. It tends to be pretty bad at communicating invariants to other programmers or nailing down APIs for other subsystems to build off. Small wonder, then, that the Node.js ecosystem tends to very good at iterating quickly and testing out many alternative approaches to solving a problem, and pretty bad at communicating invariants to other programmers or providing a stable API for other programs to build off. You tend to get what you ask for.

crdoconnor 10y ago
There exist strongly typed dynamic languages that are good at both.
- nostrademons 10y ago
  Examples? If you're about to say one of SmallTalk/Lisp/Python/Ruby, then no, they are good at prototyping but have all the pitfalls of Javascript when used on large teams. If you're about to say one of Java/Go, then no, you give up a lot of prototyping flexibility for their explicitness.
  - crdoconnor 10y ago
    >Python/Ruby, then no, they are good at prototyping but have all the pitfalls of Javascript when used on large teams. No, they absolutely don't. >>> "1" + 1 Javascript: 11 Perl: 2 This is the kind of approach works ok for small programs. Where the code that does these implicit type casts isn't too buried. When it's buried 3 layers down in a dependency used by a dependency used by a dependency, you want this to happen instead: Python/Ruby: Type error
    - Terr_ 10y ago
      ... And? That's simply "not having unpredictable type-juggling." It does nothing to communicate invariants or guide API usage at design-time. Consider PHP, which does have some of those bizarre and frustrating conversions, yet at the same time it also has stuff like type-hints and interfaces that can be used for design-time checking.

vertex-four 10y ago

I really don't think that people have been coming up with new frameworks because you can add [1] to 5 and get nonsense. Javascript cycles through technologies quickly because web developers cycle through technologies quickly, and they do that because they get to work on greenfield projects with minimal expectation for them to be around in 5 years a lot. Check out all the different server side frameworks and infrastructure components that have been in vogue with web developers over the last decade. In comparison, people who aren't writing consumer-facing websites and webapps tend to have much more clearly-defined goals, longer lifespans of their apps, and don't often get the choice to use anything but industry standard technology. Because of the slower cycle, there's less opportunity to redesign frameworks and core technologies even when it's allowed.

crdoconnor 10y ago
>I really don't think that people have been coming up with new frameworks because you can add [1] to 5 and get nonsense. There's plenty more nonsense where that came from. That's just an easy to understand, concrete and obviously stupid example. >Check out all the different server side frameworks and infrastructure components that have been in vogue with web developers over the last decade. In python it's mainly been django and flask for a decade. In Ruby it's mainly been Rails. Why do they have sticking power? It's partly cultural but it's largely because they were built on far more stable foundations.
- vertex-four 10y ago
  In web frameworks, over the past decade, we've had various PHP frameworks, Zope, Ruby on Rails, Django, a variety of microframeworks in various scripting languages, Play, node.js+express in a handful of configurations (though generally MVC-ish), and Phoenix. There's very likely more that I'm forgetting. In deployment, we've gone from SFTP scripts to Fabric-like software to PaaS to configuration management software to Docker, and then it seems every 6 months there's a different preferred way to make Docker do something useful. And of course there's the eternal argument over whether to deploy to VPSes, cloud platforms, or bare-metal hardware. The "hip" web companies at any given moment - the ones who need the latest and greatest components to impress investors and attract "rockstar" "10x" developers - aren't tied to any specific language. They'll pick whatever was the most popular at the time they needed to pick something. Hence, right now, you have a whole lot of companies building on Golang and node.js, where they'd've been building on RoR five years ago.