4 ms·

I can feel the author, in particular about the mess that is node_modules resolutions (and the fact that it sounds like 99% of "tutorials" - or even package READ

I can feel the author, in particular about the mess that is node_modules resolutions (and the fact that it sounds like 99% of "tutorials" - or even package READMEs - about Node seem to be written by someone that didn't really think things through). Anyway: I think the underlying problem is that it has been hidden that Node is NOT JavaScript. It uses (some) of the JavaScript syntax, but it doesn't use its standard library, and its not guaranteed that a Node package will also run on the browser. Deno tries to fix it. But I think everyone should ask themselves: is it really worth it? The backend and the browsers are two different environments with different needs. Why making novices think that the two are interchangeable, just to disappoint them a few moments later?

qsort 4y ago
I think the reason it's worth it (to the extent that it is) is not that it's good for novices, it's that it can leverage V8 and libuv. If your claim is "you're on the backend, you have saner options" then I would agree, but this isn't really about beginners.
- etamponi 4y ago
  Don't get me wrong: the reason why both Node and Deno (and probably JavaScript itself!) are so successful is that v8 is a ridiculously good runtime, and libuv is great. Deno did something smart: all the non-web-compatible APIs are under the Deno package. That's great, and almost fixes the issue I am highlighting. If Node could do the same, and provide a way to find at "compile time" (that is, statically), if a package is web-compatible or not, that would be very good. My issue has probably more to do with npm than with Node itself.
MCArth 4y ago
Because for lots of code, they are interchangeable, and being able to write your code that runs on both the server and client can be very useful. Not to mention that splitting the ecosystem down the middle would result in less high quality modules that can fit your specific usecase!
norman784 4y ago
Ryan Dahl recently said in a talk that *Deno deploy* and *Cloudflare workers* are just v8 runtimes, they are not Deno nor Node, with all the serverless trend it seems to makes sense, also now that we are going back to SSR (now that react supports it officially) we can combine it with SPA (check remix.run for nested routes, nextjs is also working on that) and lastly hydration, so you can now serve plain html, that will be hydrated when the page loads all the JS, it seems like a win win for all those sites/apps that needs/uses React and the users (you will see the content faster than before, just like good old days).

qsort 4y ago

I think the reason it's worth it (to the extent that it is) is not that it's good for novices, it's that it can leverage V8 and libuv. If your claim is "you're on the backend, you have saner options" then I would agree, but this isn't really about beginners.

etamponi 4y ago
Don't get me wrong: the reason why both Node and Deno (and probably JavaScript itself!) are so successful is that v8 is a ridiculously good runtime, and libuv is great. Deno did something smart: all the non-web-compatible APIs are under the Deno package. That's great, and almost fixes the issue I am highlighting. If Node could do the same, and provide a way to find at "compile time" (that is, statically), if a package is web-compatible or not, that would be very good. My issue has probably more to do with npm than with Node itself.

MCArth 4y ago

Because for lots of code, they are interchangeable, and being able to write your code that runs on both the server and client can be very useful. Not to mention that splitting the ecosystem down the middle would result in less high quality modules that can fit your specific usecase!

norman784 4y ago

Ryan Dahl recently said in a talk that *Deno deploy* and *Cloudflare workers* are just v8 runtimes, they are not Deno nor Node, with all the serverless trend it seems to makes sense, also now that we are going back to SSR (now that react supports it officially) we can combine it with SPA (check remix.run for nested routes, nextjs is also working on that) and lastly hydration, so you can now serve plain html, that will be hydrated when the page loads all the JS, it seems like a win win for all those sites/apps that needs/uses React and the users (you will see the content faster than before, just like good old days).