181–190 of 235 posts
I'd love to use Fresh but a framework for web development which calls itself v1.x and yet only supports Tailwind for styling purposes feels very immature. The fact that for the next iteration they are prioritizing view transitions and not CSS bundling is baffling.
I'm writing a JavaScript bundler and need a Node.js runtime to execute plugins. Deno's executable has fantastic Node support (at least, good enough for my use case) however the deno-core crate is super barebones and difficult to embed.
At this stage I can't simply add the deno runtime into my Rust application, I need to copy/paste internal crates from the Deno executable and wire them up myself (without documentation on how).
I'd love to see expansion for my use case - Deno could become the "plugin runtime" for the JS tooling world if it had a nice embed story.
Right now I am just going with a Nodejs child process that I talk to from the Rust host process using stdio. In my tests, the stdio approach has 10x the communication latency when compared to an embedded Deno runtime (that adds ~1 second per round trip message in a project with 100k assets)
Would love to see the compile situation fixed - the generated executables are ~90MB+ at this stage and do now allow compression without erroring out. Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again! The exe output grew from from ~50MB to plus ~90MB from 2021 to 2024: https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than…
Hi, Bartek from the Deno team here. We are actively looking into improving this situation and from initial investigations we were able to shave off roughly 40% of the baseline size, with more improvements possible in the future. Stay tuned for upcoming releases.
It is interesting to me that none of the new NodeJS alternatives support multithreading. Why is that? Is it just a side-effect of using V8 engine for the heavy lifting, or is it some part of the ECMAScript specification which forbids multithreaded implementations of the language?
I feel like most performance intensive nodejs modules drop down to c++ where real concurrency already exists. (e.g. sharp - https://sharp.pixelplumbing.com/api-utility#concurrency)
Earlier quoted context omitted.
Slint uses https://github.com/AccessKit/accesskit to provide cross-platform a11y.
> a11y I apologize for this being so besides the point of your post, but I hate this trend so much.
Also, the first thing the project website (https://www.a11yproject.com) has to do is explain what the '11' stands for. So they must have some awareness of how inaccessible their name is.
Earlier quoted context omitted.
> If node.js decided to include functionality similar to what is available on Bun/Deno, both projects would probably lose traction quickly. I believe this too. The big appeal for me is not having to install typescript, eslint, jest AND then set up all the configs. deno has nice defaults, though the importing via URLS and browser compatible API do make deno very tempting
that feels like a really weak value prop to me. how often do you have to install that stuff? how hard is it actually? can you really not use, e.g. for react, the typical vite starter and it's done?
> how hard is it actually?
> can you really not use, e.g. for react, the typical vite starter and it's done?
I have to install that stuff everytime I'm starting a new project, switching to a new project, or creating a one-off script.
It's hard when creating a new project where there's always at least one flag that needs to be found and set different from a previous project for some random reason, every single time.
It's hard when switching to a new project, because you have to figure out which version of node you're supposed to be running because each version runs the dependencies differently between different versions of node, and different computers. It might even silently work for you without being on the right version, meaning you continue working on it, then your commits don't work for yourself later or others now or later. This leads to one of two possibilities:
1. A longer job either unwinding everything to figure out what the versions should have been the whole time.
2. A lot of trial and error with version numbers in the package and lock files trying to figure out which set of dependencies work for you, work for others, and don't break the current project.
We also can't use the typical community templates because they always become unmaintained after 2 years or so.
---------------------------
Why I like Deno:
- Stupid easy installation (single binary) with included updater
- Secure by default
- TS out of the box (including in repl making one-off-scripts super easy to get started)
- Settings are already correct by default.
-- and if you ever need to touch settings for massive projects, they all sit in one file, so no more: tsconfig/package.json/package-lock/yarnlock/prettier/babel/eslintrc/webpack/etc... And since the settings are already sensible by default, you only need to provide overrides, not the entire files, so the end result for a complex project is usually small (example link: https://docs.deno.com/runtime/manual/getting_started/configu...)
- Comes with builtin STD meaning I don't need to mess-around with dependencies
- Builtin utilities are actually good so I don't need to mess-around with the rest of the ecosystem. No jest/vitest, no webpack/rollup, no eslint/prettier/biome (but you can keep using your editor versions just fine).
- Since it came after the require -> import transition, basically everything you're going to be doing is already using the more sensible es modules.
Earlier quoted context omitted.
Deno has also created a Next.js competitor, Fresh. I found it a few weeks ago and am starting to go through the docs, looks like a good overall concept. https://fresh.deno.dev/
I actually found this worrying, since it means they are not committed to make NextJS work nicely, quite the opposite they now have incentive to not make it happen
The NextJS team should be working on making NextJS run better with Deno, not the other way around. If the NextJS team doesn't want to do the heavy lifting with that support, thats on them. I think its perfectly reasonable that the Deno folks have an approximate alternative to NextJS. After all, NextJS won't use native Deno idioms for example, it'll always be tied to Vercels' proprietary cloud infrastructure.
I'd love to use Fresh but a framework for web development which calls itself v1.x and yet only supports Tailwind for styling purposes feels very immature. The fact that for the next iteration they are prioritizing view transitions and not CSS bundling is baffling.
Did you try cutting the tailwind stuff out of static/styles.css? Maybe it will already do what you want.
Earlier quoted context omitted.
How is it faster in runtime? Isn't it all V8 at the end?
It's not the JavaScript runtime that's faster but the built-in APIs. Supposedly (I haven't tested this myself), Deno has faster implementations of many Node.js APIs, which I have seen reflected in benchmarks for things like throughput in an HTTP server.