8 ms·
Deno makes sense in a variety of situations. The build pipelines of Typescript are excessively complicated and Deno hides that complication away (less dev effor
by sublimefire 6y ago
Deno makes sense in a variety of situations. The build pipelines of Typescript are excessively complicated and Deno hides that complication away (less dev effort).
Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes.
I cannot see it replacing Node though. Node has created a vast ecosystem that includes modules (npmjs), client side bundlers (eg webpack), serverside frameworks (eg express), etc. But because Deno is solving some of the issues for those who run sensitive code in production (eg Lambda functions) it'll most likely gonna become another VM on the public cloud providers' list.
All in all Javascript interpreter is becoming something like a JVM. Everyone wants to use it but without writing vanilla Javascript.
- oblio 6y agoI think raw (framework-less), modern (no J2EE, Spring) Java is most likely a much better language than raw, modern Javascript. Plus, aren't Deno libs compatible with Node libs?
- sublimefire 6y ago> much better language Maybe but who cares when your code does not execute instantly on Lambda and requires you to use GaalVM to convert bytecode to binary. Besides you have a lot of people who would say Kotlin is better. Javascript, like Python wins here. Well Javascript kind of wins because it is interpreted but devs do not use it directly but rather with a bundler/compiler. > Plus, aren't Deno libs compatible with Node libs Not really, if your dependency relies on say `https` module then it'll not work on Deno as it does not have it. And in the case of Deno modules, they are not on `npm` to begin with but even if you import them then they are written in Typescript.
- murukesh_s 6y agoBetter language or not Java is reigning king in enterprise companies. We have built our platform on top of Node.js assuming it would gain popularity but Node.js is nowhere near production use in large enterprises. Somehow the enterprise adoption has been miniscule. JVM performance is top notch. Many features like distributed transactions, messaging support, official libraries for enterprise applications like SAP is severely lacking in Node.js and hindering its adoption in enterprises.
- tomxor 6y agoThis probably either sounds nuts or over opinionated but I don't think the NPM ecosystem is as valuable as people think it is... stuff is deprecated continuously anyway - when you find a way to move away from 10k dependencies (because your shortsighted previous self decided to depend on a single package without looking closer), it's a damn relief. I hate how needlessly complicated the NPM ecosystem is, I would actually like it if no one built bridges to Deno, it could be a clean start with lessons learned. Most of the packages on NPM are complete garbage - most not all - (and I say this as a full time JS dev who actually likes JS), liking the technology does not have to mean liking what people do with it, and JS is the worst, both in terms of the crap on NPM and the web.
- TimTheTinker 6y ago> I don't think the NPM ecosystem is as valuable as people think it is Its value is less about the existing dependency tree of libraries and more about how many apps directly depend on libraries that are npm-hosted. There are many 200+ kloc apps out there making millions/yr each that deeply depend on libraries and frameworks hosted in npm.
- sublimefire 6y agoYour thoughts and experience resonate with me. Although I would look for similar examples elsewhere to understand where it is all headed. And one of those could be the rise and adoption of the JVM. There are a bunch of old dependencies, multiple repositories (compared to just one popular npmjs), a couple of build tools (ant, maven, gradle) compared to npm, yarn, then multiple languages (invented for somewhat similar reasons as Typescript). One thing is sure that the dependencies stay somewhere for-almost-ever, and all else kind of evolves around it. It seems that the main problem at the moment is the developer (me, you, everyone) who instead of writing 20 lines of code uses a dependency that has 10 other transient ones. You cannot fix it but rather challenge those situations at work and reduce the tech debt for good. Maybe there should be a build tool that throws errors depending on the amount of dependencies. Maybe there should be a frontend framework which will only need 10 dependencies for the helloworld instead of 1500; otherwise we kind of think that if a boilerplate template has 1500 deps then surely adding another 100 will not make much harm.
- Freknf 6y ago>All in all Javascript interpreter is becoming something like a JVM. Everyone wants to use it but without writing vanilla Javascript. Except not because lots of people prefer to write JavaScript and those other JVM languages are usually less verbose rather than more verbose.
- sublimefire 6y agoBut why people create Coffescript, Typescript, Kotlin (which compiles to JS), and many more? Why are we compiling ES7,ES8,ES9 to compatible version of basic javascript then? Why do we use wasm? I think this shows the lack of willingness to write a vanilla, all-compatible javascript. Also it seems people use new features without understanding how those get compiled to a lower version. Sorry when I meant vanilla I did not mean ES9.
- brundolf 6y agoI think the JS ecosystem has such a huge amount of raw developer-attention that even if Deno only gets 10% of the market, that's probably enough to bootstrap all those foundational packages/frameworks. Also: if you're porting from Node, the only things that really have to change are the system/IO API calls. The import style is a bit different but that could pretty much be automated. It's still just TypeScript at the end of the day; your core logic will be the same.