7 ms·

Node.js Overload

45 points by orange8 6y ago

nerdbaggy 6y ago
If somebodies primary language is JS I think node is a great choice. 9/10 times node performance will be just fine for what people are doing. Writing real multithreaded code without a GIL is hard. I would think just scaling horizontal or vertical would be easier. And doing threading in Python is so confusing for new beginners. There are about a million different ways to do it.
- hamburglar 6y ago
  > Writing real multithreaded code without a GIL is hard. I'm starting to think this is going to be a major dividing line in developer skill going forward -- those who can write threadsafe code and those who can't. There's an awful lot of Java, C# and Golang out there and if a programmer can't reliably think through thread safety issues (which is not that difficult in simple cases), they aren't capable in that realm. One of the most frustrating things about my brief excursion into the land of Ruby was that the community was full of modules written by people who had no reason whatsoever to think about thread safety because they were programming for Rails, not Ruby in general.
  - valand 6y ago
    > those who can write threadsafe code and those who can't This, abstracted, those who can write distributed software and those who can't yet. Dealing with shared resources is similar to dealing with shared memory if you zoom out a bit. We need more people to move from the latter group to the former, for reasons. The more people aware of distributed software and its challenges, the better.
  - jashmatthews 6y ago
    This sounds very gatekeepy. The JVM and Golang have additional aides for writing thread-safe code because writing multi-threaded code is fucking hard. People at the top of our field working on browsers or VMs regularly fuck up the simple stuff. If it was easy we wouldn't have Erlang or Rust.
    - hamburglar 6y ago
      I'm very gatekeepy about only wanting competent developers working on my code.
- jashmatthews 6y ago
  > Writing real multithreaded code without a GIL is hard. A GIL doesn't help developers. It only keeps the internal state of the VM consistent. You still need to to use locks, thread safe collections etc. That's one major reason why some people feel that OS threads + GIL is a poor trade-off. https://github.com/ruby-concurrency/concurrent-ruby#thread-safety https://github.com/ruby-concurrency/concurrent-ruby#thread-s...
  - nerdbaggy 6y ago
    Never knew that thanks!
- vertex-four 6y ago
  Writing multithreaded code without a GIL is hard, but there's really good workarounds for a lot of cases. For example, Boost ASIO's "strand" pattern. You can define a set of coroutines that never run concurrently, so synchronization is much easier, while you can have many strands. I use this model in some of my Rust code - I associate clients to a producer, meaning I don't have to work out a suitable contention-free bus. This is essentially equivalent to running N single-threaded processes, except that when I do have to share data across the system (e.g. a database connection pool), or if the lifecycle of the client crosses multiple strands, I have more tools in my toolkit.
orange8 6y ago
It cites the reasons for Node overload as: - The convenience of using the same language in the client and server - The speed of Node.js It unfortunately does not state why it shouldn't be used in the server, or offer any more suitable alternatives.
- arcturus17 6y ago
  Well it does mention that its single-threaded nature makes it a poor choice for heavy compute workloads, which I agree with. I also think it’s fine for pretty much everything else.
  - zumachase 6y ago
    I'm not sure I would agree with this. As with all things, it depends on the task, but "compute heavy" these days means likely working with a distributed framework that abstracts away the underlying process architecture, letting the user define lambda-esque tasks which are deployed across a stream/batch processing model. I think a much better critique would be that the lack of fine grained primitives, and the surrounding ecosystem, are not the best choice for compute heavy tasks.
    - arcturus17 6y ago
      It doesn’t have multithreading, period. You can compute in parallel and work around it by using serverless functions or worker threads or whatever, but often it feels like you’re going against the grain and/or reinventing the wheel. I definitely see the merit in preferring another language with a clear, native multithreading model - and with perhaps significantly better general performance to boot. If anything, the critique in my opinion misses how the Node web frameworks tend to be really unopinionated and non-prescriptive which can be great for some teams and projects but really bad for others (they do mention that NestJS is a technology to watch and that they use it widely, so I actually think they’re of the same opinion)
- manojlds 6y ago
  Not sure if you read it fully or not: > When Node.js became popular, it was the first major framework to embrace a nonblocking programming model which made it very efficient for IO-heavy tasks. (We mentioned this in our write-up of Node.js in 2012.) Due to its single-threaded nature, Node.js was never a good choice for compute-heavy workloads, though, and now that capable nonblocking frameworks also exist on other platforms — some with elegant, modern APIs — performance is no longer a reason to choose Node.js.
orliesaurus 6y ago
So what does HN think are the downsides of using Node, the article didn't really state them explicitly?
- tuananh 6y ago
  maintenance ability. building any big system with node is just difficult. typescript helps a bit but it's no where close near a statically-typed language
  - mb7733 6y ago
    Under what definition is typescript not statically typed?
    - joking 6y ago
      In the one that it is statically typed on compile time, but what gets executed is not because the javascript vm is not statically typed.
      - filleduchaos 6y ago
        What you might be trying to say is that TypeScript is not _strongly_ or _soundly_ typed. "Only statically typed at compile time" is a meaningless statement because "checks types at compile time" is the whole definition of static typing.
      - gwillz 6y ago
        The JVM also does erasure of generics. Yes, it's not _all_ types but it too relies heavily on compile time typings.
      - valand 6y ago
        ^ I see that you're not joking with this comment :D. Jokes aside, I'm adding facts TypeScript is statically typed because of the type annotations and how the compiler checks the type compatibility between objects. You may can consider TypeScript weakly-typed, because the TypeScript type information are not being encoded into the compilation result. This is similar to C (being staticcally and weakly typed). You can print int as string and the compiler won't complain. On the other hand, JavaScript is a dynamically typed and strongly typed language. It is strong as the types are encoded in the runtime. The proof is the keyword `typeof` and its ability to do Reflection. Reference: Static vs Dynamic: https://en.wikipedia.org/wiki/Type_system#Type_checking https://en.wikipedia.org/wiki/Type_system#Type_checking Strong vs Weak: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing
Mulpze15 6y ago
I am an intermittent developer, because I need to sell, and manage my (small) business too. In my case, using javascript on the front end and PHP in the back, and as a scripting language for servers was frustrating. Function names are always slightly so different... I increased my productivity and my fun tremendously when I switched to Node on the backend. Sometimes I am thinking about using Python for computer vision stuff. Nope... Everything Javascript, so much better for my sanity.
- shock 6y ago
  For a bit of unconventional (intellectual) fun, you can imagine your post as being about cooking and food instead of programming and programming languages. Something like: "I was an intermittent cook, because I need to sell, and manage my (small) business too. In my case, cooking both soups and main courses, and some deserts occasionally was frustrating. Cooking times are always slightly different... I increased my productivity and my fun tremendously when I switched to only eating polenta." I hope this does not come off as offensive, which was not my intention, instead, I hope this serves as food(pun intended) for thought and reflection.
  - pavlov 6y ago
    I’m not sure that’s the right analogy for using different programming languages in different parts of the stack. A back-end API looks the same to its consumer regardless of whether it’s written in PHP or Node or Haskrustapl. Maybe the analogy would be: “I was using three different kinds of butter in my kitchen. I switched to just one brand. Turns out it didn’t make a difference in taste, yet saves me effort and money because I can buy larger quantities of the ingredient.”
    - valand 6y ago
      > A back-end API looks the same to its consumer regardless of whether it’s written in PHP or Node or Haskrustapl. It looks looks the same to its consumer, but it will feel different when under pressure. I've experienced React SSR server (I know this is heavy) not able to withstand traffic when pushed to only tens of concurrent users, reaching only 1000ish RPS even after being clustered. I'm not opposed to NodeJS though. I've learnt a lot of it and I've ever been a NodeJS fanboy for like 2 years-ish. PS: I also increased my productivity too moving from PHP to NodeJS back then years ago.
mmkos 6y ago
The snippet about Node is confusing terminology. Node is not a framework, it's a runtime environment in which JS can run. It makes a mention of other "capable nonblocking frameworks", but is conveniently vague about which ones. The argument about compute heavy workload also feels orthogonal to the whole issue of Node on the backend.
zaro 6y ago
> Due to its single-threaded nature, Node.js was never a good choice for compute-heavy workloads, though, and now that capable nonblocking frameworks also exist on other platforms — some with elegant, modern APIs — performance is no longer a reason to choose Node.js. But do these other frameworks give you the simplicity of sharing code and using the same language in for fe and be ? For me the performance of Node BE applications is just a nice bonus, for having consistent development environment with huge library of radily available packages.
- Kuinox 6y ago
  A lot of langage have work in progress and or working GUI framework compiling to webassembly. So yes. And you know what ? You shouldn't share too much code between backend and frontend. The packages are node disavantage. You depends on too much packages it's a security risk.
  - zaro 6y ago
    > And you know what ? You shouldn't share too much code between backend and frontend. Yeah right :) I'll tell you what I like about it. I defined my database models in Typescript[1], work with them in the backend, send them to the frontend, and deserialize them back to the same Typescipt model classes in the browser and continue working with them ( w/o the actual database part) as data structures. Are you trying to convince me this is bad ? Because I definitely don't believe you :) [1] https://typeorm.io/ https://typeorm.io/
    - Kuinox 6y ago
      That exactly what you shouldn't do, database models should not be the same models than the one sent to the client.
  - zumachase 6y ago
    Any examples? Given that WASM can't manipulate the DOM, I'm suspicious of this claim.
29athrowaway 6y ago
If you don't understand the node event loop, don't use node.
- deleted 6y ago
  [deleted]
kumarvvr 6y ago
While having one language on the front end and back end might seem like less of a burden, the cognitive context for both of them are very different. Reasoning about the backend feels much easier in languages like C# and even python. Because the majority of the code in the backend is about data storage, retrieval, data modeling, rich and complex business logic, etc. While on the front end, the focus is usually on data binding, immutable structures, etc. JS in react is fine and in my view, for the notion of same language everywhere, JS is a poor language.
ajeet_dhaliwal 6y ago
If you are more productive using Node.js for back-end and React/other JS framework for front-end then don't worry about it and go ahead. Especially so for a small business with few development resources. The performance issues can be tackled when they arise and in in some areas you could use addons or even just break down some work into another service/micro service using Java or whatever. The productivity benefits can be massive and that's usually the bigger issue if you're creating a general web/service. I work on tesults.com and it's all JS.
skrebbel 6y ago
I'd like to add some context for those not aware. This is a page in Thoughtworks' "Technology Radar". Thoughtworks is a global US-based software agency that likes to market themselves as thought leaders in the world of software. They're not super well known in startup land but my impression is that in enterprisy environments they're considered "very good". One way they maintain this image of thought leadership is employing famous people such as Martin Fowler. Another way is by regularly publishing a document called "Technology Radar" which is in opinionated list of technologies that their tech leadership believes ought to be used, explored, avoided, etc. They explicitly don't position it as a bunch of truths they hold to be absolute - it's just the opinion of a few senior tech folks at Thoughtworks who had a fun weekend in a holiday house together or something like that. I guess they had a disappointing Zoom call this time around. It's generally a bit more conservative than HN, you often only see stuff listed under "Assess" that has been commonplace in HN articles for multiple years. This makes sense, it's targeted at enterprises. At the same time, it's highly opinionated and they're not afraid to take positions that are not a match with the current hype cycle. I really like it for this latter quality, and I encourage you to explore this edition further than just their recommendation to not always jump to NodeJS by default (which seems to be a bit of a straw man to me, anyway). Be sure to click all four "quadrants" (right top of the page), IMO the linked one, "Platforms", is the least interesting one.
js4ever 6y ago
I have adopted node (over .Net C#) several years ago and the main reason was NPM and the 1 million packages available. About performances ... With Workers it's pretty good, I'm doing 700k RPS with node on 1 server. Refs: https://vms2.terasp.net/ https://vms2.terasp.net/ https://github.com/elestio/cloudgate https://github.com/elestio/cloudgate
- romanovcode 6y ago
  If you felt comfortable with C# you should try .NET Core. It's amazing.
  - js4ever 6y ago
    True, but NPM vs Nugget ... Still the same story
  - wayneftw 6y ago
    I have and I found C# to be somewhat painful compared to JS in some respects, but good in other ways. There are a lot of little conveniences that are missing. There is no destructuring, no first-class functions (i.e. can’t declare functions outside of a class), no easy way to loop over properties of a class and access their values, no spread/rest operators and other things like that. I think the C# 9 might address some of these shortcomings. Some things that I liked about my .Net core project: I didn’t have to write swagger documents at all. They just got auto generated from my API classes. Dapper is better than any micro-ORM that we have in JS. I didn’t have to write a bunch of tests to make sure I was using correct types. It works great on Linux! Everything’s got its trade-offs. I started my career with Microsoft Access, VB 4/5/6 and complained about moving to .Net. Then I did like 12 years of C# and couldn’t imagine loving JS until I started doing that full-time, since like 2013 or so.... I was glad to polish off my C# skills and to learn .Net core though, just in case I want to switch back some day.
    - h_r 6y ago
      The things you cite as missing in C# can be found in F# on .NET Core. Have you ever tried it? I find it hard to stomach C# after delving deeply into F#, and you still get to use Dapper! Swagger though... not sure if anyone ever got that working well with Giraffe or any other more functional web framework. When I say "working" I mean automatically generating the Swagger docs for you.
tnolet 6y ago
Totally speculative and 100% opinion: could it be that Thoughtworks is a bit scared of JS taking over the world? My feeling is it totally does not fit their model: enterprise heavy, high $$$ consultancy, Java all the things. I'm exaggerating of course to make my point.
rswskg 6y ago
Thoughtworks are extremely fad driven. 10 years of that radar and it has become slowly clear that they use it as marketing to appear relevant.
valand 6y ago
I'm a NodeJS fanboy and I partially agree with this. Feel free to use NodeJS if it allows you iterate faster and your app doesn't need much load. If you're planning to serve a lot of ConcurrentUser with high RequestPerSecond I suggest to carefully plan the execution. I'm having trouble now. One of the projects I'm working on is using NodeJS acting as React SSR server (I know it's heavy). It crashes under pressure, with 10-ish CCU reaching only 12-RPS before crashing. The NodeJS server is not clustered yet though. If it is clustered, it might reach a bigger number, but I doubt it would be that significant. Scale up to 1000 users using Kubernetes and see yourself how big the compute bill next month. This is a fault in architecture and I'm telling you not to repeat my mistake. There are enhancements to NodeJS. NAPI is one, WASM is being introduced too, which is good news. You can utilize child_process and hire someone to write some fast binary for computation-heavy applications and execute that binary. Again, a lot of companies succeed with NodeJS. It's not to be completely avoided. Just be careful not to use it for something it is not used for.

45 points by orange8 6y ago

If somebodies primary language is JS I think node is a great choice. 9/10 times node performance will be just fine for what people are doing. Writing real multithreaded code without a GIL is hard. I would think just scaling horizontal or vertical would be easier. And doing threading in Python is so confusing for new beginners. There are about a million different ways to do it.

hamburglar 6y ago
> Writing real multithreaded code without a GIL is hard. I'm starting to think this is going to be a major dividing line in developer skill going forward -- those who can write threadsafe code and those who can't. There's an awful lot of Java, C# and Golang out there and if a programmer can't reliably think through thread safety issues (which is not that difficult in simple cases), they aren't capable in that realm. One of the most frustrating things about my brief excursion into the land of Ruby was that the community was full of modules written by people who had no reason whatsoever to think about thread safety because they were programming for Rails, not Ruby in general.
- valand 6y ago
  > those who can write threadsafe code and those who can't This, abstracted, those who can write distributed software and those who can't yet. Dealing with shared resources is similar to dealing with shared memory if you zoom out a bit. We need more people to move from the latter group to the former, for reasons. The more people aware of distributed software and its challenges, the better.
- jashmatthews 6y ago
  This sounds very gatekeepy. The JVM and Golang have additional aides for writing thread-safe code because writing multi-threaded code is fucking hard. People at the top of our field working on browsers or VMs regularly fuck up the simple stuff. If it was easy we wouldn't have Erlang or Rust.
  - hamburglar 6y ago
    I'm very gatekeepy about only wanting competent developers working on my code.
jashmatthews 6y ago
> Writing real multithreaded code without a GIL is hard. A GIL doesn't help developers. It only keeps the internal state of the VM consistent. You still need to to use locks, thread safe collections etc. That's one major reason why some people feel that OS threads + GIL is a poor trade-off. https://github.com/ruby-concurrency/concurrent-ruby#thread-safety https://github.com/ruby-concurrency/concurrent-ruby#thread-s...
- nerdbaggy 6y ago
  Never knew that thanks!
vertex-four 6y ago
Writing multithreaded code without a GIL is hard, but there's really good workarounds for a lot of cases. For example, Boost ASIO's "strand" pattern. You can define a set of coroutines that never run concurrently, so synchronization is much easier, while you can have many strands. I use this model in some of my Rust code - I associate clients to a producer, meaning I don't have to work out a suitable contention-free bus. This is essentially equivalent to running N single-threaded processes, except that when I do have to share data across the system (e.g. a database connection pool), or if the lifecycle of the client crosses multiple strands, I have more tools in my toolkit.

orange8 6y ago

It cites the reasons for Node overload as: - The convenience of using the same language in the client and server - The speed of Node.js It unfortunately does not state why it shouldn't be used in the server, or offer any more suitable alternatives.

arcturus17 6y ago
Well it does mention that its single-threaded nature makes it a poor choice for heavy compute workloads, which I agree with. I also think it’s fine for pretty much everything else.
- zumachase 6y ago
  I'm not sure I would agree with this. As with all things, it depends on the task, but "compute heavy" these days means likely working with a distributed framework that abstracts away the underlying process architecture, letting the user define lambda-esque tasks which are deployed across a stream/batch processing model. I think a much better critique would be that the lack of fine grained primitives, and the surrounding ecosystem, are not the best choice for compute heavy tasks.
  - arcturus17 6y ago
    It doesn’t have multithreading, period. You can compute in parallel and work around it by using serverless functions or worker threads or whatever, but often it feels like you’re going against the grain and/or reinventing the wheel. I definitely see the merit in preferring another language with a clear, native multithreading model - and with perhaps significantly better general performance to boot. If anything, the critique in my opinion misses how the Node web frameworks tend to be really unopinionated and non-prescriptive which can be great for some teams and projects but really bad for others (they do mention that NestJS is a technology to watch and that they use it widely, so I actually think they’re of the same opinion)
manojlds 6y ago
Not sure if you read it fully or not: > When Node.js became popular, it was the first major framework to embrace a nonblocking programming model which made it very efficient for IO-heavy tasks. (We mentioned this in our write-up of Node.js in 2012.) Due to its single-threaded nature, Node.js was never a good choice for compute-heavy workloads, though, and now that capable nonblocking frameworks also exist on other platforms — some with elegant, modern APIs — performance is no longer a reason to choose Node.js.

orliesaurus 6y ago

So what does HN think are the downsides of using Node, the article didn't really state them explicitly?

tuananh 6y ago
maintenance ability. building any big system with node is just difficult. typescript helps a bit but it's no where close near a statically-typed language
- mb7733 6y ago
  Under what definition is typescript not statically typed?
  - joking 6y ago
    In the one that it is statically typed on compile time, but what gets executed is not because the javascript vm is not statically typed.
    - filleduchaos 6y ago
      What you might be trying to say is that TypeScript is not _strongly_ or _soundly_ typed. "Only statically typed at compile time" is a meaningless statement because "checks types at compile time" is the whole definition of static typing.
    - gwillz 6y ago
      The JVM also does erasure of generics. Yes, it's not _all_ types but it too relies heavily on compile time typings.
    - valand 6y ago
      ^ I see that you're not joking with this comment :D. Jokes aside, I'm adding facts TypeScript is statically typed because of the type annotations and how the compiler checks the type compatibility between objects. You may can consider TypeScript weakly-typed, because the TypeScript type information are not being encoded into the compilation result. This is similar to C (being staticcally and weakly typed). You can print int as string and the compiler won't complain. On the other hand, JavaScript is a dynamically typed and strongly typed language. It is strong as the types are encoded in the runtime. The proof is the keyword `typeof` and its ability to do Reflection. Reference: Static vs Dynamic: https://en.wikipedia.org/wiki/Type_system#Type_checking https://en.wikipedia.org/wiki/Type_system#Type_checking Strong vs Weak: https://en.wikipedia.org/wiki/Strong_and_weak_typing https://en.wikipedia.org/wiki/Strong_and_weak_typing

Mulpze15 6y ago

I am an intermittent developer, because I need to sell, and manage my (small) business too. In my case, using javascript on the front end and PHP in the back, and as a scripting language for servers was frustrating. Function names are always slightly so different... I increased my productivity and my fun tremendously when I switched to Node on the backend. Sometimes I am thinking about using Python for computer vision stuff. Nope... Everything Javascript, so much better for my sanity.

shock 6y ago
For a bit of unconventional (intellectual) fun, you can imagine your post as being about cooking and food instead of programming and programming languages. Something like: "I was an intermittent cook, because I need to sell, and manage my (small) business too. In my case, cooking both soups and main courses, and some deserts occasionally was frustrating. Cooking times are always slightly different... I increased my productivity and my fun tremendously when I switched to only eating polenta." I hope this does not come off as offensive, which was not my intention, instead, I hope this serves as food(pun intended) for thought and reflection.
- pavlov 6y ago
  I’m not sure that’s the right analogy for using different programming languages in different parts of the stack. A back-end API looks the same to its consumer regardless of whether it’s written in PHP or Node or Haskrustapl. Maybe the analogy would be: “I was using three different kinds of butter in my kitchen. I switched to just one brand. Turns out it didn’t make a difference in taste, yet saves me effort and money because I can buy larger quantities of the ingredient.”
  - valand 6y ago
    > A back-end API looks the same to its consumer regardless of whether it’s written in PHP or Node or Haskrustapl. It looks looks the same to its consumer, but it will feel different when under pressure. I've experienced React SSR server (I know this is heavy) not able to withstand traffic when pushed to only tens of concurrent users, reaching only 1000ish RPS even after being clustered. I'm not opposed to NodeJS though. I've learnt a lot of it and I've ever been a NodeJS fanboy for like 2 years-ish. PS: I also increased my productivity too moving from PHP to NodeJS back then years ago.

mmkos 6y ago

The snippet about Node is confusing terminology. Node is not a framework, it's a runtime environment in which JS can run. It makes a mention of other "capable nonblocking frameworks", but is conveniently vague about which ones. The argument about compute heavy workload also feels orthogonal to the whole issue of Node on the backend.

zaro 6y ago

> Due to its single-threaded nature, Node.js was never a good choice for compute-heavy workloads, though, and now that capable nonblocking frameworks also exist on other platforms — some with elegant, modern APIs — performance is no longer a reason to choose Node.js. But do these other frameworks give you the simplicity of sharing code and using the same language in for fe and be ? For me the performance of Node BE applications is just a nice bonus, for having consistent development environment with huge library of radily available packages.

Kuinox 6y ago
A lot of langage have work in progress and or working GUI framework compiling to webassembly. So yes. And you know what ? You shouldn't share too much code between backend and frontend. The packages are node disavantage. You depends on too much packages it's a security risk.
- zaro 6y ago
  > And you know what ? You shouldn't share too much code between backend and frontend. Yeah right :) I'll tell you what I like about it. I defined my database models in Typescript[1], work with them in the backend, send them to the frontend, and deserialize them back to the same Typescipt model classes in the browser and continue working with them ( w/o the actual database part) as data structures. Are you trying to convince me this is bad ? Because I definitely don't believe you :) [1] https://typeorm.io/ https://typeorm.io/
  - Kuinox 6y ago
    That exactly what you shouldn't do, database models should not be the same models than the one sent to the client.
- zumachase 6y ago
  Any examples? Given that WASM can't manipulate the DOM, I'm suspicious of this claim.

29athrowaway 6y ago

If you don't understand the node event loop, don't use node.

deleted 6y ago
[deleted]

kumarvvr 6y ago

While having one language on the front end and back end might seem like less of a burden, the cognitive context for both of them are very different. Reasoning about the backend feels much easier in languages like C# and even python. Because the majority of the code in the backend is about data storage, retrieval, data modeling, rich and complex business logic, etc. While on the front end, the focus is usually on data binding, immutable structures, etc. JS in react is fine and in my view, for the notion of same language everywhere, JS is a poor language.

ajeet_dhaliwal 6y ago

If you are more productive using Node.js for back-end and React/other JS framework for front-end then don't worry about it and go ahead. Especially so for a small business with few development resources. The performance issues can be tackled when they arise and in in some areas you could use addons or even just break down some work into another service/micro service using Java or whatever. The productivity benefits can be massive and that's usually the bigger issue if you're creating a general web/service. I work on tesults.com and it's all JS.

skrebbel 6y ago

I'd like to add some context for those not aware. This is a page in Thoughtworks' "Technology Radar". Thoughtworks is a global US-based software agency that likes to market themselves as thought leaders in the world of software. They're not super well known in startup land but my impression is that in enterprisy environments they're considered "very good". One way they maintain this image of thought leadership is employing famous people such as Martin Fowler. Another way is by regularly publishing a document called "Technology Radar" which is in opinionated list of technologies that their tech leadership believes ought to be used, explored, avoided, etc. They explicitly don't position it as a bunch of truths they hold to be absolute - it's just the opinion of a few senior tech folks at Thoughtworks who had a fun weekend in a holiday house together or something like that. I guess they had a disappointing Zoom call this time around. It's generally a bit more conservative than HN, you often only see stuff listed under "Assess" that has been commonplace in HN articles for multiple years. This makes sense, it's targeted at enterprises. At the same time, it's highly opinionated and they're not afraid to take positions that are not a match with the current hype cycle. I really like it for this latter quality, and I encourage you to explore this edition further than just their recommendation to not always jump to NodeJS by default (which seems to be a bit of a straw man to me, anyway). Be sure to click all four "quadrants" (right top of the page), IMO the linked one, "Platforms", is the least interesting one.

js4ever 6y ago

I have adopted node (over .Net C#) several years ago and the main reason was NPM and the 1 million packages available. About performances ... With Workers it's pretty good, I'm doing 700k RPS with node on 1 server. Refs: https://vms2.terasp.net/ https://vms2.terasp.net/ https://github.com/elestio/cloudgate https://github.com/elestio/cloudgate

romanovcode 6y ago
If you felt comfortable with C# you should try .NET Core. It's amazing.
- js4ever 6y ago
  True, but NPM vs Nugget ... Still the same story
- wayneftw 6y ago
  I have and I found C# to be somewhat painful compared to JS in some respects, but good in other ways. There are a lot of little conveniences that are missing. There is no destructuring, no first-class functions (i.e. can’t declare functions outside of a class), no easy way to loop over properties of a class and access their values, no spread/rest operators and other things like that. I think the C# 9 might address some of these shortcomings. Some things that I liked about my .Net core project: I didn’t have to write swagger documents at all. They just got auto generated from my API classes. Dapper is better than any micro-ORM that we have in JS. I didn’t have to write a bunch of tests to make sure I was using correct types. It works great on Linux! Everything’s got its trade-offs. I started my career with Microsoft Access, VB 4/5/6 and complained about moving to .Net. Then I did like 12 years of C# and couldn’t imagine loving JS until I started doing that full-time, since like 2013 or so.... I was glad to polish off my C# skills and to learn .Net core though, just in case I want to switch back some day.
  - h_r 6y ago
    The things you cite as missing in C# can be found in F# on .NET Core. Have you ever tried it? I find it hard to stomach C# after delving deeply into F#, and you still get to use Dapper! Swagger though... not sure if anyone ever got that working well with Giraffe or any other more functional web framework. When I say "working" I mean automatically generating the Swagger docs for you.

tnolet 6y ago

Totally speculative and 100% opinion: could it be that Thoughtworks is a bit scared of JS taking over the world? My feeling is it totally does not fit their model: enterprise heavy, high $$$ consultancy, Java all the things. I'm exaggerating of course to make my point.

rswskg 6y ago

Thoughtworks are extremely fad driven. 10 years of that radar and it has become slowly clear that they use it as marketing to appear relevant.

valand 6y ago

I'm a NodeJS fanboy and I partially agree with this. Feel free to use NodeJS if it allows you iterate faster and your app doesn't need much load. If you're planning to serve a lot of ConcurrentUser with high RequestPerSecond I suggest to carefully plan the execution. I'm having trouble now. One of the projects I'm working on is using NodeJS acting as React SSR server (I know it's heavy). It crashes under pressure, with 10-ish CCU reaching only 12-RPS before crashing. The NodeJS server is not clustered yet though. If it is clustered, it might reach a bigger number, but I doubt it would be that significant. Scale up to 1000 users using Kubernetes and see yourself how big the compute bill next month. This is a fault in architecture and I'm telling you not to repeat my mistake. There are enhancements to NodeJS. NAPI is one, WASM is being introduced too, which is good news. You can utilize child_process and hire someone to write some fast binary for computation-heavy applications and execute that binary. Again, a lot of companies succeed with NodeJS. It's not to be completely avoided. Just be careful not to use it for something it is not used for.