The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.
Deno has the advantage that they are starting from a clean slate without the burden of legacy APIs, but how long will that hold for?
Either way, if Deno is one day replaced by something else, say 'Done' to keep the naming convention, that won't refute the use everyone will have gotten out of Deno in the mean time, in the same way that Deno doesn't refute the use everyone has already gotten out of Node.
So I strongly doubt the next 10 years will be anywhere near as tumultuous as the past 10. It's very possible that right now is just a much better time to be establishing a JS runtime.
But it had limitations, chiefly that imports/exports were not static. Things got imported at runtime when they got reached, etc. This meant that things like browserify were fudging the semantics in some ways, and it also made it impossible to properly do tree-shaking. The stricter semantics of ES modules are better IMO, despite the pain of transitioning.
In case of Deno, I hope they just stick to following the standards and changing with them. They might not, I cannot vouch for them. On the other hand, I was also skeptical about TypeScript following ECMAScript. I though at some point they'll get too much into conflict and MS will refuse to follow, but so far I've been proven wrong. And from the looks of it, TS even deprecates stuff that is likely to conflict with upcoming ES versions.
There are a few longstanding incompatibilities/footguns. And they’re likely to remain due to widespread use, even though most are controversial. Off the top of my head:
- access control annotations (`private` which is compile time only vs `#`). I’m on the fence on this one. I prefer the TS syntax, but obviously not the behavior.
- Enums. Everyone but me hates them. I use them extensively for personal/internal use but try not to force them on others.
- Decorators. This is the big bad ticking time bomb. Last I checked the TC39 proposal has diverged significantly from the TS implementation. And sure it’s marked “experimental” but it’s used a lot and almost guaranteed to be a future conflict. Putting that toothpaste back in the tube is gonna make a lot of people feel a lot of pain.
Hmm, what did I miss, why do people hate them exactly?
> And sure it’s marked “experimental” but it’s used a lot and almost guaranteed to be a future conflict. Putting that toothpaste back in the tube is gonna make a lot of people feel a lot of pain.
Maybe I'm a bit masochist, but I can't say I feel a lot of compassion for people using experimental features in missing-critical production code.
To be fair, decorators are an experimental feature in name only at this point. A lot of libraries force you to use it, including Microsoft's own tsyringe and the beyond popular TypeORM. NestJS is a reasonably popular framework that will codegen services with decorators in them. As the OP of this thread said, the toothpaste is out of the tube now.
In my experience, enums are far less type safe and convenient (usage in switch for instance, combined with a linter) than union types.
They operate in a weird gray-zone between being just compile-time types vs. an actual readonly object in the runtime. I don't think I've seen a use case for them yet that wouldn't have been better accomplished with a union type of string literals and using const string literals in the code.
type Color = "red" | "blue" | "green";I don't know the history of Node... but why would there need to be a diversion?
Node never implemented any of the essential browser APIs like XMLHttpRequest or later fetch, localStorage, etc.
However using CDNs in the browser has some big trade offs. Besides obvious concerns sending any data to consolidated third parties, it’s actually a performance detriment now that browsers are caching per origin.
Used to be, using a CDN got you more likely cache hits and better perf on N+1 requests. Now you definitely don’t get that plus you get the extra DNS lookup and whatever performance characteristics of that CDN.
Where did you get the information from that CDNs arent as good as they used to be?
For scenarios that were previously popular like using the jQuery CDN, you won't get the benefit of the user having jQuery in their cache from another website. You will however still get the proximity benefit you describe. CDNs are obviously still quite useful, just not for getting cache hits on popular libraries.
https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
Using a CDN for your static files is just as fine as it always has been.
The other comment addressed this, but to be clear. One of the common usage of external CDN resources is predicated on a performance benefit: if multiple sites use the same resource, it’s more likely to be cached already and much less likely to be impaired by the drawbacks (DNS hit, external network factors). But since browsers have shipped cache partitioning for very good privacy reasons (as other comment mentions, caches are prefixed by the requesting origin), you get no cache benefit and all of the detriment of a clear cache.
Essentially the only reason to use a CDN for third party resources now is if you can bet the CDN will perform better than your local, already DNS-resolved host.
And you can always use `npm`, `node_modules` and `import maps`[0][1][2] to kind of mimic "nodejs way".
[0]: https://wicg.github.io/import-maps/
[1]: https://blog.logrocket.com/es-modules-in-browsers-with-impor...
[2]: https://deno.land/manual/linking_to_external_code/import_map...
See: https://deno.land/manual/contributing/web_platform_tests
Actually, nodejs has really done a lot of catching up with deno in this regard. It just has to support both the “legacy” way and the “forward looking” way where deno does not.
the web reinvented many of these wheels.
I still largely think kris kowal building the "Q" promise library is what made promises interesting, what surfaced the idea that we might want to first-class our completeablea/futures. I know kris had some specific inspirations but I forget what.
pains me somewhat to this day that promises ultimately became somewhat un-value like, that handlers don't get to see what it was resolving. all the chain/spawn discussion, the functional promise folk: they got rolled by those insisting we had to target only the lowest rings of the developership, and that allowing more potent systems was unacceptable. wish I could find those es-discusa threads, for the powerful sorrow of the afteath, what we are stuck with, in it's so lites form, haunts me. especially as we double back a decade latter & invent controllers & signals toanage our promises. which we would have had for free.
way off topic now. forgive me my late night ramblings.
[1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.30/Cha...