An Introduction to Deno: Is It Better Than Node.js?
blog.appsignal.com
blog.appsignal.com
For instance, bundling typescript. I like typescript and hate setting up the build toolchain so this sounds like a good idea. But not every typescript upgrade is backwards compatible (even if unintentional when not), and I'd hate to be stuck not upgrading V8 because it's bundled with typescript.
Or the import system. Importing from HTTP is useful, it ensures things "just work". I like it, on first sight. But is it manageable? Let's say I isolate all my external dependencies into files that just re-export them, or whatever the standard is nowadays. Is the tooling there for when I need to upgrade? How do I deal with sub-dependencies using different versions of things? How do I keep versions compatible? Will something break if I depend on Xv1.1 and Yv1.2 and X uses Yv1.3? Can I force X to use Yv1.2? I can see a world where these things are solved, but it's a vague image.
Or the permissions. Why does my text processing app need to access the web? Again, seems like a good idea. But now the behavior of your standard library is tied to cli options. Phone apps make this work, but they request permissions, you don't explicitly say, "Open Maps with internet access". Ideally I'd like my code not to behave too differently just because it's in a different environment. I want to believe, I see a world where this all comes together smoothly, but it's tough to trust right now.
If I'm understanding you correctly, you don't want to run the code with correct flags and instead, have deno figure it out like a browser where it prompts the user to ask if they would like to give a certain permission.
If yes, that is already the case with deno. You can pass --prompt flag.
It's not that I don't want to run it with the correct flags. I do want that. Things is, if I run it with too few flags the program breaks. Hopefully in a way where it's obvious what happened! If I run it with too many, I lose the security benefit Deno gives.
But the last thing I want is my whole service to fail because I forgot to add that one darned cli flag to my service file!
And, I admit, maybe this is a non-issue. Maybe I can just check I'm in the right environment at program start. But it's one of those things where I don't feel like I fully grasp the implications.
Please don’t say HTTP imports are a good idea. Please.
Otherwise there's no difference between http "imports" and any dependency management system (which ultimately import from some http endpoint)
Basically, you're ("you" as in figuratively speaking) smashing the functionality of a package manager into the interpreter. I'm not convinced at all that making a single tool do more and more stuff is a good idea, but let's keep on.
Then, you're writing URLs (for the libraries you're importing) all over the code (which is just bad). Deno's solution (from the link in my prev reply) is to just put all the URLs in a single file (so, basically a "packages.json", but now inside your code, ¿because that's somehow a good idea?).
Then there's the entire thing about replacing NPMJS, which has full-time engineers working on security, maintenance, etc... with a bunch of different servers, maybe maintained, maybe not, by random people.
Then there's the entire "but how can I be sure that the code didn't change?" thing, to which Deno suggests to use a "--lock command flag". This sounds like "npm.lock / yarn.lock".
And finally, there's the availability concern ("what happens if any of these servers goes down?"), which Deno just dismisses by saying that this can happen to any server. And while that is technically true, pulling all your dependencies from a single place, instead of N different places, reduces the points of failure to 1 (instead of N).
So, this entire "import directly from URLs" sounds just like a package manager with different steps, without providing anything new, without fixing any specific problems with package managers, and introducing new problems (which are in fact old problem, because as I said, we've been there already when PHP thought remote includes were a good idea).
Availability is a concern, but again if you have it once you have some way of including it in the project.
I think there's a security nightmare with anything that's going to end up in browser at some point. It's such an exploitable surface.
And PHP was not a thoughtfully designed language, but the bad part wasn't the fact that remote includes were possible but that there was no attempt at sandboxing or security built into the functionality.
I'm not sold on Deno for what it's worth. I do agree with you on interpreter not really needing to be in charge of package management, but compilers do it all the time and most typescript ends up getting compiled or transpiled anyway.
To an extent, Go does the same thing, even though the modules slightly changed that.
What am I missing?
2. It's a bit of a pain to have to run 2 separate processes. With esbuild you have a single watch process that does compile+run rather than a compile watch and a separate run watch.
The permissions model may have been a mistake. In my own projects I find myself just doing —-allow-all constantly. I could see it being useful for a hardened production server that eg. should only have access to the network, but I think permission-denial may have been better than permission-granting. Maybe they’ll change the CLI around this at some point.
- Maybe Deno intends to be "just a runtime", compared to Node world, where the Node tool and NPM blur together. It also seems to be attempting to dial back Node projects' exponentially large dependency trees by putting a lot of its effort into its built-ins and standard library.
- Deno is as free a bird compared to Node with its apt/dnf packages, multi-version/LTS support, and its lack of 10 years worth of old-JS cruft. It seems to not be too antsy to get out of its alpha stage.
- I could see Deno start to overtake Node if:
* It develops some mature, popular frontend (Vite for Deno becomes stable) and backend libraries. (And/or they pull off their Node compatibility features.)
* It starts to sell people on a comparatively safer software supply chain than NPM.
Some other perceived benefits would be:
* Performance (not the case now) / the interesting stuff it's doing with its runtime.
* New 'n fun.
I cannot imagine how you are capable of effectively getting meaningful things done with this mindset.
For libraries and frameworks, agree completely. But for LOB software, do what you have to do.
> I think I've managed to get by with less dependencies in Go than any other language. It somehow walks the line between JavaScript leftpad and Python "stdlib is where modules go to die".
> I don't think there's been a single instance where I've thought "why can't stdlib do this?" nor "why the heck is this in stdlib?"
I think the answer for things built on npm is that it's someone else's problem and the projects tend to have short lives unless they are super successful to afford constant churn maintenance.
There's parables here to fast fashion and all the other crappily made stuff that sells well but end in landfill way before it should, destroying our planet quicker.
It’s a lot faster and more effective to use free labor from open source projects if what you care about is building useful things quickly.
Also I don't believe that e.g. Node is actually faster than more robust alternatives, with large, well designed, stabler, battle tested, base class libraries, that come with consistent homogenous licenses that won't be deprecated. If you are actually skilled at e.g. C# .NET you can go as fast or faster in my opinion, yet still have much better long term maintainability.
Respect for avoiding dependencies is the sort of thing you learn when you get longer experience supporting not just initially building systems, and culturally I think the javascript ecosystem attracts people who are junior in terms of that experience.
Senior devs understand the value of delegation, especially outside of the company, for work that isn’t your core competency.
You aren’t often allowed on successful and productive teams for very long if you just throw out an entire category of efficiency. I know no dev would last very long on a team I run if they wasted my team’s time rewriting something we could pull off the shelf.
To be clear of course use of dependencies makes sense according to the situation, with consideration for the tradeoffs of the system. If it's write one and never maintain then use whatever works in the moment.
But npm style solutions come with hundreds to thousands of dependencies, which has a real long term cost. Left-pad e.g. is real. You don't seem to be addressing the long term cost at all in your comments.
Hammering on people who are judicious about using dependencies, sounds like an application of when all you have is a hammer, everything looks like a nail.
The idea that we would or even should build software that "lasts" is probably not right, either. The most effective tech is tech that begins its life with a specific set of criteria for when that tech will be rewritten. Often, specifically early on in a startup's life, that "shelf life" will be months, not years, because the problem you're trying to solve will change fundamentally in those ensuing months.
If you're judicious about using dependencies, you are wasting the time of the people around you, full stop. The metric to be measured, as long as you're being paid to write software, is not "elegance", it's "number of problems you've successfully solved". Failing to realize this actively harms your team's ability to execute successfully, and a good team leader will recognize that and correct the problem, either by adjusting your behavior or removing you from the team, if you can't respond to feedback quickly enough.
You don't get paid to create beauty, you get paid to provide functionality, and it's a mistake I see a lot of junior devs make.
It seems you're engaging in poor faith discussion here so I'm not going to bother engaging further in this discussion.
1) strawmanning about beauty, a new topic you've introduced to argue against. 2) introduced new things to argue against re whether software should last 3) stating vague things by assertion e.g. interesting/valid instead of discussing the specifics that a meaningful conversation can be made from
Typically my approach is to attempt implementing something myself before using a library, unless it's something I already know I'm going to need one. If I notice myself going too far down the rabbit hole, I back up and use a lib. At the very least I end up with a greater appreciation for what the dependency is saving me. But often I find you don't actually need more than a small subset of a given library, and my homemade solution keeps chugging along for years.
I still mostly agree with my thoughts from a couple years ago:
1: https://github.com/TypeStrong/ts-node#native-ecmascript-modu...
- ergonomics (convenience methods/parity across collection types)
- improve safety for broader use cases (realms etc)
- embrace FP (records and tuples)
- being a good faith language target for typed extensions
Even very narrow type system stuff seems to stall and feels like it’s going to wither in stage 1 or get bikeshedded to death. Proposals which directly overlap with static typing explicitly eschew any of that overlap to be able to proceed.
Part of me wishes Flow had won, even though I’m all in on TypeScript, because at least Flow had an optional story that could be built into the language and allowed to thrive on its merits and adoption. I can’t see a future where TypeScript or some variant gets folded into the language, because despite being gradual it’s explicitly a separate syntax with a build step. And I know the TS team is very engaged with TC-39, but the language syntax is very much in flux, and a Python-style “type hints ignored at runtime by default” is basically a deadlock or at least reasonably threatens to be one.
"browser compatible" javascript that runs in places other than the browser can (and should) only grow over time ...
deno is kind of a rust-wrapper around v8 -- how long before it becomes the api for the javascript engine used by the browser rather than v8 ...
I think (eventually) "import some_browser_only_api" will become an optional thing you can do when you want to make your code depend on browser only functionality -- with code that doesn't depend on the browser-only functionality able to run without it ...