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

Deno 1.6 supports compiling TypeScript to a single executable

github.com

Post reply on HN
Print view View original

221–230 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#221

Post by oblio »

pjmlp wrote: post #200
oblio wrote: post #197

Earlier quoted context omitted.

I know you're aware of this, but 70% of the languages in your list are niche languages and especially for web development they weren't that popular. It was (is?): PHP, Javascript, Java, Python, Ruby, C# or nothing. Especially the dynamic languages are extremely popular, primarily with smaller companies and startups.

The whole point of my discussion doesn't have anything to do in which field the languages are popular. Zope and AOL Server teached me that those dynamic languages are really only good for OS scripting tasks anyway, but that isn't the subject of this thread.

It is the point of the thread :-)

For many developers, maybe the majority, those languages are their objective reality. They haven't used anything else, they might not ever use anything else.

So things which extend the range of their tools are very much appreciated.

They're not going to shun their existing programming languages because other people don't like them and they're not going to switch to OCaml or to commercial Java compilers, either ;-)

Re: Deno 1.6 supports compiling TypeScript to a single executable

#222

Post by zeroc8 »

momokoko wrote: post #110
echelon wrote: post #9

Earlier quoted context omitted.

A lot of languages are doing single static binary deploys now. Rust, Nim, Go. It's a really nice pattern. Static binaries are so much easier that the gross PHP / Ruby / Python pattern that has to ship directories full of files that (usually) have to be put in the correct place. It's also easier than shipping a runtime like a JVM. With a single binary, containers get even slimmer.

It’s funny you say that because when PHP / Python / Ruby were all the rage, most people considered needing to compile everything into a single binary gross. What’s old is new is old again!

Because compilers - apart from Pascal dialects - were quite slow. With Go, you aren't wasting time waiting for the compiler. So it feels like a script language, but gives you that extra security of a compiler.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#223

Post by lucacasonato »

offtop5 wrote: post #137
lucacasonato wrote: post #24

Earlier quoted context omitted.

Correct. We are currently working on reducing size for these `deno compile` binaries. From preliminary testing we think we can reduce size by around 60%. Regarding speed, we are investigating V8 snapshotting of the user code, which would give it a great boost in startup time. Actual runtime performance would be the same.

Would it be theoretically possible, to end up using this as sort of a scripting language for rust or whatever. I'm imagining Deno somehow getting complied down to Rust and then running at Rust speed. I basically want low level performance without writing in a difficult language

No this is not possible. JS is too dynamic for that to work.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#224

Post by mark_and_sweep »

z3t4 wrote: post #213
mark_and_sweep wrote: post #208

Earlier quoted context omitted.

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

> 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. It has already been tried with Dart. Dart was made because JS lacked a type system, preventing further optimisations. Support for Dart was added in Chrome. Another popular JS transpiler is CoffeeScript, mos…

I have no data to prove this, but I feel like TS is far more widely used than CoffeeScript and Dart have ever been.

Support for Dart in Chrome was added before Dart was popular (if you can even consider it popular at all). Since TypeScript is already popular now, I think if Chrome added support for stripping the types and running TS code as JS, most devs would welcome that.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#225

Post by mark_and_sweep »

nikisweeting wrote: post #216
mark_and_sweep wrote: post #185

Earlier quoted context omitted.

> Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no? No, there is no magic node_modules directory in any other JS environment, other than Node. Deno aims to be compatible with web standards. Import and import maps are web standards, require and node_modules aren't. > Deno would be a drop-in replacement and we could move our whole codebase over to it overnight The rea…

Node is the standard web environment, even frontend code is built 90% of the time using Webpack or another bundler running in a node environment and pulling from node_modules. I don't think you can blame the incumbent tool with complete market dominance for "poor compatibility"... I really like the direction of the Node compatibility layer though https://deno.land/std@0.80.0/node , I suspect it will be enough to make…

Last time I checked jQuery was used on 9 out of 10 websites using JS with 8 out of 10 websites being powered by PHP.

How dare Node not be compatible with the market dominating jQuery! Silly server-runtime not having a browser window object!

> Now it just needs support for normal `import` statements from node_modules

Deno will never ever do that (other than by using standardized import maps) since that's not normal (normal meaning standardized).

Re: Deno 1.6 supports compiling TypeScript to a single executable

#226

Post by incrudible »

kybernetikos wrote: post #172
oorza wrote: post #151

Earlier quoted context omitted.

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…

Hiring people based on their ability to predict your own idiosyncratic hatreds of specific technologies is just a horrible idea. It also ensures your ideas never get challenged and you never improve.

This is called cultural fit. Predicting idiosyncratic hatred is not enough, one must also share it.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#227

Post by nickjj »

DougBTX wrote: post #181
zelly wrote: post #134

Earlier quoted context omitted.

Containers changed the game. 99% of Deno/Go/Rust server software will be running on containers in practice. You're no longer deploying to a system running other programs which may share pages. It's a container, not a process. Dynamic linking in a container is just a vestigial useless step.

Interesting, that’s the opposite of my experience. Containers allow bundling up lots of dynamic dependencies together so that they can be installed as a single unit. Static binaries can just be deployed as a single file, no need for containers.

> Static binaries can just be deployed as a single file, no need for containers.

Sure but most web apps are more than a single binary. There's generating static files, a database, background worker / cache, and more. Then there's wanting to be able to develop that project as a whole on Windows, macOS and various Linux distros as well as deploying it to a specific distro of Linux (most likely). Then there's the distribution of the binary across a network in a reasonable way.

Docker and its ecosystem of tools solves all of those problems once your app is containerized. And if you want to go 1 step further and run a distributed system with load balancers and friends, container orchestration tools let you solve this problem at a level above your application.

And the best part is you can do all of that in the same way with any tech stack.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#228

Post by nikisweeting »

mark_and_sweep wrote: post #225
nikisweeting wrote: post #216

Earlier quoted context omitted.

Node is the standard web environment, even frontend code is built 90% of the time using Webpack or another bundler running in a node environment and pulling from node_modules. I don't think you can blame the incumbent tool with complete market dominance for "poor compatibility"... I really like the direction of the Node compatibility layer though https://deno.land/std@0.80.0/node , I suspect it will be enough to make…

Last time I checked jQuery was used on 9 out of 10 websites using JS with 8 out of 10 websites being powered by PHP. How dare Node not be compatible with the market dominating jQuery! Silly server-runtime not having a browser window object! > Now it just needs support for normal `import` statements from node_modules Deno will never ever do that (other than by using standardized import maps) since that's not normal (n…

I don't understand, jQuery works fine in node-built environments. Obviously any DOM mutation stuff stuff needs to happen in the frontend when it runs in the browser, but you can absolutely import jquery and use parts of it during server-side compiling or rendering steps in node.

    import $ from "jquery"
> Deno will never ever do that

Why would Deno take such an antagonistic approach to supporting the most common setup that everyone uses with npm? Wouldn't it be trivial to just fall back to checking node_modules for named packages? I want to use Deno! This seems like it's deliberately making transitions difficult for anyone using npm.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#229

Post by dmurray »

jjnoakes wrote: post #70
Couto wrote: post #43

Earlier quoted context omitted.

This reminds me of the server that Zoom used to have. Accepting connections only from 127.0.0.1, alone, isn't enough, since any request from the browser would match that IP, even if the request was being made through a XSS attack. I'm sure someone with more knowledge in security would better chime in.

What I do is generate a random token, pass it to the browser I spawn, and only accept requests that include the token.

Pgadmin does something like this. And also makes it easy for you to get another URL with that token, in case you want to open the same page in a different browser.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#230

Post by chrisweekly »

feanaro wrote: post #220
cjonas wrote: post #155

Earlier quoted context omitted.

Wouldn't proper CORS be enough? I guess you would have to avoid putting any sensitive data in GET requests

No, because CORS can only restrict which origins (scheme, domain, port combinations) are able to access the site's data. But you're not even connecting from a web origin but from localhost and you're trying to defend from all access except by your frontends. For this, you need a shared secret between the server and the frontend. A further limitation of CORS is that certain requests are allowed even if they are not fr…

I'm so fuzzy on the details but isn't this what client certs are for?
Post reply on HN