4 ms·

There's a lot of 'just' in your argument. As programmers we fall into this trap where we think that 'just' doing something else will solve all our problems. Bu

There's a lot of 'just' in your argument. As programmers we fall into this trap where we think that 'just' doing something else will solve all our problems. But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either.

spartanatreyu 3y ago
There's a lot of 'just' in your argument. I used the word "just" once in my comment in the point about using Temporal. The Temporal spec was created in part specifically because of the issues with moment.js. ---------------------------------------------------------------------------------------- > But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either. Unfortunately, Node has historically not used the same standards as browsers over a whole swath of functionality, which lead to differences in the language based on whether it was running client-side or server-side. Simple libraries intended to run anywhere would sometimes need to release a client version and a server version. Even when node started adding support for the standard APIs instead of creating new proprietary APIs, they ended up with a fractured ecosystem where some things would only work with the proprietary APIs, and some would only work with the standard APIs. There were so many missteps with node that the creator of node essentially said screw this, I'm starting again from scratch, hence: Deno. Coming back to your point: > But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either. But it *IS* that simple. How? Because Deno uses the standard APIs for things. If it already works in the browser, it will continue to work in the server. No more fractured language.
- troupo 3y ago
  > Because Deno uses the standard APIs for things. If it already works in the browser, it will continue to work in the server. No more fractured language. For greenfield projects? Maybe. For established projects? Not for a very long time. There's a reason Deno added support for npm modules and CommonJS. Because no amount of wide-eyed naïve fanboyism can replace reality.

spartanatreyu 3y ago

There's a lot of 'just' in your argument. I used the word "just" once in my comment in the point about using Temporal. The Temporal spec was created in part specifically because of the issues with moment.js. ---------------------------------------------------------------------------------------- > But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either. Unfortunately, Node has historically not used the same standards as browsers over a whole swath of functionality, which lead to differences in the language based on whether it was running client-side or server-side. Simple libraries intended to run anywhere would sometimes need to release a client version and a server version. Even when node started adding support for the standard APIs instead of creating new proprietary APIs, they ended up with a fractured ecosystem where some things would only work with the proprietary APIs, and some would only work with the standard APIs. There were so many missteps with node that the creator of node essentially said screw this, I'm starting again from scratch, hence: Deno. Coming back to your point: > But I can guarantee that it's never that simple, and for the people who consume your library, it won't be either. But it *IS* that simple. How? Because Deno uses the standard APIs for things. If it already works in the browser, it will continue to work in the server. No more fractured language.

troupo 3y ago
> Because Deno uses the standard APIs for things. If it already works in the browser, it will continue to work in the server. No more fractured language. For greenfield projects? Maybe. For established projects? Not for a very long time. There's a reason Deno added support for npm modules and CommonJS. Because no amount of wide-eyed naïve fanboyism can replace reality.