7 ms·

So basically, I just just stay far and away from anything javascript now; not just node.js. Got it. This can't end well anyway; javascript itself is a client s

by cremp 8y ago

So basically, I just just stay far and away from anything javascript now; not just node.js. Got it. This can't end well anyway; javascript itself is a client side language, and node, using the same language, made it server side. That's been my whole gripe with Node in the first place, because you're taking a tool (square,) and force-fitting it into a round hole.

nebulous1 8y ago
node.js came into existence because it turned out that it was particularly apt for server side programming, not because it was force fitted into it.
- aaronblohowiak 8y ago
  A belief that it’s creater later discovered was in err.
  - Nadya 8y ago
    Ryan Dahl has only spoken about implementation details and poor decisions made at the start that are too far along to correct now. He says Go is better than Node, not Javascript. If Javascript-as-a-server was a mistake then Ryan would not be working on Deno [0]. I just hope that the use of Py2 and having to stick with it doesn't bite them in the ass past 2020 [1]. With the caveat of my argument assuming "Typescript is a superset of Javascript." [0] https://github.com/denoland/deno https://github.com/denoland/deno [1] https://github.com/denoland/deno/issues/464#issuecomment-411795578 https://github.com/denoland/deno/issues/464#issuecomment-411...
    - nebulous1 8y ago
      I don't see (from that issue, this is the first I've heard of it) that they "have to stick with it". They're saying they won't try to move to python 3 until the V8 build does. Seems pretty reasonable to me.
    - aaronblohowiak 8y ago
      https://mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/ https://mappingthejourney.com/single-post/2017/08/31/episode... >That said, I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node. It was the realization that: oh, actually, this is not the best server side system ever.
      - Nadya 8y ago
        Node is not JavaScript. E: To clarify on this a little since I'm not posting from a phone. Which means he's still using Javascript-as-a-server (Deno), so he obviously still has some faith in using Javascript-as-a-server. Go > Node, in his opinion, but that says nothing about Go > Javascript.
  - nebulous1 8y ago
    Oh? Is that why he's still at it to this very day? https://github.com/denoland/deno https://github.com/denoland/deno
    - aaronblohowiak 8y ago
      Iiuc, his goal for this is to create a better experience for one off exploratory stuff, not for evented servers. http://tinyclouds.org/jsconf2018.pdf http://tinyclouds.org/jsconf2018.pdf
      - nebulous1 8y ago
        well, from that document: > My problems with Node are almost entirely around > how it manages user code. > In contrast to the focus on evented I/O early on, > the module system was essentially an afterthought > With this in mind, I have long thought about how it > could be done better....
- pjmlp 8y ago
  Actually it was more because it allowed JavaScript developers to do server side programming. I still don't see what it offers against .NET, Java, C++, OCaml, Haskell stacks, and their concurrency options.
  - EB66 8y ago
    It's a combination of both. The event loop and non-blocking I/O are inherent in JavaScript. The language lends itself very well to scalable server-side programming.
    - pjmlp 8y ago
      There are plenty of event loop and non-blocking I/O libraries for the languages I have mentioned.
      - EB66 8y ago
        Yep, that's true. However, JavaScript does it right out of the box and the JavaScript ecosystem is very well-aligned for async. One of the most significant reasons to use a language like Node for server-side async programming is that for any random library you choose to use there's a very high probability the library also supports async and won't block on you. For better or for worse, async is pervasive in the JavaScript ecosystem. Even languages that have good async frameworks, like Python, most libraries will block as it's the normal I/O mode for the language.
    - forgotpwd16 8y ago
      How are event loop and non-blocking I/O inherent in JavaScript?
  - hajile 8y ago
    Ocaml has no concurrency options worth mentioning (need to look to PolyML/SML or F# for that). Finding and teaching Haskell devs simply isn't feasible. C++ is way too low-level for most of the work that someone choosing node would be doing. It turns out that most of the reasons a server needs threads is IO. With node, any IO is moved to a new thread, so you get most of the threading benefits, but are completely safe (provided libuv is safe). Another consideration is JS being dynamic. It's very easy to create extremely flexible APIs and you can move very fast adding features without breaking things. While That SML or F# app will provide much better type guarantees (and somewhat better performance), those benefits simply don't pay off for a lot of projects. There's also something to be said for functional vs OOP styles. You will never see a JS dev writing enterprise fizzbuzz. Even in very large projects, those layers of boilerplate abstraction simply won't exist. Part of that is being dynamic and part is being functional.
- cremp 8y ago
  > apt for server side programming Except what part is that? Having to download 4 or 5 projects to build, compile, and run 'basic' pages is too much bloat; not to mention the dependency hell. It more and more seems to me like node was made 'because we can' instead of providing something. This can be seen with all of the cruft required; a lot made as an after-thought. Package manager, npm; which itself has proven that... it wasn't designed too well. The reliance of it creates the cruft. Add in the fact that a web server shouldn't be event driven. I (personally) haven't seen any other language do an event-driven web; and I'd say, for good reason (callback hell.) Javascript itself is okay because it's a requirement today for web pages to the average joe. However, if the Javascript foundation is merging; it'll their motto to use it (Node.)
  - hajile 8y ago
    I've used ruby, java, python, etc and all of them require a decent amount of dependencies to get a server up and running. Likewise, dependency hell is an issue in lots of languages. The company I'm with has legacy dependency issues with their Java. They have pip dependency issues with Python. The front-end testers learned JS and left ruby simply because they couldn't get their tooling installed on another machine without a couple days work (turned out JS was easier to maintain and faster too). Yarn exists and solves the major issues NPM had (though they seem to be improving as well). EventMachine or twisted are two event-based servers (ruby and python) with some level of popularity. The big issue with them is every library you reach for has blocking code everywhere, so actually making it work is painful. Promises eliminated callback hell years ago for most of us. Koa/generators eliminate most of the rest as well. On the flip side, JS as a language is rapidly evolving and node is a serious consideration when adding new features. Node as an implementation is extremely fast and I doubt that there's another scripting language that comes anywhere close to its combination of performance, size, memory usage, startup time, etc.
sephware 8y ago
Nonsense. JavaScript is a general programming language that's suitable for many different kinds of environments. It just so happens to have started in the browser, but it could just as easily be embedded like Lua, or ran on the server like Python, or be used for shell scripting like Perl, and even used in embedded devices like mruby.
- anonytrary 8y ago
  Javascript's best feature is also its worst. The single-threaded event loop makes async programming incredibly simple (e.g. no race conditions), but it is also a limitation in performance. AFAIK node's worker/cluster solution is much slower than Go's solution for multiple threads...
  - sephware 8y ago
    That's not an inherent limitation of the language though. There's nothing stopping a server-side implementation from adding threads as a first-class feature and breaking away from the spec. Ideally it would do so in a way that's backwards compatible with libraries that assume they're on the same thread as themselves, but that isn't infeasible.
    - anonytrary 8y ago
      > breaking away from the spec. At that point, creating a new language is just as likely. I love Javascript, even though it gets tons of flak, but I do accept that Go is probably a better server solution for people who need performance as a top priority.
Mister_Snuggles 8y ago
Honestly, I don't like JavaScript, but this isn't a terribly good argument against it. There are many things to criticize about the language itself and its ecosystem, but the fact that it started as a client-side language is not one of them.
- type0 8y ago
  > There are many things to criticize about the language itself What are the main critiques of javascript? Genuinely curious, would like to hear from people that use or used it to build real projects.
  - dx87 8y ago
    I haven't done any big projects with it, but I did use it for making a Firefox extension to archive sites. My biggest issue with it was the unpredictable way it would handle syntax errors, and how things were handled wasn't documented anywhere that I could find, you just kind of had to figure it out and remember for later. For example, depending on the function, passing the wrong number of arguments could 1). Cause the script to silently terminate 2).Cause the script to terminate with an error message 3).Execute the invalid function without mentioning the error, then return garbled output 4). Emit an error, skip the invalid function, but continue trying to execute the rest of the script. It was frustrating enough to turn me off using languages that don't have compile time type checking.
    - gnfurlong 8y ago
      Passing the "wrong" number of arguments isn't a syntax error in JavaScript. If you pass fewer arguments than declared parameters, the rest are implicitly undefined. The variations you were seeing probably just came down to how the invoked function handled that undefined value. I can still understand how inconsistency in behavior there might be confusing.
  - Mister_Snuggles 8y ago
    I don't use JavaScript very much, so keep that context in mind. As far as JavaScript the language goes, my biggest complaints are to do with the sparse standard library (leftpad should be something easy to do with built-in string formatting functions[0], not a 3rd-party library), unexpected behaviour (the map/parseInt thing[1] being one example), etc. The unexpected behaviour stuff is truly a case of needing to understand the language - after all, why should JavaScript behave like Python? However, as someone who doesn't use JS much, these bits of weirdness make it more difficult to use when I need to. [0] https://docs.python.org/2/library/stdtypes.html#str.rjust https://docs.python.org/2/library/stdtypes.html#str.rjust - this is a Python example, but why doesn't JS have this in its stdlib? [1] https://wsvincent.com/javascript-parseint-map/ https://wsvincent.com/javascript-parseint-map/
deleted 8y ago
[deleted]
icebraining 8y ago
JavaScript has been server-side since the start; both the Netscape Enterprise Server and IIS supported it mere months after it first shipped on the Netscape browser.

by cremp 8y ago

nebulous1 8y ago

node.js came into existence because it turned out that it was particularly apt for server side programming, not because it was force fitted into it.

aaronblohowiak 8y ago
A belief that it’s creater later discovered was in err.
- Nadya 8y ago
  Ryan Dahl has only spoken about implementation details and poor decisions made at the start that are too far along to correct now. He says Go is better than Node, not Javascript. If Javascript-as-a-server was a mistake then Ryan would not be working on Deno [0]. I just hope that the use of Py2 and having to stick with it doesn't bite them in the ass past 2020 [1]. With the caveat of my argument assuming "Typescript is a superset of Javascript." [0] https://github.com/denoland/deno https://github.com/denoland/deno [1] https://github.com/denoland/deno/issues/464#issuecomment-411795578 https://github.com/denoland/deno/issues/464#issuecomment-411...
  - nebulous1 8y ago
    I don't see (from that issue, this is the first I've heard of it) that they "have to stick with it". They're saying they won't try to move to python 3 until the V8 build does. Seems pretty reasonable to me.
  - aaronblohowiak 8y ago
    https://mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/ https://mappingthejourney.com/single-post/2017/08/31/episode... >That said, I think Node is not the best system to build a massive server web. I would definitely use Go for that. And honestly, that's basically the reason why I left Node. It was the realization that: oh, actually, this is not the best server side system ever.
    - Nadya 8y ago
      Node is not JavaScript. E: To clarify on this a little since I'm not posting from a phone. Which means he's still using Javascript-as-a-server (Deno), so he obviously still has some faith in using Javascript-as-a-server. Go > Node, in his opinion, but that says nothing about Go > Javascript.
- nebulous1 8y ago
  Oh? Is that why he's still at it to this very day? https://github.com/denoland/deno https://github.com/denoland/deno
  - aaronblohowiak 8y ago
    Iiuc, his goal for this is to create a better experience for one off exploratory stuff, not for evented servers. http://tinyclouds.org/jsconf2018.pdf http://tinyclouds.org/jsconf2018.pdf
    - nebulous1 8y ago
      well, from that document: > My problems with Node are almost entirely around > how it manages user code. > In contrast to the focus on evented I/O early on, > the module system was essentially an afterthought > With this in mind, I have long thought about how it > could be done better....
pjmlp 8y ago
Actually it was more because it allowed JavaScript developers to do server side programming. I still don't see what it offers against .NET, Java, C++, OCaml, Haskell stacks, and their concurrency options.
- EB66 8y ago
  It's a combination of both. The event loop and non-blocking I/O are inherent in JavaScript. The language lends itself very well to scalable server-side programming.
  - pjmlp 8y ago
    There are plenty of event loop and non-blocking I/O libraries for the languages I have mentioned.
    - EB66 8y ago
      Yep, that's true. However, JavaScript does it right out of the box and the JavaScript ecosystem is very well-aligned for async. One of the most significant reasons to use a language like Node for server-side async programming is that for any random library you choose to use there's a very high probability the library also supports async and won't block on you. For better or for worse, async is pervasive in the JavaScript ecosystem. Even languages that have good async frameworks, like Python, most libraries will block as it's the normal I/O mode for the language.
  - forgotpwd16 8y ago
    How are event loop and non-blocking I/O inherent in JavaScript?
- hajile 8y ago
  Ocaml has no concurrency options worth mentioning (need to look to PolyML/SML or F# for that). Finding and teaching Haskell devs simply isn't feasible. C++ is way too low-level for most of the work that someone choosing node would be doing. It turns out that most of the reasons a server needs threads is IO. With node, any IO is moved to a new thread, so you get most of the threading benefits, but are completely safe (provided libuv is safe). Another consideration is JS being dynamic. It's very easy to create extremely flexible APIs and you can move very fast adding features without breaking things. While That SML or F# app will provide much better type guarantees (and somewhat better performance), those benefits simply don't pay off for a lot of projects. There's also something to be said for functional vs OOP styles. You will never see a JS dev writing enterprise fizzbuzz. Even in very large projects, those layers of boilerplate abstraction simply won't exist. Part of that is being dynamic and part is being functional.
cremp 8y ago
> apt for server side programming Except what part is that? Having to download 4 or 5 projects to build, compile, and run 'basic' pages is too much bloat; not to mention the dependency hell. It more and more seems to me like node was made 'because we can' instead of providing something. This can be seen with all of the cruft required; a lot made as an after-thought. Package manager, npm; which itself has proven that... it wasn't designed too well. The reliance of it creates the cruft. Add in the fact that a web server shouldn't be event driven. I (personally) haven't seen any other language do an event-driven web; and I'd say, for good reason (callback hell.) Javascript itself is okay because it's a requirement today for web pages to the average joe. However, if the Javascript foundation is merging; it'll their motto to use it (Node.)
- hajile 8y ago
  I've used ruby, java, python, etc and all of them require a decent amount of dependencies to get a server up and running. Likewise, dependency hell is an issue in lots of languages. The company I'm with has legacy dependency issues with their Java. They have pip dependency issues with Python. The front-end testers learned JS and left ruby simply because they couldn't get their tooling installed on another machine without a couple days work (turned out JS was easier to maintain and faster too). Yarn exists and solves the major issues NPM had (though they seem to be improving as well). EventMachine or twisted are two event-based servers (ruby and python) with some level of popularity. The big issue with them is every library you reach for has blocking code everywhere, so actually making it work is painful. Promises eliminated callback hell years ago for most of us. Koa/generators eliminate most of the rest as well. On the flip side, JS as a language is rapidly evolving and node is a serious consideration when adding new features. Node as an implementation is extremely fast and I doubt that there's another scripting language that comes anywhere close to its combination of performance, size, memory usage, startup time, etc.

sephware 8y ago

Nonsense. JavaScript is a general programming language that's suitable for many different kinds of environments. It just so happens to have started in the browser, but it could just as easily be embedded like Lua, or ran on the server like Python, or be used for shell scripting like Perl, and even used in embedded devices like mruby.

anonytrary 8y ago
Javascript's best feature is also its worst. The single-threaded event loop makes async programming incredibly simple (e.g. no race conditions), but it is also a limitation in performance. AFAIK node's worker/cluster solution is much slower than Go's solution for multiple threads...
- sephware 8y ago
  That's not an inherent limitation of the language though. There's nothing stopping a server-side implementation from adding threads as a first-class feature and breaking away from the spec. Ideally it would do so in a way that's backwards compatible with libraries that assume they're on the same thread as themselves, but that isn't infeasible.
  - anonytrary 8y ago
    > breaking away from the spec. At that point, creating a new language is just as likely. I love Javascript, even though it gets tons of flak, but I do accept that Go is probably a better server solution for people who need performance as a top priority.

Mister_Snuggles 8y ago

Honestly, I don't like JavaScript, but this isn't a terribly good argument against it. There are many things to criticize about the language itself and its ecosystem, but the fact that it started as a client-side language is not one of them.

type0 8y ago
> There are many things to criticize about the language itself What are the main critiques of javascript? Genuinely curious, would like to hear from people that use or used it to build real projects.
- dx87 8y ago
  I haven't done any big projects with it, but I did use it for making a Firefox extension to archive sites. My biggest issue with it was the unpredictable way it would handle syntax errors, and how things were handled wasn't documented anywhere that I could find, you just kind of had to figure it out and remember for later. For example, depending on the function, passing the wrong number of arguments could 1). Cause the script to silently terminate 2).Cause the script to terminate with an error message 3).Execute the invalid function without mentioning the error, then return garbled output 4). Emit an error, skip the invalid function, but continue trying to execute the rest of the script. It was frustrating enough to turn me off using languages that don't have compile time type checking.
  - gnfurlong 8y ago
    Passing the "wrong" number of arguments isn't a syntax error in JavaScript. If you pass fewer arguments than declared parameters, the rest are implicitly undefined. The variations you were seeing probably just came down to how the invoked function handled that undefined value. I can still understand how inconsistency in behavior there might be confusing.
- Mister_Snuggles 8y ago
  I don't use JavaScript very much, so keep that context in mind. As far as JavaScript the language goes, my biggest complaints are to do with the sparse standard library (leftpad should be something easy to do with built-in string formatting functions[0], not a 3rd-party library), unexpected behaviour (the map/parseInt thing[1] being one example), etc. The unexpected behaviour stuff is truly a case of needing to understand the language - after all, why should JavaScript behave like Python? However, as someone who doesn't use JS much, these bits of weirdness make it more difficult to use when I need to. [0] https://docs.python.org/2/library/stdtypes.html#str.rjust https://docs.python.org/2/library/stdtypes.html#str.rjust - this is a Python example, but why doesn't JS have this in its stdlib? [1] https://wsvincent.com/javascript-parseint-map/ https://wsvincent.com/javascript-parseint-map/

deleted 8y ago

[deleted]

icebraining 8y ago

JavaScript has been server-side since the start; both the Netscape Enterprise Server and IIS supported it mere months after it first shipped on the Netscape browser.