Earlier quoted context omitted.
Why is Go's binary so big?
Standard library and runtime.
I see a go binary, stand alone. And a lot of symbols. Jesus, that's a lot of symbols.
Deno 1.6 supports compiling TypeScript to a single executable
201–210 of 284 posts
Re: Deno 1.6 supports compiling TypeScript to a single executable
#202Whoa!
Potentially this can make React Native hit the same performance as Flutter+Dart.
as the Dart team claimed - https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
>Dart is one of very few languages (and perhaps the only “mainstream” language) that is well suited to being compiled both AOT and JIT. Supporting both kinds of compilation provides significant advantages to Dart and (especially) Flutter.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#203Earlier quoted context omitted.
What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience b…
Why anyone would look at the litany of mistakes that is npm and Node, then look at Deno and all of the same developers learning nothing except how to implement its "hurr durr URL loading code is cool" approach to security and think "this a good idea" is beyond me. I appreciate Deno because I can ask job interview candidates what their thoughts are about it, and when candidates for senior positions don't point out any…
> I appreciate Deno because I can ask job interview candidates what their thoughts are about it, and when candidates for senior positions don't point out any of the billion obvious reasons it's a stupid project for stupid people, it saves me a ton of time.
I hope you're either self employed, or that you run your own company. If not, this comment is a red flag for potential recruiters; you might want to consider editing it.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#204Earlier quoted context omitted.
Deno is a JavaScript runtime much like Node. For the reasons on why creating Deno I recommend "10 Things I Regret About Node" by Deno's author [1] Deno is different than Node in several aspects; most notably: - Deno supports only ES modules, there's no built-in support for CommonJS modules - Deno's APIs are all promised based - Deno does not use NPM, instead it can pull code from any URL, much like browsers do - Deno…
Node.js module system (kinda like CommonJS) is what made Node.js popular. ES modules while taking away features like scoped module support and dynamic import, it's very complicated and allows bad practices like include files. Promises are very complicated compared to first class functions. What makes JS/Node hard to grasp is that it's async. Async is an (often unnecessary) optimization, with tradeoffs. Loading module…
ES Modules have dynamic imports (https://github.com/tc39/proposal-dynamic-import). The proposal is at stage 4 and is available from Typescript 2.4. We're on version 4 now so I'd expect Deno to have it.
I'm not sure what you mean by "bad practices like include files" so I can't comment on that.
I've found most Javascript developers prefer the await syntax with promises to using callbacks. It gives the code the appearance of being synchronous with the ability to do things more asynchronously if you need. I haven't encountered many who actively prefer the callback style. It gets unruly fairly quickly.
I can't see optional type annotations ever being added to Javascript. They would have to be checked at runtime which isn't something I'd imagine browser vendors wanting to implement.
The feeling that I get is that the standards committee is trying to bring Javascript to be the best dynamic language it can be and if people want more comprehensive guarantees then there are excellent tools like Typescript which give that option.
The fact there have to be multiple implementations of the standard in the various JS runtimes makes it a hard sell to evolve Javascript too far.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#205Re: Deno 1.6 supports compiling TypeScript to a single executable
#206Whoa! Potentially this can make React Native hit the same performance as Flutter+Dart. as the Dart team claimed - https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf > Dart is one of very few languages (and perhaps the only “mainstream” language) that is well suited to being compiled both AOT and JIT. Supporting both kinds of compilation provides significant advantages to Dart and (especially) Flutter.
What this deno feature does is not AOT, but simply packaging the JS as an embedded resource in the executable. JS is still parsed and compiled at runtime.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#207Node is almost perfectly matched to the "Oops, well, too late now" design ethos of JavaScript itself. Nobody was stupid. We humans just can't really predict what will work out and what won't in the future, and this was one of those frustrating cases like carving in stone, where every mistake you make is permanent. But a combination of various factors made the web an enormously impactful medium. It's too important to…
I find it interesting that your example for "benefit of hindsight" is TypeScript. TypeScript is a superset of JavaScript, so it's literally "just add good stuff to the bad and live with it". Am I misunderstanding something?
Also, it's not like TypeScript is without its own set of legacy cruft that they haven't been able to let go (yet). Namespaces and decorators with old, deprecated spec come to mind.
I love TS as much as the next person but I don't think it's particularly good example to use here.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#208Earlier quoted context omitted.
Deno is a JavaScript runtime much like Node. For the reasons on why creating Deno I recommend "10 Things I Regret About Node" by Deno's author [1] Deno is different than Node in several aspects; most notably: - Deno supports only ES modules, there's no built-in support for CommonJS modules - Deno's APIs are all promised based - Deno does not use NPM, instead it can pull code from any URL, much like browsers do - Deno…
Node.js module system (kinda like CommonJS) is what made Node.js popular. ES modules while taking away features like scoped module support and dynamic import, it's very complicated and allows bad practices like include files. Promises are very complicated compared to first class functions. What makes JS/Node hard to grasp is that it's async. Async is an (often unnecessary) optimization, with tradeoffs. Loading module…
> Not everyone wants to use TypeScript.
You don't have to use TS. Deno runs plain JS, too.
> [TypeScript] will probably become obsolete once optional type annotations gets added to JavaScript.
What makes you think that type annotations will be added to JS? I think it's far more likely that browsers and other runtimes will natively support TS as a separate language rather than JS evolving to become TS.
> An opinionated toolchain is nice, but should be optional IMHO.
It is optional. You don't have to run deno lint, deno fmt, deno test, etc. But at the same time, they are pretty good tools so you might want to try them.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#209OT: After reading and discussing this feature in this thread, I realize, it's not about the feature or if it's good or bad. This Deno update and the whole thing shows once again that we want a node successor but Deno as great as it sounds doesn't offer enough benefits or is 10x better than just using node + Typescript in order to leave latter and their huge ecosystem. Even worse, it creates the notion that the Deno t…
> Deno as great as it sounds doesn't offer enough benefits (...) Deno feels just like an opinionated node/Typescript distribution with too little improvements
Node is 11 years old. In the beginning, it was rough around the edges, too. I think you need to be a bit more patient until Deno reaches a similar level of maturity.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#210Earlier quoted context omitted.
> My concern is only will users accept a local server running on their desktop I would say that users don't mind. They want a working application, that does what it promises, and is dependable. Things like having an underlying server is just an implementation detail, nobody really cares (talking about the big public here, not the more technical users of HN who might have a say about the technology choices, but are ov…
Right. One additional complication might be that some web-tech in the browser may require https, which would bring its own complications with security certificates.
PSA: If you have an https web site that needs to talk to your server in localhost, that localhost server does not have to run https since localhost is considered potentially trustworthy.
It will not trigger the mixed content errors (for Chrome and Firefox – Safari does not do this for now, but it is in the works: https://bugs.webkit.org/show_bug.cgi?id=171934 )
I have seen some companies do the following too: They embed a snake oil certificate and instruct people to disable web security, don't do this. Some other companies do something like purchase a foolocal.com https certificate (spotify and dropbox do this I believe), but that certificate might be revoked afaik.
As to CORS, you need to check that the incoming request comes from your own remote machine, otherwise if you enable cors for all, other sites can scan and get your user's data (ebay was recently doing this, scanning ports: see https://blog.nem.ec/2020/05/24/ebay-port-scanning/ )