5 ms·

Mind sharing why you consider node.js and other server-side javascript tools irrational?

radicalbyte 10y ago
For APIs the lack of typing hurts; only that is now no argument because it is fixed by TypeScript / Babel. Performance? That is a good reason, but again if you actually pay attention to defining (and testing) your APIs that is in most cases a solved problem - use a fast language for performance sensitive endpoints. Team's lack of knowledge? That's the only real argument. But that works both ways. If you have a team of experienced Node/JS developers then it would be foolish to implement your backend in Java (given no other constraints).
- Sanddancer 10y ago
  I would not call TypeScript/Babel making it a non-argument, because those two are separate languages that are compiled to Javascript. The language itself still has those limitations, you're just hiding it under the rug. Regarding performance, your solution means that in order to understand your site, you need to understand another language and javascript now. At which point, why swap between languages and mindsets when the other language can already do everything javascript does, plus gives you a performance edge? With the knowledge pool, it really does depend on the sort of application you're making, and how much code is reused and where. If your application has a web-based, and desktop/mobile app, you may very well be better off coding the entire thing in a language more amenable to native compilation. Knowledge-wise, and long-term developer comfort-wise, Javascript's fast churn is problematic. When big packages' idea of long-term support is three years or less, you're going to be spending a lot of engineering time rewriting your code just to keep things from collapsing into a bug-ridden insecure heap. Examples like Angular.JS show just how brittle the javascript environment is, and how difficult it's going to be to keep a site maintained.
  - flor1s 10y ago
    Programming languages in general hide the limitations of machine code under the rug. Regarding performance, why don't we write our web applications in C++, Rust or Go? There is a lot of churn in front-end frameworks, but for back-end frameworks the ecosystem is more stable (I like ExpressJS, which is like the Rails for NodeJS). If you factor your architecture correctly (e.g. separate your domain model from your views), you can also switch a bit easier between front-end frameworks.
    - ketpat 10y ago
      Isn't it more like the sinatra for nodejs?
    - ketpat 10y ago
      Isn't it more like the sinatra for nodejs?
intrasight 10y ago
Because you have the option of using first-class, enterprise-ready languages like C# and Java
mahyarm 10y ago
Unless your project is small (like under 10-20k lines), why use node when you can use a typed language? Javascript is a mess and if I'm server side and using something dynamic, I might as well use something nicer like ruby or python.
- z3t4 10y ago
  Types are low level. JavaScript is very high on the stack, and has no concept of types, it only has "value objects" (variable values: string and number, plus static values: true, false, null, undefined) and "normal objects" (Array, Object, Date, Function, etc). There's a debate though on what type should be used for numeric values in JavaScript. In JavaScript you rarely see getters and setters, as you do not need any abstraction over the type system, although it is possible to do bitwise operations, so if you want to you could make your own types, although you will not have full control of their binary representation, witch you would need a "real" programming language with a proper type system, but I've only seen that in optimization witch rarely runs faster then native JS. You get a lot of productivity by not having to worry about types in JS, and you rarely se buffer overflows witch is common in lower level languages such as C and C++. JavaScript is an an abstraction where you do not have to worry about the under-layer like imperative memory management. If you have to decide between small int vs big int vs floats, it's a leaky abstraction. JavaScript is one level above that.
  - tscs37 10y ago
    You seem to assume that A) Types are low level B) C++ and C are the only competition to JavaScript C) Not having to worry about types makes you faster or in any way better A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case) B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks but Regex matching -> https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Furthermore, Go is statically linked which means deploying to production is a simple scp operation to drop the binary. Lastly, Go is opinionated on how you write programs, you will write programs that are scalable simply because of how simple goroutines are, using channels you can utilize asynchronous execution as you would in node.js but also utilize all available cores without having to think about threads or synchronization. Just pipe data through the channel! C) Is a red herring, depending on who you ask it's either opinion or static typing being "better". http://danluu.com/empirical-pl/ http://danluu.com/empirical-pl/ Some studies indicate that it does not matter, some indicate faster development but more bugs for no types and others indicate less bugs and slightly longer development for types. IMO Types are good. I want to worry about the types because when I receive user input I can be sure that once parsed it's 100% an int or a float or it fits in a certain struct. For the same reason I think relational databases are better than document stores, they ensure that my data is valid. I don't have to write as much validation logic. It is sufficient to know that my function has been passed an int-type, I don't have to check if it's nil or a string.
flukus 10y ago
Because there are and always have been better options.
slowmotiony 10y ago
Because when asked if (9999999999999999 == 10000000000000000), they return true.
- tscs37 10y ago
  This is why types are nice. In Javascript you're not ensured to have an error, your program might continue working based on wrong data because some type has been randomly converted to a float. In Go or C# you'd get an overflow error if the type is an int or you know it's a float and you get inaccuracy, if you need the accuracy you use a decimal type which will also ensure that any result is always of it's type. Typed languages mean I cannot loose data accuracy without explicitly doing so. I have to tell Go that I want this uint64 as uint8 otherwise it's an error.

For APIs the lack of typing hurts; only that is now no argument because it is fixed by TypeScript / Babel. Performance? That is a good reason, but again if you actually pay attention to defining (and testing) your APIs that is in most cases a solved problem - use a fast language for performance sensitive endpoints. Team's lack of knowledge? That's the only real argument. But that works both ways. If you have a team of experienced Node/JS developers then it would be foolish to implement your backend in Java (given no other constraints).

Sanddancer 10y ago
I would not call TypeScript/Babel making it a non-argument, because those two are separate languages that are compiled to Javascript. The language itself still has those limitations, you're just hiding it under the rug. Regarding performance, your solution means that in order to understand your site, you need to understand another language and javascript now. At which point, why swap between languages and mindsets when the other language can already do everything javascript does, plus gives you a performance edge? With the knowledge pool, it really does depend on the sort of application you're making, and how much code is reused and where. If your application has a web-based, and desktop/mobile app, you may very well be better off coding the entire thing in a language more amenable to native compilation. Knowledge-wise, and long-term developer comfort-wise, Javascript's fast churn is problematic. When big packages' idea of long-term support is three years or less, you're going to be spending a lot of engineering time rewriting your code just to keep things from collapsing into a bug-ridden insecure heap. Examples like Angular.JS show just how brittle the javascript environment is, and how difficult it's going to be to keep a site maintained.
- flor1s 10y ago
  Programming languages in general hide the limitations of machine code under the rug. Regarding performance, why don't we write our web applications in C++, Rust or Go? There is a lot of churn in front-end frameworks, but for back-end frameworks the ecosystem is more stable (I like ExpressJS, which is like the Rails for NodeJS). If you factor your architecture correctly (e.g. separate your domain model from your views), you can also switch a bit easier between front-end frameworks.
  - ketpat 10y ago
    Isn't it more like the sinatra for nodejs?
  - ketpat 10y ago
    Isn't it more like the sinatra for nodejs?

intrasight 10y ago

Because you have the option of using first-class, enterprise-ready languages like C# and Java

mahyarm 10y ago

Unless your project is small (like under 10-20k lines), why use node when you can use a typed language? Javascript is a mess and if I'm server side and using something dynamic, I might as well use something nicer like ruby or python.

z3t4 10y ago
Types are low level. JavaScript is very high on the stack, and has no concept of types, it only has "value objects" (variable values: string and number, plus static values: true, false, null, undefined) and "normal objects" (Array, Object, Date, Function, etc). There's a debate though on what type should be used for numeric values in JavaScript. In JavaScript you rarely see getters and setters, as you do not need any abstraction over the type system, although it is possible to do bitwise operations, so if you want to you could make your own types, although you will not have full control of their binary representation, witch you would need a "real" programming language with a proper type system, but I've only seen that in optimization witch rarely runs faster then native JS. You get a lot of productivity by not having to worry about types in JS, and you rarely se buffer overflows witch is common in lower level languages such as C and C++. JavaScript is an an abstraction where you do not have to worry about the under-layer like imperative memory management. If you have to decide between small int vs big int vs floats, it's a leaky abstraction. JavaScript is one level above that.
- tscs37 10y ago
  You seem to assume that A) Types are low level B) C++ and C are the only competition to JavaScript C) Not having to worry about types makes you faster or in any way better A) is simply refuted by looking at java or SQL. SQL is a very high-level language compared to other stuff, yet it's heavily typed simply to ensure that data is either valid or the query fails (SQL Injection is still valid data in this case) B) Take a look at Go. It's blazing fast. It beats Node.js in all benchmarks but Regex matching -> https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... Furthermore, Go is statically linked which means deploying to production is a simple scp operation to drop the binary. Lastly, Go is opinionated on how you write programs, you will write programs that are scalable simply because of how simple goroutines are, using channels you can utilize asynchronous execution as you would in node.js but also utilize all available cores without having to think about threads or synchronization. Just pipe data through the channel! C) Is a red herring, depending on who you ask it's either opinion or static typing being "better". http://danluu.com/empirical-pl/ http://danluu.com/empirical-pl/ Some studies indicate that it does not matter, some indicate faster development but more bugs for no types and others indicate less bugs and slightly longer development for types. IMO Types are good. I want to worry about the types because when I receive user input I can be sure that once parsed it's 100% an int or a float or it fits in a certain struct. For the same reason I think relational databases are better than document stores, they ensure that my data is valid. I don't have to write as much validation logic. It is sufficient to know that my function has been passed an int-type, I don't have to check if it's nil or a string.

flukus 10y ago

Because there are and always have been better options.

slowmotiony 10y ago

Because when asked if (9999999999999999 == 10000000000000000), they return true.

tscs37 10y ago
This is why types are nice. In Javascript you're not ensured to have an error, your program might continue working based on wrong data because some type has been randomly converted to a float. In Go or C# you'd get an overflow error if the type is an int or you know it's a float and you get inaccuracy, if you need the accuracy you use a decimal type which will also ensure that any result is always of it's type. Typed languages mean I cannot loose data accuracy without explicitly doing so. I have to tell Go that I want this uint64 as uint8 otherwise it's an error.