10 ms·
From Node to Deno
- dang 6y agoThe other major threads so far: https://news.ycombinator.com/item?id=23172483 https://news.ycombinator.com/item?id=23172483 https://news.ycombinator.com/item?id=23093737 https://news.ycombinator.com/item?id=23093737 https://news.ycombinator.com/item?id=22102656 https://news.ycombinator.com/item?id=22102656 https://news.ycombinator.com/item?id=20373430 https://news.ycombinator.com/item?id=20373430 https://news.ycombinator.com/item?id=17183241 https://news.ycombinator.com/item?id=17183241 Let me know if I've missed any.
- k__ 6y agoDesktop apps build on Electron should be a good fit for Deno, because Denos API is more like a Browser API than like the Node API.
- tuukkah 6y agoIs there a decent browser (or other GUI framework) in Deno though? It has a wrapper for zserge/webview but I haven't used a webview in ages.
- cultofmetatron 6y agoeven better if deno bases their web renderer on servo since the deno runtime is rust and servo is rust. Would be great for getting some diversity back in the browser stack.
- milutinovici 6y agoThe one big thing missing is an ORM. And making those things is notoriously difficult. Hopefully something will turn up
- littlestymaar 6y agoSince the underlying DB driver exists, you could probably fork one existing node one, or even submit a pull-request for demo support in your favorite node ORM.
- will_raw 6y agoCurious, Why do you think it will be "notoriously" difficult?
- ralusek 6y agoIf something is notoriously difficult, it isn't up to what one individual thinks. That's what makes it notorious.
- jdxcode 6y agoAre ORMs even that great? In my experience they invariably end up just being a messy abstraction to work around.
- hn_throwaway_99 6y agoThe idea that ORMs are a net-positive is definitely an open question. After 20+ years I'm certainly of the opinion they're not. I recently discovered Slonik (only for postgres, hope there is eventually a port for MySQL and others) and I'm a huge fan of the overall approach and the API. This blog post from the creator explains: https://medium.com/@gajus/stop-using-knex-js-and-earn-30-bf410349856c https://medium.com/@gajus/stop-using-knex-js-and-earn-30-bf4...
- derision 6y agoI've used a number of ORMs in the past and have not had a great experience, but recently have been using Eloquent with laravel and it's really great
- hn_throwaway_99 6y agoI just think that at the end of the day, for any moderately complex system under non-trivial load, the idea that you want to "hide the complexity of SQL" from the service developer is an absolutely flawed premise.
- bkanber 6y agoI disagree. I've used many ORMs in my ~20 years, and I've architected and designed several hugely complex systems under non-trivial load. There are really two things I want to put out there: 1) My opinion is that about 90% of your standard, day-to-day queries work just fine in a good ORM. The developer _should_ know enough about the DB schema and SQL to handle the other 10%. (In our 10 y/o enterprise software, the only queries we really drop down into SQL for are complex windowed reporting queries.) 2) Eloquent ORM is... different. It's probably the best I've seen. I wish it existed in other languages. Sequelize, which may be the "best" in the JS ecosystem, doesn't hold a candle to Eloquent, IMO.
- h-cobordism 6y agoI skimmed the Eloquent docs[0] but I couldn't see anything that sets it apart from other ORMs. What makes it special? [0]: https://laravel.com/docs/7.x/eloquent https://laravel.com/docs/7.x/eloquent
- ralusek 6y agoThanks for doing this. I have a few questions regarding packages/dependencies, and TypeScript in general. I tried installing Deno, and I tried including a package, and immediately the TypeScript typechecking in my IDE (VSCode) failed, of course. The IDE doesn't know what to do with a URL as a dependency. Is this something Deno will be able to handle? The next question is that TypeScript packages I have written in the past use `baseUrl` and `paths` in their own configs to allow for absolute import paths. When I look at third-party Deno repositories, I didn't see any that were building out to JS/declaration files, and were instead just meant to be included as the original TypeScript source code. Won't this break things like absolute import paths and other behaviors of the dependency's own tsconfig file, or does this work fine with Deno/TS?
- brlewis 6y agohttps://stackoverflow.com/questions/54794933/how-to-pull-typings-in-deno https://stackoverflow.com/questions/54794933/how-to-pull-typ... Looks like there's a plug-in. Can't research much now, but I hope there's something like that for emacs tide.
- brlewis 6y agoI think for emacs/tide I'll just be able to follow the instructions for Atom here: https://github.com/justjavac/typescript-deno-plugin https://github.com/justjavac/typescript-deno-plugin
- aralroca 6y agoFor VSCode there is recommended this: * https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno https://marketplace.visualstudio.com/items?itemName=axetroy....
- adrianhel 6y agoIt's an unstable feature, but you can use import maps with Deno.
- hn_throwaway_99 6y agoI'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" for years IMO (lock files mess, signed code mess, etc.) but I feel most of those pain points have largely been addressed. I downloaded Deno and tried it out, but at this point I'm just left thinking it doesn't really add anything for me that I need.
- xkapastel 6y agoThis is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do: SUBCOMMANDS: bundle Bundle module and dependencies into single file cache Cache the dependencies completions Generate shell completions doc Show documentation for a module eval Eval script fmt Format source files help Prints this message or the help of the given subcommand(s) info Show info about cache or info related to source file install Install script as an executable repl Read Eval Print Loop run Run a program given a filename or url to the module test Run tests types Print runtime TypeScript declarations upgrade Upgrade deno executable to given version What would it take to get Node to do all of that? Which documentation tool would you choose, and how would you configure it? Testing? Bundling? Formatting?
- hn_throwaway_99 6y agoTotally agree with all that, but I also think it's one of those things that most devs hit the pain point for once, and then have a standard template project they use for everything going forward. I.e. I have all my webpack/tsc/eslint/prettier/jest boilerplate set up once, so now it's not really an issue for me. I also think this is a problem area where the Romejs project is taking a better approach: simplify and fix the toolchain, instead of replacing the entire runtime.
- truth_seeker 6y agoFew things comes to my mind if you are moving from NodeJS to Deno: 1. Deno lacks the library eco system which is required to build a production level app today. I am not saying it cant be done. Just think of the different third party service integration modern application has to do, their maintainance and testing by individual vendors or open source contributors ! Blogs mentions few DB driver libraries, i highly doubt they are as mature. 2. Deno's security model overly hyped at least i see it this way. In last few version of NodeJS, many security flaws have been addressed, see their changelog if you dont believe me. But most importantly, security flaws with native JS is handled by V8 which is common to both NodeJS and Deno. On top of that, most of the libraries and frameworks in NodeJS during their various releases sorted out many security issues in their code. If someone is still doubtful they can use eslint-plugins for sanity and security checks in their JS files. Adopting Typescript also helps if you cant live without types. 3. Learning curve to adopt new SDK for Socket API, File API, System call API etc. I don't think NodeJS falls short significantly anywhere, in fact it provides more and those APIs have been relatively more battle tested over the years. 4. Irrespective of using NodeJS or Deno, following a BDD/TDD practices to ensure sound test coverage of your business use logic still remain the most promising tool to make, break and refactor your codebase.
- nitsky 6y agoRegarding point 3, Deno's APIs use language features that were unavailable when node was written, including promises and async iterators. That is a big improvement IMO.
- truth_seeker 6y agoYou can easily PROMISIFY the low level callback style NodeJS SDK APIs using in-built utilities. https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_... It was introduced in NodeJS 8.x release. The latest LTS version is 12.x
- nitsky 6y agoPromisifying makes the node APIs more convenient, but you still do not have the ability to provide back-pressure. See the link below: https://deno.land/v1#promises-all-the-way-down https://deno.land/v1#promises-all-the-way-down
- ljackman 6y agoIt looks like a good evolutionary improvement over Node.js. However, I have a concern about its security claims. Perhaps someone on the project can allay these concerns. My brief skimming of its site indicates that its security model is based around the ability to disable, say, network access for whole Deno programs. However, does it allow starting up with network access, allowing a subset of the program to handle it, and then dropping those rights for the rest of the program, _especially_ subdependencies? I can't see any mention of a more fine-grained approach: https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions A modern Node.js web service will have hundreds, if not thousands, of indirect dependencies. Some network access will be required for at least the Express routing, or an equivalent. For a Deno equivalent, this would amount to enabling network access for all hundreds of those subdependencies, not reproducing the isolation in capability-based security such as WebAssembly nanoprocesses. Have I missed something here? That doesn't seem like much of an improvement over Node.js except for very small and contained programs. Yes, Deno's dropping of centralised package repositories and package.json might alleviate this problem _somewhat_, but the same fundamental issue seems to remain.
- surajrmal 6y agoYes this is supported: https://deno.land/manual/examples/permissions https://deno.land/manual/examples/permissions
- surajrmal 6y agoYes, this is supported: https://deno.land/manual/examples/permissions https://deno.land/manual/examples/permissions
- ljackman 6y agoThat's a good start, supporting the dropping of privileges after performing something on startup. What about keeping the network allowed in the layer handling, say, inbound HTTP connections, but blocking it in the data access layer or purely computational component? From what I can see, this doesn't work with global boolean flags in the runtime, instead requiring isolated tasks with whitelisted capabilities passed in, some form of "immutable, set-once, dynamically-scoped capability flags", or something like that. The problem with the global boolean flag approach is that if any part of a service needs it constantly, the entire program gets it, even obscure subdependencies for generating colour pickers. Don't get me wrong, it's an incremental improvement over's Node.js blase approach. It's also quite niche to see languages support this feature. E was one of them. There was another newer Python-like language with this too, starting with an `M`, but its name escapes me. I'd recommend Deno's developers look at E a bit more before committing too much to the platform boolean flag approach. Or I've misunderstood their approach and it actually does more than I'm giving it credit for.
- dzonga 6y agoand the great migration begins. but when you look at other backend ecosystems e.g php, ruby on rails they're still getting shit done. even though people might say those languages/frameworks might be slow or insecure. stability is what's lacking in the JS ecosystem. glad I do my backends in flask now
- Roboprog 6y agoMaybe it would be OK if all the Typescript people went Away to Deno and the few of us left who just want to run plain JS on Node, could, in peace. ... As long as there is enough interest still in Node to maintain it. Hopefully, there is still interest in running the same language as browsers do, without additional dependencies. Personally, I would prefer Clojurescript to TS, but not strongly enough to want to be tied to its fate.
- DrFell 6y agoUsing JavaScript outside a browser by running the V8 JavaScript browser engine on the server is a bit of a gimmick, but enough people can't bother to be a polyglot, and it's not that crazy. But, once you are writing code in TS, then transpiling that to JS, then running that in V8 on a server, you have taken a big step into the Rube Goldberg dimension.
- thelazydogsback 6y agoWhat Node is missing due to it's design is parallel (not just async-on-a-single-thread) processing using either green or OS threads without the overhead of serialization to web-workers or a cluster. Last time I checked, Deno didn't have a story there.