9 ms·
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, de
by maga 5y ago
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.
- FractalHQ 5y agoWhat do you mean by reuse of web apis? I’m curious to read up on this feature.
- tehbeard 5y agoThings like ArrayBuffer/view, fetch(...) and worker threads being the same spec/interfaces as the browser implementations rather than homegrown stuff like Buffer, child_process and any number of npm wrappers around the http module in node.
- TechBro8615 5y agoHopefully the story is the same in five years after Deno and browsers have both had time to evolve. Are there plans in place for tracking future updates to Web APIs in Deno?
- mark_and_sweep 5y agoI believe so. Recently Deno started running a subset of the Web Platform Tests to test compatibility. See: https://deno.land/manual/contributing/web_platform_tests https://deno.land/manual/contributing/web_platform_tests
- monocasa 5y agoDefaulting to browser based APIs when they exist (like a global 'window' element to access the DOM), rather than reinventing the wheel the way Node did. Although to be fair a lot of Node APIs predate their browser equivalents, and in a lot of ways the browser contains a 2.0 version of a lot of Node APIs.
- paxys 5y agoI can't think of a single case of Node reinventing the wheel with their APIs. Like you said, they were all created to fill gaps in browser JS implementations. It's obviously going to be hard to reconcile the two as browsers themselves increase their API surface, but then Deno is going to run into the same problem eventually.
- IggleSniggle 5y agoI think that depends on how much deno commits to following the web APIs with each release. 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.
- jonny_eh 5y agoNode introduced the "global" object instead of using the existing "window" object the pre-existed in all browsers.
- sdfin 5y agoAt least whe have "globalThis" now.
- rektide 5y agonode actually invented a lot of wheels. node was first with promises (a couple major iterations!), streams, uhh I dunno what else. file access (we're just getting that now in the browser after some old ill supported early attempts). modules. the web reinvented many of these wheels.
- eyelidlessness 5y agoNode didn’t introduce the Promise API. Although it definitely instigated it. Node, with its async IO model, was just littered with callbacks. There were a zillion different approaches to async APIs that could ease that. Promises were, well, the most promising. But years of iteration and competing standards came and went before Node adopted them as the preferred API. And they did so right along with browser vendors and web standardization bodies.
- tengbretson 5y agoThings like using UInt8Arrays instead of Node's homemade Buffer class, fetch, using WHATWG's implementation of Streams, Blob, WebWorker, etc.
- austincheney 5y agoNode's homemade Buffer class uses UInt8Arrays. https://nodejs.org/dist/latest-v15.x/docs/api/buffer.html#buffer_buffer https://nodejs.org/dist/latest-v15.x/docs/api/buffer.html#bu...
- bavell 5y agoNot originally though: https://nodejs.org/dist/latest-v10.x/docs/api/buffer.html#buffer_buffer https://nodejs.org/dist/latest-v10.x/docs/api/buffer.html#bu...
- deleted 5y ago[deleted]
- paxys 5y agoWhen Node first released its biggest selling point was being able to reuse web APIs. It also filled in gaps for APIs that weren't standard in browsers. Then browsers started to add these APIs, and some of Node's implementations naturally diverged (aka the idiosyncrasies that you mention). 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?
- bijection 5y agoYou could argue that the apis in question are more mature now than when Node was first released. 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.
- brundolf 5y agoJavaScript itself has gone through about a 10-year transition period from a toy language for writing quick scripts to a full-on general-purpose programming language. It didn't even have a module system when Node launched. 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.
- girvo 5y agoPart of me almost misses `browserify` -- the heady days of "Node modules are the One True Way", with all the constraints that implied. Got a lot done with it and related tooling back then!
- brundolf 5y agoCommonJS worked well enough for lots of things, and it was neat that it was so simple (no new syntax!) 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.
- tkzed49 5y agoHow do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports to node_modules, whereas deno code imports from e.g. deno.land. How do you write library code with dependencies that can support that and the other differences in the module systems?
- deleted 5y ago[deleted]
- sjy 5y agoDeno uses ES6 modules, which are supported by modern browsers. There’s no node_modules. https://deno.land/manual/examples/import_export https://deno.land/manual/examples/import_export
- tkzed49 5y agoYeah, I guess if you don't use typescript? But isn't that a lot of the appeal of deno? The browser can't import a TS module.
- zdragnar 5y agoSnowpack might be an option
- eyelidlessness 5y agoTheir companion CDN (and namesake umbrella parent company) is also a first class part of Snowpack. 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.
- chris_engel 5y ago