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

221–230 of 245 posts

Re: Deno 1.9

#221

Post by chris_engel »

richeyryan wrote: post #189
chris_engel wrote: post #178

Earlier quoted context omitted.

There has always been an extra DNS lookup wirh a CDN. Thats even the point of the CDN since based on where you are, you will be served from a location as physically close to you as possible. Where did you get the information from that CDNs arent as good as they used to be?

Safari and Chrome now use a combined cache strategy using the URL of the resource and the top level domain of the site loading that resource as the cache key. For scenarios that were previously popular like using the jQuery CDN, you won't get the benefit of the user having jQuery in their cache from another website. You will however still get the proximity benefit you describe. CDNs are obviously still quite useful,…

Yeah thats true - so you explicitly mean CDNs that serve a single thing only.

Using a CDN for your static files is just as fine as it always has been.

Re: Deno 1.9

#222

Post by jessaustin »

goldenkey wrote: post #207
jessaustin wrote: post #204

Earlier quoted context omitted.

This is a regression. This was possible with "require" and destructuring assignment.

I don't know why you are getting downvoted. I agree. The difference is that ES6 imports are meant to be more optimized and also can allow for async/top-level async modules. I believe part of the additions of ES6 modules made it harder to treat the right hand side like a complete object that can be destructured. In summary, it's not the syntax, it's the difference in feature richness between ES6 and CommonJS importing…

Yeah, I'm not saying that import was a mistake or even a good idea done in the wrong way. I use "import" whenever I can in my own code. It could be impossible to import only the particular things one needs, and that trusting tree-shaking is the best we can do. However, it very much seems like a first version to me, and that import statements could be made smart enough to destructure.

Re: Deno 1.9

#224

Post by Soremwar »

felixfbecker wrote: post #195
dkdbejwi383 wrote: post #183

Earlier quoted context omitted.

> In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release. This is only true as long as you trust NPM. If they were hacked or taken over by a malicious actor, packages could be modified unbeknownst to you.

No they could not. Because your package-lock.json contains integrity hashes that are verified during installation.

Only if you update dependencies, a fresh install would not have such integrity checks, so it's just as vulnerable as Deno hosts to such attacks

Re: Deno 1.9

#225

Post by oscargrouch »

tym0 wrote: post #196
oscargrouch wrote: post #138

Earlier quoted context omitted.

> Deno glue code around V8 is written in Rust. The C++ V8 api is very reasonable to be used in a safe way. So i dont see this as a good point unless of course for people that wan to write some parts that need to be optimized in Rust. Don't deal with NodeJs that much, but is a lot of node functionality in C++ modules? and if so they are presenting a lot of security bugs in a way that Rust might see appealing? Because…

> Deno glue code around V8 is written in Rust. Maybe this is not the best way of putting it. They use Rust for all the system bits including networking, so it's not like they just wrote some JS to V8/C++ glue code in Rust.

Ok, but even if there's more Rust code in it, i think the expectations of the parent poster are unreal, as for safety, only if V8 VM were rewritten in Rust, and giving its a JIT VM sensitive portions of code would need to be in 'unsafe{}' anyway, so how much safer would it turn out to be even than?

Anyway in security terms it will probably turn out negligible as the percentage of code in safe Rust are probably low compared to the whole thing.

Than in memory usage, if it replicates Eletron,it would turned out almost the same, giving is not the C++ core the one that is most memory hungry.. is mostly the renderer process with WebKit and V8 executing big portions of javascript code in memory.

Giving if such a branch existed, it would use typescript which in turn is the same V8/javascript pipeline that is memory hungry.

So, addressing to the parent poster, i don't think it would change much in terms of security or memory pressure if compared to Electron.

Sometimes i think Rust give some people high expectations, that it would be very hard to actually replicate in real life experiences, giving software is much more complex and as in Deno, requires other core parts that cannot be realistically rewritten in Rust, and even if they could, while we can see how software written in Rust can be safer, it still needs to prove the claim for bigger, sensitive pieces of software that requires a lot of "unsafe" techniques to work like JIT's and OS's and therefore might not feel that much of a difference giving the size and complexity of the project.

Re: Deno 1.9

#226

Post by eyelidlessness »

chris_engel wrote: post #178
eyelidlessness wrote: post #135

Earlier quoted context omitted.

Their 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 do…

There has always been an extra DNS lookup wirh a CDN. Thats even the point of the CDN since based on where you are, you will be served from a location as physically close to you as possible. Where did you get the information from that CDNs arent as good as they used to be?

> Where did you get the information from that CDNs arent as good as they used to be?

The other comment addressed this, but to be clear. One of the common usage of external CDN resources is predicated on a performance benefit: if multiple sites use the same resource, it’s more likely to be cached already and much less likely to be impaired by the drawbacks (DNS hit, external network factors). But since browsers have shipped cache partitioning for very good privacy reasons (as other comment mentions, caches are prefixed by the requesting origin), you get no cache benefit and all of the detriment of a clear cache.

Essentially the only reason to use a CDN for third party resources now is if you can bet the CDN will perform better than your local, already DNS-resolved host.

Re: Deno 1.9

#227

Post by m00x »

oscargrouch wrote: post #219
m00x wrote: post #151

Earlier quoted context omitted.

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

Yeah for sure. People didn't want to change from JS to Dart because it's different and they can't adopt the libs they used.

It's absolutely a good language and doing well in Flutter and somewhat outside (I use it outside, but I might be one of the few here).

Re: Deno 1.9

#228

Post by jonathanaird »

hajile wrote: post #205
jonathanaird wrote: post #203

Earlier quoted context omitted.

The canonical way of doing things in Flutter is composition NOT inheritance. This is the whole point of Widgets. Inheritance is used in ways that generally make sense and don’t result in huge complex inheritance trees.

Dart has top-level, first-class functions that don't require wrapping everything in a class. It then proceeds to waste this by wrapping everything up into classes and hoping nobody will use inheritance.

Widgets are essentially data classes, simple wrappers for configuration information. They need to be classes because of the way the internals of the framework works. And no one is hoping you don’t use inheritance. The recommended style is very clear. You’re free to do things however you want but you have to take responsibility for doing things in a weird way.

Re: Deno 1.9

#229

Post by agnoster »

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…

Always snopes before you post! https://www.snopes.com/fact-check/patrisse-cullors-topanga-h...

The "mansion" is a 3br 2ba, real estate is just kind of expensive in LA. My Bay Area home is actually worth more than that, and I don't see why she shouldn't be allowed to make real estate investments or have a nice-ish house. There's no evidence any funds have been misappropriated, and if it comes to light I'll join you in complaining, but until then it just kinda sounds like an attempt to discredit BLM-the-movement by discrediting it's leaders and organization without any real evidence.

Re: Deno 1.9

#230

Post by nikisweeting »

vexna wrote: post #89
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…

I found most of the dependency woes to go away with import maps: https://deno.land/manual@v1.9.0/linking_to_external_code/imp...

Except you have to make them manually. They could've trivially built a thing that takes your npm package.json and converts it to an import map internally, but instead you gotta manage all that hassle yourself because they don't want to play nice with npm. /rant
Post reply on HN