Deno 1.10 Release Notes • Hacker News Board

Re: Deno 1.10 Release Notes

#111

Post by oblio » Wed, May 12, 2021, 2:36 PM UTC

andrew_ wrote: post #92

oblio wrote: post #23

Earlier quoted context omitted.

If the standard library would be richer you'd just ignore half a million of those packages. They'd just die a quiet death.

I think you're underestimating just how passionate the Node crowd is on customization and reusability. There are feature-rich, extremely popular packages which act as a stdlib in many ways for particular functions - yet there are constantly alternatives to ecosystem-dominating packages that spring up. Some gain traction, some do not. I don't see this changing, even with a robust stdlib. It's the culture around the to…

That's just a post hoc rationalization.

The whole "culture" popped up because people wanted to share code between browsers and backends and there's no tree shaking in Javascript, so libraries had to be super small and modular to keep the code small for the front end, where download/unzipping/code parsing/compiling code speed matters.

If browsers get a big stdlib, many of these libraries will just go away (bye, leftpad!).

Re: Deno 1.10 Release Notes

#112

Post by runarberg » Wed, May 12, 2021, 2:41 PM UTC

Jean-Philipe wrote: post #96

echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

I can see why npm is annoying, but I wonder what would be a good role model for a better ecosystem. I can personally only compare npm to PHP, Python and Java, and I think npm is far superior. Do you have an example of a better ecosystem/package manager? I'm genuinely curious.

I think some people like to compare Deno’s package management to go’s. I think that is a good comparison since dependencies live (sort of) on a URL in both cases. However I think Deno has improved significantly on the go approach.

When I look for a better ecosystem though, I like to look towards Rust’s Cargo. However that is bit of an unfair comparison since Cargo was heavily inspired by npm, had learned from npm’s past mistakes and were able to improve on it significantly.

Re: Deno 1.10 Release Notes

#113

Post by BatteryMountain » Wed, May 12, 2021, 2:54 PM UTC

echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

I don't understand all the hate towards .Net. The included libraries are amazing.. about 80% of what you will ever need is provided by the framework. It basically provides you with a massive selection of tools, ready to go. The rest you can either build yourself or pull in a (precompiled) nuget package.

It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trusts. Something that should be predictable and boring, is absolute chaos in the js world. I think it's half the reason things like jQuery, momentjs, lodoash and others exist, because people got frustrated with the lack of built-in functionality. npm has just made everything worse. Can't we have a .Net type framework for javascript? Minus the CLR and compilers of coarse, just the framework bits. Or if we need some kind of CLR type layer, why not build it with webassembly? Then all flavours of javascript can call into that? There has to be a clean way forward.

Re: Deno 1.10 Release Notes

#114

Post by v8dev123 » Wed, May 12, 2021, 3:03 PM UTC

echopom wrote: post #33

rapsey wrote: post #19

Earlier quoted context omitted.

Just because they are attempting to address it does not mean they will succeed.

> Just because they are attempting to address it does not mean they will succeed. Strongly agree this statement , hence I don't see how switching from "npm" to "raw urls" will solve anything... The problem with Node dependency is bigger than just "npm is not a good package manager"... Honestly in this case just fork node and replace npm with something else... Here the problem relies on a mixture between poor built-in…

npm maybe bloated but I'd say it's better than pip. pip is insane, you have to set up virtual env (hurts UX) but with node you don't have to.

Re: Deno 1.10 Release Notes

#115

Post by tarruda » Wed, May 12, 2021, 3:04 PM UTC

BatteryMountain wrote: post #113

echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

I don't understand all the hate towards .Net. The included libraries are amazing.. about 80% of what you will ever need is provided by the framework. It basically provides you with a massive selection of tools, ready to go. The rest you can either build yourself or pull in a (precompiled) nuget package. It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trus…

> It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trusts. Something that should be predictable and boring, is absolute chaos in the js world

This is something that Deno is attempting to build with its stdlib: https://deno.land/std

While the stdlib is not shipped with Deno (it is downloaded like any other third party dep), the code there is reviewed and audited by the core team.

Re: Deno 1.10 Release Notes

#116

Post by [deleted] » Wed, May 12, 2021, 3:08 PM UTC

throwaway2037 wrote: post #107

grumple wrote: post #89

Earlier quoted context omitted.

I have yet to find a datetime library in any language that was adequate for all purposes I've needed. That's not a particularly damning example in my opinion. I've had to write very weird datetime code in JS, Python, and Ruby. I don't even want to imagine the horrible things you could find in some other languages.

In Java, Joda-Time was a third party library for ages. It was the dominant date-time lib for enterprise development. Then, it was standardised and added to the stdlib: java.time (JSR-310). The Joda-Time project lead, Stephen Colebourne, ran the standardisation process. It was well received by most, even the breaking API changes that SC was adamant were flaws in the original Joda-Time API. I can vouch for it: Both Jod…

[deleted]

Re: Deno 1.10 Release Notes

#117

Post by ithrow » Wed, May 12, 2021, 3:08 PM UTC

BatteryMountain wrote: post #113

echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

I don't understand all the hate towards .Net. The included libraries are amazing.. about 80% of what you will ever need is provided by the framework. It basically provides you with a massive selection of tools, ready to go. The rest you can either build yourself or pull in a (precompiled) nuget package. It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trus…

I don't understand all the hate towards .Net.

Because it's the same over-abstracted over-engineered life-sucking ecosystem as the Java world.

Re: Deno 1.10 Release Notes

#118

Post by BatteryMountain » Wed, May 12, 2021, 3:11 PM UTC

ranguna wrote: post #34

echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

I personally like to have a few dependencies in my projects and a simple runtime vs having a monster of a language with a huge amount a unrelated and specialised APIs (java) and still need to install some additional dependencies. I think the barebone nature of nodejs and javascript is what makes it great. If you don't like it, don't use it, there are other languages and runtimes out there and node is a really good fi…

Java is not really a good benchmark for having lean build artifacts. It is a monster but it has other desirable qualities.

In .Net land, the dotnet core runtime weighs in at about 30mb (what you'd need to run a production server), the sdk is about 140mb (for development machines and build servers)(once off setup). If you compile a project that depends on 5 other packages, it will only include those 5 packages and a package for your actual project (assuming 1 project per solution, else n packages for n projects per solution). It boils down to having build artifacts that are super lean, provided you are using the installed runtime on the target machine. You also have the option to package the framework along with your own package, then you don't have to install the runtime on the target machine, and these typically compile down to less than 100mb. It is probably less by now, but I don't use it. You also have the option to bake everything into a single file, much like how Rust does it.

So yeah, I wish more people would play with .Net Core and it's tooling a bit, it's bloody great at moment. Java and it's tooling feels like a behemoth once you get used to the new dotnet tooling.

Take it from somebody that builds build servers and custom tooling (cloning git repo's, building prod binanies, packing them if needed and then move them around (deployment, nuget server etc), all on linux, with C# code) - it is a dream. Calling the the dotnet build tools from my own console apps is a no brainer. My build tools can then be called by other processes in linux like any other cli app, or if I build them as asp.net projects, a simple middleware to intercept calls from nginx to trigger workflows remotely... easy peasy. All while the build tools can talk to Digital Ocean, Azure, Aws via their api's...

Re: Deno 1.10 Release Notes

#119

Post by doteka » Wed, May 12, 2021, 3:13 PM UTC

mmbleh wrote: post #103

tannhaeuser wrote: post #36

Earlier quoted context omitted.

Excuse me, but what's this "bad ecosystem in npm" you're talking about? Every single JS lib, pipeline tool, framework is on npmjs.com (react, webpack, bootstrap, expressjs, and 100'000s others). It's the ecosystem that every contender would love to be. And the lack of a "stdlib" is exactly how and why npm started over ten years ago, via the community-driven CommonJs initiative (JSCI, connect/express.js, the package.j…

> It's the ecosystem that every contender would love to be. Trying to clarify - do you mean other JS ecosystems? Outside of JS, NPM is usually used as what not to do, not as an aspiration.

Could you share some examples of ecosystems that are 1) vibrant and active 2) have working, open source, ergonomic tooling of a comparable caliber to VSCode, typescript and friends 3) can target almost any platform, including but not limited to server, mobile, desktop and web?

I’m trying hard to think of any, Java and Python come closest but both fall short.

Re: Deno 1.10 Release Notes

#120

Post by vesche » Wed, May 12, 2021, 3:15 PM UTC

Manozco wrote: post #7

thegeekpirate wrote: post #6

Earlier quoted context omitted.

They're talking about deno, which _is_ written in Rust. https://github.com/denoland/deno

Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust. So it's probably a rust wrapper around a C++ project (unless they reimplement V8 in rust... )

Yup, it uses rusty_v8 which are Rust bindings for V8's C++ API - https://github.com/denoland/rusty_v8