Hacker News new | ask | show | jobs
by Equiet 1305 days ago
Even if you can't use Deno in your project today, it's hard not be excited about the future that Deno is pushing towards (and dragging the Node ecosystem with it).

When ES6 came out but wasn't yet widely supported it became pretty common to add a build step to transpile the backend code to. This brought a whole bunch of issues that transpilation brought with it but was seen as a temporary evil worth the tradeoff because the new language features brought so many productivity improvements, but stuck for so long it became pretty standard. And when TypeScript became popular, it felt like we'll just never get rid of this complexity explosion that build systems bring. And then Deno came.

Just imagine the amount of config files you'll be able to delete once you no longer need to build your backend codebase.

1 comments

As always, less complexity and less expressive power at a given level go hand in hand: Deno as it exists right now can’t work even with a relatively tame nonstandard approach to JSX such as that in Solid.js[1] (without essentially running a build step at startup), let alone a full language extension like Svelte[2] (there is a thing for that now[3], but it seems to be squeezing in a build system through a localhost server IIUC?).

[1] https://github.com/solidjs/solid/discussions/332

[2] https://github.com/sveltejs/svelte/issues/4431

[3] https://github.com/crewdevio/Snel