Hacker News new | ask | show | jobs
by ronaldj 2083 days ago
Configuring the modern JS toolkit (webpack, Babel, your framework of choice, Jest, etc) is such a pain. I’ve been doing front-end for 10+ years. You’re probably not a bozo.
1 comments

Same, and it's just layer on layer of extra tooling and complexity.

Typescript, Babel, Webpack, JSX, TSX, etc, etc.

It gets in the way of development as much as it helps.

Deno does away with most of the tooling configuration. You get linter, bundler, docs generator, formatter, watcher, version manager, std library, inbuilt tests, and many things that you would otherwise source from third parties in node ecosystem.

Support for webgpu and local storage incoming. Makes it a delight to write scripts. You can also scope them by permission.

https://deno.land/

Great community: https://discord.gg/deno

I've been dabbling with Deno and I quite like it.

I wrote a CLI tool to try it out. It monitors CPU/GPU temps then generates an HTML chart on SIGINT.

I like top-level await, the standard library and first-class typescript support.

I do wish the sandboxing was more granular. My small CLI tool requires: --allow-read --allow-write --allow-run and --unstable. I only need a read/write in a single directory, run a single binary. Unstable is required for signal handling, but that shouldn't be the case forever.

I'm glad someone is re-imagining JS/TS on the back end. A robust and stable standard library could well improve the dependency hell and broken projects issues.

Deno seem great, But third party libraries seem non existent compared to npm.
Deno is nowhere near ready for prime-time.
And likely will have similar issues in five years as node has now.

Node was once thought to be the cleaner alternative that had a lot of these features built in, it was the supposed savior of Javascript, and now look at where we are.

I think that is an unnecessarily negative view. By that logic, nobody should do anything because it will probably suck someday.
I do believe constant iteration is better, but Javascript has many problems at its very core, and many Node developers transitioning to Deno are going to create and write solutions that are more akin to their comfort in Node.

This will lend itself to reproducing similar issues as they currently have.

I am primarily a javascript developer, I've written both Node and Deno projects, but I don't see the issues being solved by just rewrapping the source output.

I have found that over time, I have become more sceptical about new shiny things in the programming world. Every now and then, I wonder if I’m becoming the dreaded veteran dinosaur type, the developer who has more demands on their time now and who just hasn’t kept up with the tech.

But then I look at all the troubles the kids have with their fragile, short-lived tools. I recognise short-sighted design decisions they’re making because they’re being pushed into them by some shiny new library. I notice that many of those tools and libraries have big names behind them, and that the Zeitgeist people think you’re weird if you’re not using them, and remind myself that these things are only ever means to an end, no matter how popular they become.

Of course it’s useful to keep generally aware of what’s happening in the industry and from time to time a genuine improvement does come along. However, there is definitely a difference between not keeping up and not wasting your time repeating past mistakes or following blind alleys that often end up at dead ends.

... And suddenly, you want to insert your UI components of choice and you end up with segfault errors of node-gyp.

Then you decide that not giving a damn is the sane option to maintain codebases.

Yeah not-giving-a-damn-driven-development is also the only way to stay sane and not be over come with paralysis from being surrounded by a thousand broken windows in need of fixing.
Arguably not giving a damn caused the problem in the first place