Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.9

deno.com

Post reply on HN
Print view View original

211–220 of 245 posts

Re: Deno 1.9

#211

Post by pests »

goldenkey wrote: post #209
eevilspock wrote: post #149

Earlier quoted context omitted.

I'm just saying Don't be so quick to judge. Be humble! No one is infallible. That said, creating Deno after Node doesn't imply that Node was a fail or that Deno will be perfect. Obviously not. Consider that someone really smart has reasons for doing (or trying to do) things a certain way. Be humble!

Node is a failure. It's standard library is written ad hoc. Riddled with catch 22s and monkey patches. The development style is just to bolt on more and more variables and branches, endlessly, without any cohesive style. Example of the "common caterpillar" genus of node quirks and the awful antagonistic responses by the dev team: https://github.com/nodejs/node/issues/25857 Just take a look at a random stdlib source f…

Most support BLM the concept, few know anything of BLM the organization.

Re: Deno 1.9

#212

Post by riho »

zkldi wrote: post #88

I'd love to use deno, but I really don't understand the point deno's module/package system. The standard practice of deps.ts/dev_deps.ts as described in the docs[1] just seems absolutely asinine to me. Importing everything into one scope and then re-exporting from one file just seems like an awful hack. What do you do if two libraries have functions with the same name? Do you namespace them yourself, or export an obj…

This is probably one of the bigger issues holding me back from adopting Deno (at least for personal projects anyway). I'm sorry, I don't want to go back to early 2000s where we're copy pasting random links to script tags. Those days are over and for the better. NPM has proved pretty much undeniably that people prefer the simplicity of just typing in the name of something to install it, and import it. Does it have issues? Absolutely. I'd rather those issues be resolved than completely throwing away the concept though.

This feels to me a bit like if a new browser came around and said "DNS is the root of all evil" and only allowed you to directly type in the IP address of websites.

You can make all kinds of excuses, like "oh, but you can keep a list of your own!" or "hey, you can install this plugin that gives you DNS lookups back", but ultimately as a user I'm gonna say "No thanks, I'll keep using a browser that doesn't needlessly complicate my day."

I'm usually an early adopter for this kind of stuff, and I really like a lot about Deno, which is why this situation just makes me very sad.

Re: Deno 1.9

#213

Post by brundolf »

girvo wrote: post #167
brundolf wrote: post #64

Earlier quoted context omitted.

JavaScript 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.

Part 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!

CommonJS 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.

Re: Deno 1.9

#214

Post by flyingchipmann »

pierreyoda wrote: post #192
folkrav wrote: post #148

Earlier quoted context omitted.

> enums [...] everybody but me hates them 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-critica…

> Hmm, what did I miss, why do people hate them exactly? In my experience, enums are far less type safe and convenient (usage in switch for instance, combined with a linter) than union types.

The thing is enum and union type have different use cases. Union type cannot be used to check against incoming data. It's a lightweight type level feature. There is no way for compiler to identify the unknown data object from the network. Enum is essentially an object in memory which can be used in this case.

Re: Deno 1.9

#215

Post by goldenkey »

pests wrote: post #211
goldenkey wrote: post #209

Earlier quoted context omitted.

Node is a failure. It's standard library is written ad hoc. Riddled with catch 22s and monkey patches. The development style is just to bolt on more and more variables and branches, endlessly, without any cohesive style. Example of the "common caterpillar" genus of node quirks and the awful antagonistic responses by the dev team: https://github.com/nodejs/node/issues/25857 Just take a look at a random stdlib source f…

Most support BLM the concept, few know anything of BLM the organization.

The movement has been co-opted by opportunists just like Al Sharpton did 10 years ago.

Police reform is an issue that everyone can get behind. But it's not as catchy and divisive.

Re: Deno 1.9

#217

Post by dwaite »

paxys wrote: post #55
maga wrote: post #20

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.

When 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 fo…

There is a tremendous amount of overlap between the Web and Node API creators, but there has been push-back and slowness to adapt many of the Web APIs in Node by the same group. For example, the delays in adopting ECMAScript modules in node, or the lack of first-party API for fetch.

Re: Deno 1.9

#218

Post by smallnamespace »

goldenkey wrote: post #208
smallnamespace wrote: post #166

Earlier quoted context omitted.

Indeed, DRY is overrated, especially for trivial things like string constants.

How is DRY overrated? Making edits to a codebase shouldn't require any more tools than a text editor. I wouldn't want to live in a house that required powertools for every minor repair, it would be burdensome and indicate poor development practices.

Are you using a text editor that can't index your repo and do search-replace within? Vim and emacs both do this easily.

If you're not using an IDE, have you considered that by DRY-ing up constants, you're adding about 2-3 steps to even see what the value of a constant is?

Jump to the top of your file, figure out where the import is from, open the other file, then find constant name.

You also force your code reviewers to do this in e.g. GitHub, where there's no convenient 'jump to definition'.

IMHO, if your starting point is that you won't use sed, can't use a good IDE, and won't configure your editor nicely, then you're just creating a lot of unnecessary work for yourself, regardless of whether you're doing DRY.

Power tools are appropriate if you're building a house.

Re: Deno 1.9

#219

Post by oscargrouch »

m00x wrote: post #151
oscargrouch wrote: post #142

Earlier quoted context omitted.

Because Typescript eventually won that race? (The race to be a fine, typed and sane counterpart to Javascript). Somehow Typescript convinced people from the Javascript side of the fence that they could mix both and eventually upgrade from it. While Dart also tried the same feat, it failed doing so. Nowadays Dart is only being considered to anything because the team behind it are top-notch and implemented themselves a…

> Because Typescript eventually won that race? (The race to be a fine, typed and sane counterpart to Javascript). Dart is doing fine, I'm not sure what race you're talking about? > If you want to use Flutter go for Dart, but picking Dart to anything outside Flutter will just alienate the developer crowd as giving even Typescript is some sort of a niche language in terms of adoption, nevermind forcing people to learn…

Where you were in 2012?

Dart was heavily marketed as a Javascript successor by Google, this was even before ES5 changes, so Javascript was a even weaker language in terms of design, giving people were doing more and more full applications in the language.

The problem is, Javascript did a catch-up, and the Typescript technique of compiling to Javascript made it more appealing as a successor, not mentioning the design of the language (I know that Dart had this too, but having its own JIT it were more appealing in terms of speed back then).

Meanwhile Google abandoned the project that would allow the Dart VM and bindings to WebKit to coexist with V8. And now that only the Dart-to-JS path could be followed to develop for the Web, Typescript championed this path as it was the only way for them from the beggining.

So if you were following those events, you would know what sort of race i was talking about.

I agree with you that "Dart is doing fine", but is only doing so because of Flutter. As in, people learn Dart to target Flutter, not the other way around.

Im not implying that Dart is a bad language, or technology, because thats not true. Its only a problem of adoption, and it will have a hard time outside of the Flutter bubble.

If it were not for Flutter, Dart would continue is path to a slow death, not because its a bad language or technology, but because of how the events turned out to be, and a little bad luck.

Re: Deno 1.9

#220

Post by uli31 »

smallnamespace wrote: post #218
goldenkey wrote: post #208

Earlier quoted context omitted.

How is DRY overrated? Making edits to a codebase shouldn't require any more tools than a text editor. I wouldn't want to live in a house that required powertools for every minor repair, it would be burdensome and indicate poor development practices.

Are you using a text editor that can't index your repo and do search-replace within? Vim and emacs both do this easily. If you're not using an IDE, have you considered that by DRY-ing up constants, you're adding about 2-3 steps to even see what the value of a constant is? Jump to the top of your file, figure out where the import is from, open the other file, then find constant name. You also force your code reviewers…

You're just going to wind up making changes where you don't need them that way. There's no guarantee that because the code looks the same it does the same. An IDE can't figure out what side-effects will happen.

By just letting your IDE make changes globally, you're running the risk of introducing bugs. By DRYng up your code, you know that the change you make will have the same result everywhere.

Post reply on HN