The Deno Company
deno.com
deno.com
"Rest assured that Deno will remain MIT licensed. For Deno to grow and be maximally useful, it must remain permissively free. We don’t believe the “open core” business model is right for a programming platform like Deno."
"If you watch our conference talks, you will find we've been hinting at commercial applications of this infrastructure for years. We are bullish about the technology stack we've built and intend to pursue those commercial applications ourselves. Our business will build on the open source project, not attempt to monetize it directly."
PS, if I was a rich investor I'd throw money at this project even as a donation, so no complain at all, but I'm very curious on the monetization plan.
or like Joyent
vc's will issue course correction very soon.
looks like a repeat of docker.
There's a semi-joke that goes "all companies are software companies now" but there is a lot of truth to that..
It comes to down where a company wants to put its effort.
Do you want to own/operate/maintain all your infrastructure and services (and all the challenges that come with retaining scarce talent that is capable of that work), requiring you to substantially invest in an area that is not core to your business?
Or do you want to spend that money (and let's be real, less money too) to pay a trusted third party provider who will do a better job than you would anyways, because that's their area of expertise?
Then you can focus your (likely limited) resources on delivering value to your business instead.
Other than that, there is the following vague statement at the end of the post:
> The Deno company hopes to enable the millions of web programmers out there to maximally leverage their craft in other domains.
Lambda integrates with existing AWS services, whilst Cloudflare invents newer services to go along with the serverless-first paradigm. Different strategies but they do compete with each other.
I mean Zoom has no right to exist because you can use Chime?
There is always room for better UX, better support, different approach etc.
That largely depends on your definitions of "beat" and "win". There are plenty of software infrastructure firms out there that Amazon has yet to smash into the ground.
Nature seems to think (and I agree) simply existing is winning.
https://deno.com/deploy/docs/pricing-and-limits
AWS sucks hairy balls at providing things that are simple for developers to use, so that could be their competitive advantage, but I'm just guessing here.
Deno seems to be targeting cloudflare as a competitor for their service... But it's probable that AWS will release a cloudflare worker competitor themselves if deno continues with the MIT license.
You're right that v8 Isolates are blazing fast, but Lambda runs functions in a microvm spawn by Firecracker [0], which is likely to be more, not less, secure than Isolates [1].
This is debatable. It's true that V8 is a much larger attack surface than Firecracker, therefore likely to have more security bugs than Firecracker itself. However, Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and very hard to patch if problems arise. It's much easier to work around hardware bugs when you're working from JS / Wasm and can control the code generation.
Ultimately I don't think you can really say one or the other model is more or less secure.
(Disclosure: I'm the tech lead for Cloudflare Workers so I am obviously biased here.)
> Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and very hard to patch if problems arise. It's much easier to work around hardware bugs...
I see your point. I mean, Google wouldn't put as much effort as they are on gVisor if KVMs were the best possible answer.
Deno is competing against Node.js, which is MIT-licensed. Deno is arguably better, but it would have to be _so much better_ to get people to even give it a second look if it was commercial.
1: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
I do find the messaging to be confusing, because what would you think I meant if I talked about the runtime of Elixir or Scala?
This is the marketing line on the front page of the Deno project:
> A secure runtime for JavaScript and TypeScript.
They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.
To me "TypeScript runtime" means running TypeScript in a mode that runs faster than JavaScript by actually using the type info to generate better machine code. It does not mean translating to JavaScript at runtime and running in V8.
For example at one time there was an experimental version of Chrome that had a Dart Runtime. A quick google finds this HN thread when they decided NOT to have a dart runtime
https://news.ycombinator.com/item?id=9264531
So can we get clear? Does Deno plan to execute TypeScript natively (not via V8 or via a heavily modified V8) or are the plans to continue compiling TypeScript to JavaScript internally and actually just run JavaScript
This is the marketing line on the front page of the Deno project:
> A secure runtime for JavaScript and TypeScript.
They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.
https://startfunction.com/deno-will-stop-using-typescript/
It featured on HN some time back:
This is the marketing line on the front page of the Deno project:
> A secure runtime for JavaScript and TypeScript.
They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.
Hence the implied step that TS needs to first be transpiled to JS before getting executed in the runtime was always in the back of my head and I'm guessing this is the way most people think as well.
And from a black-box perspective, whether TS first gets transpiled to JS or run directly doesn't make a difference. In that sense one could argue that it is a "TS runtime". This is a petty semantics-fight I don't want to get into though and I've probably already said too much :).
If you are interested in something that gets close to a TS runtime though, have a look at AssemblyScript [0]. It compiles to WASM and tries to keep most of the syntax of TS. Very interesting project imo.
> Deno is a runtime for JavaScript and TypeScript that is based on the V8 JavaScript engine and the Rust programming language.
We've simply incorporated the type-checking and transpiling steps into the deno cli, making it super simple to get going, no config needed.
> A secure runtime for JavaScript and TypeScript.
Shouldn't require caveats, with the caveat being that there is no runtime for TS.
There is reason to believe that the extra information given from TS typings could be carried into runtime wins, and so there is absolutely pent up demand for an actual TS runtime.
I think this is one of the reasons why cloud computing monoliths like AWS are so successful. It's way easier to set up a $50/month VM on AWS then to get permission to spend $5/month on a VM elsewhere.
Unless you have a ridiculously good relationship with a handful of organizations or a perfect system for fitting into existing infrastructures, it's a big mistake to care about selling something to those organizations.
AWS is popular because it's free for companies with a high potential for getting big (like YC companies) and they can absorb the costs of the sales cycle.
Really ? I can think of QT - but that's such a huge body of work with some very specific use cases in which it doesn't really have competition (aside from DOM based shell for UI maybe, but that has it's own problems and is often a hassle to get working).
In this case Node is established, Deno is going to have an up hill battle to gain that mindshare on equal footing, adding a licensing restriction would probably kill it off the ground.
Can anyone name a few that come to mind?
I only know about one (Qt: GPLv2/3 or LGPLv3), but I don't use a lot of commercial software. Interestingly, Qt looks about 233 USD per month per seat!
One of the funniest/best business models out there is SQlite (https://sqlite.org/copyright.html). They give it away to the public domain, but some lawyers wrongly claim that that is not enough, so they will "sell" you a warranty asserting it is all public domain.
Not all jurisdictions of the world legally recognize the concept of 'public domain'.
This might be surprising, but not everyone is looking to be a unicorn.
I've been building my new multiplayer games website [1] with Deno over the last 4 months and apart from some minor growing pains, it's been a joy to use.
The lack of unnecessary package management, and the TypeScript-by-default approach makes Web dev much nicer. We're also using TypeScript on the client-side, relying on VSCode for error reporting. We use sucrase to strip the types just as we're serving the script files, so that there is no extra build time, it feels like TypeScript is Web-native and we can share typed code with the server.
[1] Not yet launched but we ran a preview past weekend with hundreds of players over WebSockets: https://twitter.com/MasterOfTheGrid/status/13757583007179735... - https://sparks.land
I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?
> I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?
Not that I can tell. But if we need to, we can always do a minified bundle in production later on. So far it's just nice to not have to even think about it!
It compiles, and then caches the output I assume?
That's a really cool use case I hadn't thought of..
If you're on Windows like me, sadly there's still a nasty bug with path mismatches between the LSP server and the VSCode extension (https://github.com/denoland/deno/issues/9744) which requires reloading the window to fix spurious errors, but I'm sure it'll be fixed soon enough.
Vscode extension is maintained by the official team and will provide the best experience. There are unofficial plugins for sublime and Vim. They use LSP too and provide a comparable experience.
Each game server (a stand-alone Deno program that might or might not run on its own machine) connects to the switchboard over websocket and authenticates itself with an API key (since people will be able to make their own game servers).
When a player wants to join a server, they POST a request to the switchboard, which gives them back a token that they can send to the game server after establishing a WebSocket connection to it. The game server checks the token with the switchboard and gets back public user account info if it's valid.
Each game server's logic is currently single-threaded. I guess we might end up offloading some work to WebWorkers later on.
A server can publish some state info through the switchboard that will be broadcasted to other servers from the same user. This is used to show player counts in game rooms from a lobby, things like that.
I run the whole thing on a couple cheap Scaleway servers, with Cloudflare in front (no AWS nor containers or anything of the sort). My previous platform, built with Node.js (https://jklm.fun) is able to sustain at least 2000 concurrent players like that, though admittedly those are board-like games which are not very demanding, unlike the games for Sparks.land which will be more fully-fledged... so we'll see how that holds up!
> Our infrastructure makes it possible to... create custom runtimes for different applications [like] Cloudflare Worker-style Serverless Functions
Fascinated to see what happens here. The serverless / edge compute paradigm fits Javascript hand-in-glove philosophically, but until now it's always felt quite clunky to me. When I've tried it out, I've always been left thinking "but this would just be so much easier with a server".
Reading this has made it click for me why that is. A new paradigm needs a new set of tools native to that paradigm.
The entire server-side JS ecosystem is currently structured around Node, a fundamentally stateful-server paradigm. You can try to abstract over it, but only so far. It's not the serverless paradigm that's clunky, per se, it's that the tools right now were built for another way of doing things.
As a concrete example - Deno has an import system based on URLs, rather than on-disk node_modules. I thought that was a cool feature for convenience, less overhead, more open and sharable packages, etc. But now I realise the full intent of it. It's much more than all that, it's a fundamental shift in the paradigm: no implied dependency on stateful disk in the runtime itself.
It's the same issue with Netlify, Vercel etc. where their edge is very different to say Akamai, Cloudflare or Fastly's edge.
I think that lets you deploy to things like edge devices that don't have a hard drive, and even more ephemeral environments.
wow lots of bold statements there. And another one for the usual "JavaScript is fragmented, let's create another tool to fix 'em all.".
Deno is more of an ecosystem reboot than a fork, I would think.
Because you know this blog post and announcement will draw some strong reactions from entrenched interests.
As someone who uses Node but doesn't closely follow the steering/proposals side of things, I can't say I had this impression of that process..
Is Node really that bad compared to how JS/ES is innovated on in the browser?
Streams (and event emitters, and the ecosystem bits that rely on them) still haven't fully caught up with promises either, e.g. async iterators and generators are still quite awkward
I mean, I don't mind using util.promisify or just importing the "to be" xyz/promises paths. The code exists clearly, either behind a symbol or otherwise.
As an outsider who likes to lurk, I have the impression both ECMA and Node committees are stuck in the "we're nice and therefore right" field.
They made technological choices that broke the platform (eg. require vs import). It took ages of pain to innovate on things that matter (eg. promises, async)
I wish Deno the best, but I'll just try to stay away from JS from now on (same as I've been avoiding Python after the 2to3 migration).
https://guides.rubyonrails.org/v4.2/command_line.html#custom... https://docs.djangoproject.com/en/3.1/howto/custom-managemen...
I guess though, the people in the Ruby / Django community are actually building projects and the node community are padding their resume with new npm packages.
I hope deno or dart can make the JS world better, but I suspect they will both end up just making it more fragmented. One thing I really like on flutter / dart is they do try to rate / otherwise rank / categorize support of their packages aside from stars https://pub.dev/packages?sort=popularity / downloads which are easy to manipulate. IMO deno should do this as well or let someone willing to takeover as the primary package manager https://deno.land/x/lodash@4.17.19
Golden phrase to describe a lot of folks. If I were to translate, it's behaving pleasantly and politely in order to justify poor decisions.
The first line on Wikipedia in the nodejs history section is "Node.js was written initially by Ryan Dahl in 2009".
You can make whatever point you want, but maybe try to do it without rewriting history, or changing the agreed-upon definition of "creator".
Embedded answers are worse than useless.
https://www.google.com/search?hl=en&q=who%20invented%20hands
Don't think so. I have been using Node.js since 2010 and following the ecosystem. Node.js is the child of Ryan Dahl. Other than Ryan, perhaps Isaac Schlueter is the most influential person who developed the NPM as a separate project and later merged into Node. Ryan could have done it himself or embedded it in Node.js, but guessing from Deno he is not keen on a centralised package repository so could have let Isaac build NPM as a separate project.
From what I could observe, the overall API is still pretty much the same from 2010. What's changed is V8 getting updated to newer versions (and thereby supporting new ES features) and other performance optimizations. But no one can't deny or take away the creator credit from Ryan.
Furthermore Node has its own maintenance/risk issues in production systems (think permissions), and Deno reduces those with custom built runtimes.
I cannot see it replacing Node though. Node has created a vast ecosystem that includes modules (npmjs), client side bundlers (eg webpack), serverside frameworks (eg express), etc. But because Deno is solving some of the issues for those who run sensitive code in production (eg Lambda functions) it'll most likely gonna become another VM on the public cloud providers' list.
All in all Javascript interpreter is becoming something like a JVM. Everyone wants to use it but without writing vanilla Javascript.
Plus, aren't Deno libs compatible with Node libs?
Maybe but who cares when your code does not execute instantly on Lambda and requires you to use GaalVM to convert bytecode to binary. Besides you have a lot of people who would say Kotlin is better.
Javascript, like Python wins here. Well Javascript kind of wins because it is interpreted but devs do not use it directly but rather with a bundler/compiler.
> Plus, aren't Deno libs compatible with Node libs
Not really, if your dependency relies on say `https` module then it'll not work on Deno as it does not have it. And in the case of Deno modules, they are not on `npm` to begin with but even if you import them then they are written in Typescript.
Most of the packages on NPM are complete garbage - most not all - (and I say this as a full time JS dev who actually likes JS), liking the technology does not have to mean liking what people do with it, and JS is the worst, both in terms of the crap on NPM and the web.
Its value is less about the existing dependency tree of libraries and more about how many apps directly depend on libraries that are npm-hosted.
There are many 200+ kloc apps out there making millions/yr each that deeply depend on libraries and frameworks hosted in npm.
Although I would look for similar examples elsewhere to understand where it is all headed. And one of those could be the rise and adoption of the JVM. There are a bunch of old dependencies, multiple repositories (compared to just one popular npmjs), a couple of build tools (ant, maven, gradle) compared to npm, yarn, then multiple languages (invented for somewhat similar reasons as Typescript). One thing is sure that the dependencies stay somewhere for-almost-ever, and all else kind of evolves around it.
It seems that the main problem at the moment is the developer (me, you, everyone) who instead of writing 20 lines of code uses a dependency that has 10 other transient ones. You cannot fix it but rather challenge those situations at work and reduce the tech debt for good. Maybe there should be a build tool that throws errors depending on the amount of dependencies. Maybe there should be a frontend framework which will only need 10 dependencies for the helloworld instead of 1500; otherwise we kind of think that if a boilerplate template has 1500 deps then surely adding another 100 will not make much harm.
And don't do anything. I'm amazed by how often I read the source for a package I'm interested in, only to find it's about 10 or 20 lines of code.
The convenience of adding a package means that if you're not sure how to do something, you can easily just add a package to do it rather than figuring out how to do it yourself. A lot of the time, you can just read the source and adapt it rather than installing the package.
Having reusable code wrapped into packages is basic software engineering.
Although some people will then complain about the size of the library...
Exporting out one method at a time is pretty absurd.
This is also an opinionated subject, and as with most things in life there is a balance somewhere in between the two extremes. However the NPM packages you refer to (and yes I have seen the <10 line offenders you refer to) are clearly at a stupid end of extremely useless shared code that amount to the most trivial stackoverflow JS examples.
In response to the sibling comment on duplication: all I can say is that it cuts both ways, deduplication to the extreme also has downsides: when someone changes that code you don't control, it now affects a large number of dependencies that the author may not care about. But even ignoring those issues and assuming you package-lock everything and never look back, extreme de-duplication in general can result in highly illegible code due to a lack of holistic view: whether it's achieved with thousands of tiny external packages or thousands of tiny 3 line functions in the same file - many have covered this topic in detail before, deduplication for deduplication sake never ends well, abstractions always have a cost.
I generally think the NPM ecosystem is pretty cool, but I have noticed that even simple stuff like creating a RESTful service doesn't seem to have stablised in the ways I would have expected given node's target audience, and you end up writing a lot of the boilerplate yourself. Hopefully this will result in hundreds of replies telling me how I should be doing it, but even the fact that it's not trivial to find that out is a sign of a fragmented ecosystem.
Except not because lots of people prefer to write JavaScript and those other JVM languages are usually less verbose rather than more verbose.
I think this shows the lack of willingness to write a vanilla, all-compatible javascript. Also it seems people use new features without understanding how those get compiled to a lower version.
Sorry when I meant vanilla I did not mean ES9.
Also: if you're porting from Node, the only things that really have to change are the system/IO API calls. The import style is a bit different but that could pretty much be automated. It's still just TypeScript at the end of the day; your core logic will be the same.
- Typescript as a first class citizen
- An actual `window` global with familiar browser APIs
- Sandboxing w/ permissions
- URL-based imports (no need for NPM)
- Bundling into self-contained binaries
- Things like top-level-await which Node.js still treats as experimental.
- Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks)
To me, those aren't just minor details. This has the potential to create a new epoch in server-size JavaScript.
What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think the abstraction, and to some degree the centralization, of package management is generally a good thing
I cannot understand the benefit of this scheme honestly. I would have preferred they fix something npm is lacking, like adding the ability to sign packages
Deno caches everything offline and only reloads if you use --reload flag.
I would recommend going through the manual to learn more about deno workflow.
Could you expand on this? Any examples would be appreciated.
Example guiding users to include a Maven dependency: https://www.baeldung.com/guava-mapmaker#map-maker
There is some degree of assurance that this dependency won't last long in the Maven central repo, or any other user configured repository, if it contained malicious code. Obviously it is not foolproof and incidents happen, but without a centralized authority for package management, there is much less assurance that a package is not malicious
Deno makes it easy to import from temporary places. However, this wouldn't be solved by having a centralized registry or a package manager like npm.
Npm can install from git repos and registries other than npmjs.
Having a package on npm by its own doesn't make it any less malicious.
A solution would be to enforce registries you can import from and fail if it's outside that.
Also: Nobody prevents you from using a package manager anyway. Just because you can use urls in imports doesn't mean you have to. But it is very convenient that deno downloads exactly the code that is imported. A package manager will always just throw everything at you. Some packages in node.js try to fix this by splitting the project into submodules like @babel/core, @babel/env, .... But that made installing dependencies worse. Just let deno figure out what is required is way more elegant IMO.
Also, from your link:
"In Node this is done by checking node_modules into source control. In Deno this is done by pointing $DENO_DIR to some project-local directory at runtime, and similarly checking that into source control:"
I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production.
Is it possible to do this in deno today? I don't really get that sense.
npm install copies in to your node_modules an entire zip/tarball package. Deno uses ES2015+ module syntax and it's only going to grab the JS files that are imported (or imported by imports). So it "naturally" tree shakes at the file level, and doesn't have a concept of a "package" in the same way. It's not directly going to tree shake inside of single file boundaries in the way that a major bundler/packager might (though the V8 JIT should still sort of indirectly compensate).
So yeah, if the package is published as just a single (M)JS file it will still get entirely downloaded by Deno, but if the modules are split across multiple files, Deno will only download the ones that are directly or indirectly imported (and will have no idea of the remainder of the files in the "package").
> I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production.
> Is it possible to do this in deno today? I don't really get that sense.
Yes, because URLs are just URLs, you could always have a Proxy service running at a URL that knows how to request the packages from upstream. https://jsproxy.mydomain.example.com/lodash/v1.1/module.js could be simple caching proxy that knows how to get lodash from upstream if it doesn't have the requested version cached (or sends a 404 error if it isn't allowed to cache a specific version or whatever).
Re: URL proxying, this all feels ad-hoc and overly decentralized. I agree with your assessment that "rolling it yourself" looks simple enough at first glance, but after having so much success with package managers and associated tooling I can feel the doubt in my mind that a new approach won't just reskin the same problems. I see they've done some reasonably smart decision-making along the way though, so let's hope they walked down this logic tree and are happy with the likely paths
Well, I started from the "full paranoia" mode where people would want it to be ad hoc and as decentralized as possible. It's very easy to imagine that there would still be trusted/trustable 3rd parties creating central proxies for stuff like this. Just as unpkg today provides one way to pull individual JS files from npm, you could imagine unpkg as an option for Deno. Similarly, there are lots of artifacts repositories with upstream pulling options already in the wild such as GitHub Artifacts or Azure Artifacts or jFrog Artifactory as three easy examples to mind (among many). It's not hard to imagine those artifact libraries also supporting Deno style URLs (in a similar manner to what unpkg does with npm) as Deno becomes more popular.
Ultimately it is likely to be a huge spectrum from people that want a JS proxy they entirely control/run/manage themselves, to those that want one they trust from a 3rd party, to those that are fine with whatever CDNs their libraries suggest. That's already a spectrum that exists in the npm world: people have private npm servers, people use npm artifact libraries like GitHub Artifacts, people use unpkg directly to pull in JS files from npm, people still go to Bootstrap or JQuery in 2021 and just copy and paste whatever CDN is mentioned in the "Getting Started" section of the appropriate docs. That spectrum is still likely to exist for Deno libraries, and while it might make it harder as a user/developer to choose which part of that spectrum is best for your own projects, Deno having little to no "out of the box" opinion on which part of the spectrum your project falls into (as opposed to Node defaulting to npm these days and the two ever more seemingly inseparable) isn't necessarily a bad thing for the ecosystem's health as a whole.
In a fairly simple and elegant manner. You specify a URL to the specific file FOO you want to import and FOO gets downloaded. Then deno looks at FOO to see what files FOO depends on, and downloads those, so on so forth...
That's very different from how NPM works where you have to download the entire package, including parts you may never use, along with every dependency the package depends on, even if you never end up using those dependencies either.
NPM's approach, which frankly worked well given the circumstances, has the downside of not providing end-users much benefit of writing code in a modular fashion, so there's no advantage to breaking a package up into multiple files versus distributing a single and large minified file.
Deno's approach promotes breaking up packages into multiple files so that an end-user only downloads the files and dependencies that are actually needed.
I will be interested to see how the tooling & community resulting from this decision look. Hopefully good.
The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits
They don't do a great job of advertising the changes; take a look under features/zero-installs.
The common practice is to still use yarnv1 as your global yarn, just do "yarn set version berry" inside your project to use v2. 0-config can be a breaking change - though I haven't had problems in a long time.
If we are using URL-based imports, the scope of security assurances are much broader: an SSL certificate doesn't say anything about whether the current owner of a domain was the owner at the time of a dependency being safe. There is no one authority who we can expect to take swift (or even slow) action to remove malicious packages from being available on the myriad hosting protocols that are accessible through an environment like Deno
At the least it can be made a requirement for packages in the case of multiple people with publishing access that everyone uses 2fa
What it isn't eliminating is the ability to define "local" caches. Just because you are importing everything from URLs doesn't mean that they can't all be URLs that you directly control. You don't have to use CDN-like URLs in Production, you can entirely copy and paste all the modules you need onto a server you control and URL scheme that you maintain.
There will still possibly be good uses of caching automation in Deno (once people get bored with xcopy/robocopy/cp -r/rsync scripts), but it will likely seem a return to more bower-like tools rather than necessarily full blown packager npm-like tools. (ETA: Or proxy services like GitHub Artifacts that pull an upstream source for you and rehost it on controlled URLs with some additional security checks.)
I wish there was something like Docker Hub's automated builds in the Node world because the way NPM works right now, what comes from NPM is an unknown. The only thing you know is if you download a specific version once, you'll always get that same version again, unless it's invalidated. Otherwise, whatever the package author wants to upload and include, that's what you get and you can't know that what you're seeing in some Git commit is what's running in your application. I wish that was the state of the art.
- this doesn't make sense, its bad API design and shoe horning in a completely different paradigm is not a good idea, it should have moved somewhere less familiar and more oriented to the environment (I know that sounds weird but giving a quick answer, there are better solutions and this aint a browser)
- not bad, but seems odd to me as a language feature in some ways, there are plenty of ways to achieve this. (macOS will do this to your node scripts even itself, why do we need more of it)
- this is subject to the same problems NPM could have, but I guess it is easier? Now you have to lexically parse all files to determine an import and you also have to remember where you keep your 3rd party packages without a centralized way to know it (edit: this seems to harm the previous point)
- bundling isn't that interesting in this context as it just bundles the whole runtime with the package, which is terrible for size of packages and doesn't net a lot of benefit since they are also now tied together - if there is a security flaw you now must fix the entire binary and hopefully it still compiles. (edit: technically swift did this a long time too... but they also were reasonably sure they could include their runtime with the OS itself once ABI was stable, I am not sure if Deno has a path for this or if we just get fat binaries forever)
- top level await is a weird one to me, there are valid reasons its not in node currently. but yeah- no one likes having to write janky init code to work around this
final edit: I have a lot of opinions on this and would love to learn more about why deno is great. from what I can tell, its just a faster language of js which, imo, is great. But the points drawn from GP are just bizarre to me.
But what I’d like to question is why the idea of parsing everything is considered bad. Semver itself, while miles ahead of what came before, is still just lies we tell the compiler.
You can never actually rely on the fact that a miner fix will not be a breaking change and the like.
Rich Hicky had a great talk on the subject of imports and breakage, and the conclusion that I agree with was to actually load and check every function in all the libraries you use, so that if there is an incompatible change you will not be none the wiser.
I’m glad people are trying to experiment here, as package management is far from a solved problem and issues with it cause sweat, tears and blood to most devs during their careers.
1. people will import packages willy-nilly and not think about what they are doing and it becomes harder to understand WHAT they imported (the why becomes more clear imo), I am aware that is very much so JS culture today but I also believe that to be harmful.
2. Having to parse all files to find deps takes time, obviously not a ton of time, but it takes time, it simply doesn't scale appropriately
Working in finance - I think personally that it is really important to make changing the dependency chain something everyone should be VERY aware of.
Yes to download each url and walk the tree is going to take time. But it can be cached. Not sure how long it can be cached for.
The important thing about url only imports is that it’s a consistent layer to build new tools on top of.
- it makes a ton of sense if you don't want to maintain two different versions of the same library. With WASM there is zero need for Node native modules anymore, so there is no need to have platform specific idiosyncrasies that go beyond Web APS's. Is the fact that it's called "window" a favourite of mine? Certainly not, but when you try to get a library running that you really need, that was originally written for the browser or vice versa, you don't care what the thing is called, as long as it's backwards compatible.
- defense in depth, multiple sandboxes are better than one
- this has to do with the window point, it's a lot easier to make code cross platform compatible if you only have to reference publicly accessible http endpoints
- maybe that's not interesting for you, but I've had to deliver command line tools as binary, and I'm super duper happy that I could do so in JS, the security I gain from controlling the runtime version is also much better than what I'd get from that being the users responsibility, besides that fact that not knowing exactly which runtime your code is gonna end up on is also a big source of security vulnerabilities
-
- we have the chance to define a new and better API, we should do it - you are already adopting something different
- I agree, but its not a selling point, these things are probably in containers already and my OS should be doing most of the work
- window: just no, call it global if you must. perpetuating ideas like this isn't good for anyone but the lazy.
- I think the cmd aspect of shipping a whole binary is cool for sure, but lets not conflate this as a "compiled language" its not. you are shipping a runtime and a scripting language together.
The web has been paving the cow paths for good reason.
There are hills worth dying on, what the common namespace is called isn't one of them.
Deno's difference from node is the choice to implement web API instead of nodejs stdlib API
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
edit: but at the same time now I realize why people are attracted to it, they are desirable features wether or not they actually make sense.
URL-based imports are already something you can do in package.json if you really thought that was great. Top-level await really is trivial. The permissions system does very little for you since they are process-level permissions when I'm scared of transitive dep attacks. Typescript in Node is good and Deno has to catch up in tooling.
If Deno was where it is today but like 8 years ago, it would have made a splash. Now it just looks like someone made a few creature comforts to Node.
Though I admit it's not that fun for me to come in here to poopoo Deno.
I write a lot of short JS files that aren't part of a big cohesive backend, and little things like top-level await make the code somewhat easier to read. Yes, you can just do an async IIFE, but that's just another thing for the eye to parse and feels quite vestigial.
EDIT: And since I can't respond to your other comment, I'll ask this here; what do you consider great and important about Deno that doesn't fall under the bullet-points I listed? I'm simply curious.
Edit: just realized I gave no example.. an example would be a dep that has gone missing and there is no backup for it. Deno sort of handles this but all we have actually added is no centralized way to describe dependence. So if you dynamically import a package via its package manager you also need to write some code to ensure it even exists. how is that better?
- Typescript as a first class citizen: Agreed, it's not hard to get TS set up in Node, and it's a "one and done" cost.
- An actual `window` global with familiar browser APIs: I've never needed or wanted this, though I could see how the server-side rendering crowd could benefit, but I still have to believe there would by necessity be enough difference between the browser-based window that implementing SSR is still non-trivial.
- Sandboxing w/ permissions: I honestly think this is going to be useless. As you stated, if you're really running untrusted code better to rely on process permissions. This actually reminds me of many of the overly complicated security/permissions architecture in the Java SecurityManager stuff that I rarely if ever actually saw being used.
- URL-based imports (no need for NPM): NPM certainly has its warts, but I think a lot of Deno supporters woefully underestimate how most server-side JS developers love having a single primary global package repo.
- Bundling into self-contained binaries: Again, this is nice, but also gets a "Meh, I don't really care" from me.
- Things like top-level-await which Node.js still treats as experimental: Once you learn how to do an IIFE who really cares?
- Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks): Again, a minor nice-to-have, especially with Util.promisify.
This doesn't seem good?
If there is going to be a global object, then it might as well be the same one used in the browser, which everyone who writes JS is familiar with.
The structural and semantic differences between imports are a much more important discussion. Import syntax is the front end to the languages meta programming semantics. It's meta programming in the sense that your code and other code is the data, but what you're really programming is a task runner with specific instructions about how to find and satisfy the requirements to build and/or run the software.
Integrating package resolution into the language itself is a really important distinction for contemporary designs - passing that buck to external tools but simultaneously coupling them to the runtime is a mistake that I think we should learn from. Deno is a good step in that direction.
> - Typescript as a first class citizen
This doesn't seem to add much besides having to install `tsc` or `ts-node` and also not having the choice of the TypeScript compiler version you use.
- An actual `window` global with familiar browser APIs
Node.js has a `global` global object and the only API I would understand having in common with the `window` object is the `fetch()` API.
- Sandboxing w/ permissions
Sandboxing is so basic that any large project will have to enable all permissions.
- URL-based imports (no need for NPM)
I would consider this a disadvantage.
- Bundling into self-contained binaries
Again, I would say that this is rarely useful in a world where a lot of operations use container technology.
- Things like top-level-await which Node.js still treats as experimental.
This is trivially solved by anonymous self-executing functions
- Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks)
I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently.
Depends on your point of view. With TypeScript being built in, you don't have to think about using tsc or whatever version of TypeScript you have. It's just what version of Deno you use. If someone doesn't like that, then they still can have the option of using TypeScript by itself.
> Node.js has a `global` global object and the only API I would understand having in common with the `window` object is the `fetch()` API.
It also supports `addEventListener`, which is commonly used by browser code on the window object.
Just the existence of something defined as `window` makes more sense than a `global` which never existed in browsers in the first place.
> Sandboxing is so basic that any large project will have to enable all permissions.
That's pretty dismissive. Why should an app that doesn't interact with the file system be allowed to write or even read from it? I don't know how this feature can be considered a drawback. Don't like it? Don't use it. I don't see how it detracts objectively from Deno.
> I would consider this a disadvantage.
Then you can still use NPM. Others of us get the option to just import packages from a URL instead of publishing it to a central repository.
> Again, I would say that this is rarely useful in a world where a lot of operations use container technology.
Why? Building Docker images requires extra software, Linux images, time spent running apt-get or apk, time spent downloading and installing your runtime of choice, and so forth. Having Deno build a binary can give you a bit of a shortcut in that you have one tool for running and bundling code, and you don't need to deal with as many OS-level nuances to do so. Docker and k8s are there for anyone who needs something beyond that.
> This is trivially solved by anonymous self-executing functions
That's your opinion. Just promise me you don't go on to say that JS is a bad language, because people keep saying that yet are opposed to reducing complexity they consider "trivial". If using IIFE for the mere purpose of accessing syntax makes more sense to you than making `await` syntax available, then I really don't know what to tell you. What exactly is the argument for not implementing this feature besides "all you have to do is type some extra characters", to loosely paraphrase you.
> I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently.
> I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently.
I honestly have to wonder if you are joking. This is exactly why people invent new backends, new libraries, and new languages.
My only response to your point about Promises is that perhaps one shouldn't be using JavaScript if Promises are that much of a bottleneck. What you're saying is totally valid, though.
An example I shared few days ago here: https://news.ycombinator.com/item?id=26560464
https://deno.land/manual@v1.8.2/runtime/workers#specifying-w...
Because any app of a medium size and above will require access to all permissions. Also Deno had some obvious security vulnerabilities around symbolic links for example which really detracts from the supposed security goal.
> Why? Building Docker images requires extra software, Linux images, time spent running apt-get or apk, time spent downloading and installing your runtime of choice, and so forth. Having Deno build a binary can give you a bit of a shortcut in that you have one tool for running and bundling code, and you don't need to deal with as many OS-level nuances to do so. Docker and k8s are there for anyone who needs something beyond that.
But you are going to need some kind of operating system image anyway due to other tools that will need to live with your app like log shipping, load balancers, DNS caches, firewalls, daemons, etc. So in the end you will need to describe this somewhere and why not also describe the dependencies of your apps at the same time.
> If using IIFE for the mere purpose of accessing syntax makes more sense to you than making `await` syntax available, then I really don't know what to tell you.
If using IIFE is so heavy that a new backend platform needs to be built I don't know what to tell you. In the apps I see, there is exactly one top level IIFE that is needed in the whole application.
> This is exactly why people invent new backends, new libraries, and new languages.
New libraries yes, new languages no. The util.promisify() already makes 90% of the cases work painlessly and some promise wrappers for existing core libraries already exist on top of that. Since core is moving to promises slowly anyways I fail to see how this advantage will carry on being one in the future.
> My only response to your point about Promises is that perhaps one shouldn't be using JavaScript if Promises are that much of a bottleneck.
Yup, that's absolutely true. I would say that there is always an advantage in having leeway in a programming language between the convenient option and the fast option so that when something becomes a bottleneck you have easier options than porting it to another language. But of course this might not be the most common case.
some apps are just CLI tools.
Top-level await helps with the rigidity of the ES module systems[1]; I believe they can also be used with dynamics imports giving ES-modules and CommonJS similar expressivity
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
And is that really worth dumping loads of money into developing further? I just find it hard to believe people are going to bother with Deno any time soon - we’ve gone too far down the NodeJS road.
The other feature is TypeScript as a first class citizen which is pretty great for devs.
Sandboxing doesn't sound so unique or innovative when WASM is coming along and doing the same thing, and with a much wider audience and thus more likely to have massive traction.
As a glaring strawman if you expose eval to wasm it will not help you.
Deno's sandbox will allow you to crate a dedicated worker with no network/disk access to handle sensitive informations, or to force your application to use a specific worker as a proxy (by making it the only thing with network acess)
It depends on migration effort. Take typescript for example, it's very similar with JS that migrate the codebase is not that painful. If the standard library and package manager can prove to highly useful, we'll see two possible scenario that aren't mutually exclusive:
1. People migrating to Deno
2. Newer nodejs version follow what Deno has
In the end it's good for us
> Not every use-case of server-side JavaScript needs to access the file system; our infrastructure makes it possible to compile out unnecessary bindings. This allows us to create custom runtimes for different applications: Electron-style GUIs, Cloudflare Worker-style Serverless Functions, embedded scripting for databases, etc.
So it's basically more of a Redhat approach to making money from open source? They intend to build tailored services on top of Deno for companies that request them?
My read was that anyone could more easily configure a runtime to expose (or not expose) the underlying bindings that it requires, vs. just having them all in there by default.
I think "us" in that statement is the Deno community, not Deno the company.
But maybe I'm wrong.
I still find it strange that there is no mention of it in the post...
So if you're up for it, you can still roll your own deployment infrastructure and tailor your builds as needed etc.. and support all of that internally.
Or you can pay Deno to handle it for you and you can focus on building your apps.
I think the point being made here is that it will be easier to create purpose-built runtimes that only provide needed bindings, making them more secure and possibly also more performant?
JS/TS as languages are here to stay, so let's give them the best possible ecosystem.
If it was more along the lines of "I want to use this array helper library, but it shouldn't have any permissions" then it would be a lot more useful, but right now if your Deno app needs any file or network access, then all of your dependencies get access too.
We have so many dependencies that really only need to work in-memory and have zero IO needs. That part is not solved in Deno at all.
You might write an smtp daemon that only delivers email on to another service via LMTP - thus without ability to write to (or read from, depending on configuration) the file system, for example.
Yes, you can accomplish this via containers, too - but it's nice to get as much out of process isolation as possible, not to mention it is likelier easier to test and debug the closer to the surface of the runtime limitations are implemented.
Then what are all these modules, if not a standard library? https://nodejs.org/api
It certainly isn't that interesting for everyone, but for a subset of users it's great!
What's a "standard" for you? Whatever definition, I think it implies there are > 1 implementations of it.
Node.js is based on CommonJS APIs, an initiative lead and implemented by earlier server-side JavaScript (SSJS) runtimes at the time such as v8cgi/TeaJs, Helma, etc. until Node.js dominated SSJS around 2011. Remember, SSJS is as old as the hills, starting 1996/7 with Netscape's LifeWire, and arguably has seen even longer use than Java as a mainstream server-side language.
Also not a "standard" in the above sense is TypeScript.
As to "standard library", the core packages on npmjs plus package.json are the standard library of Node.js on top of core Node.js APIs, and were developed in that spirit.
Really what I mean by 'standard' in this context is a batteries-included experience for most day-to-day programming problems.
I can appreciate the minimalist view where every project selects a core set of libraries for the given challenge. On the other hand, a core set of libraries that are good enough for most things just reduces decision fatigue, and makes it easier to just code.
Keep up the great work Ryan, Bert & team. Exciting times!
We were consultants scaling node to production for a major international bank, circa 2016.
Love the security improvements in deno, will have to give it a look.
The leading app framework for that is Nextjs and I hope the Rauch Capital investment sígnals Vercel will be supporting Deno.
Anyone know?
$ deno run --unstable --allow-write=output.png https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/hello-triangle/mod.ts
Download https://crux.land/2arQ9t
Download https://crux.land/api/get/2arQ9t
error: Import 'https://crux.land/api/get/2arQ9t' failed: 404 Not Found
at https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/deps.ts:4:0
Another one:
$ deno run https://deno.land/v1.8/permission_api.ts
error: An unsupported media type was attempted to be imported as a module.
Specifier: https://deno.land/v1.8/permission_api.ts
MediaType: Unknown
> But JavaScript and TypeScript scripts calling into WebAssembly code will be increasingly common.
Why is WebAssembly a key concept here? How does Deno uses it?
It's essentially the route Java is taking with graal/truffle - allowing heterogeneous mix of languages to be compiled and optimized.
Why not allow typescript to use Fortran numeric libraries via wasm?
This is analogous perhaps to C# and F# within .NET currently. C# and F# have the same BCL (base common layer) so you can use C# code in F# and vice versa. WebAssembly is like that and much more.
.NET BCL is the Base Class Library. Outside of a few classes in it that are fundamental to the runtime (e.g. Object, String, Array), it's not actually required for cross-language interop on .NET platforms. E.g. if you have two different C compilers both outputting CIL, they can interop just fine without any objects in the picture. WebAssembly interop is really more like that, and doesn't have the high-level object model layer that .NET also has (and which is used in practice).
Clicking on 'Learn more about Deno Deploy' leads to https://github.com/apps/deno-deploy , which does not tell me more.
What does 'act on your behalf' mean for Deno Deploy?
Anyone else is running into this?
Few days ago, there was new version released (87). In certain situations, when silent upgrade had been made during using the browser it displays an "Oops, something went wrong" notification with a button to refresh. If you will close and reopen the Firefox the problem will vanish. It is less kind of crash but more likely as problem to free/monkeypatch resources.
I have run into the same problem on Linux but I have quite complicated Firefox configuration with at least few extra profiles (about:profiles).
Genuine question (I assume it is, but presumably it was before with c++) - it just strikes me that once something becomes as successful as node, and given that nothing is ever perfect it might be useful to clarify why the technical insight might be better this time around - at least regarding the idioms of the underlying tech; the added experience at the architectural and implementation side a given.
I haven't fully investigated in a few years, but isn't it still true that LuaJIT is is faster than V8 JavaScript? The last I saw it was outperforming V8 by a lot. The practical use of LuaJIT is still very niche though. The lack of a comprehensive standard library, and being forever stuck on Lua 5.1 makes it even less generally appealing. I still love it for programming Nginx though..
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Fact Check: False
LuaJIT is fastest than all JavaScript JIT implementations in existence.
Why is the Mozilla Corporation an investor in a Chrome based technology startup ?
And all Servo developers according to: https://paulrouget.com/bye_mozilla.html
Mozilla continues to be interested in Rust even though they did that, they’re a founding sponsor of the Rust Foundation, for example, and are continuing to use Rust even though they do not employ people to work on the language itself.
My only gripe with the Deno company is that taking investor funding is a double-edged sword. Yes, they'll get to hire very skilled developers. However naturally the investors want a tidy exit, and I wonder if that would be to be bought out by Amazon, Microsoft or Google.
Edit: Just realized that there's a key difference in that Deno does not have something like NPM to be bought and sold because dependencies are URLs and thus decentralized. Also, Deno itself is open-source.
I can see that Deno.listen returns an object which implements reader and writer interfaces, but it isn't clear to my how to look for events, such as disconnect or that new data is available.
I wish there were examples showing how to correctly parse frames or implement protocols.
I'm sure these things will be expanded over time, partly by programmers in the community, but from the outside, things are still a bit rough.
Well, I wish they would stop using it period, but at least in the browser it makes some sense.
Edit: to be clear, I have no beef with Typescript, Dart, Clojurescript, and the many other languages that compile into JS. It's JS itself I have issue with. I feel like it gives too much flexibility to young programmers to screw things up. There don't seem to be enough safeguards or training wheels. On large projects its my nightmare.
One of Deno's main selling points is that it runs typescript out of the box?
I know this might be hard to see, but Rust is actually in the same domain. It is also, among other things, enabling product/frontend/web engineers to build backend/native/browser-less applications.
I'd bet Rust will be more successful here, especially given its amazing ability to change itself and innovate.
Care to explain? I can imagine web programmers being productive in deno in a few minutes vs however long it takes to learn an entire new language, not to mention a language that requires memory management.
> "A language empowering everyone, but especially folks who thought that systems programming wasn’t for them.”
Many developers, I think, don’t look past web-first abstraction layers.
I can’t tell you how many times I’ve seen CLI tools which are huge chunks of node wrapping a thin bash command. They are multiple files, orders of magnitude larger than they need to be, and require external dependencies because these developers are fixated on their proverbial hammer.
It uses comet-stream instead of WebSockets.
But it's fully "joint" parallel on all cores.
In my opinion, the best part of node is (or was) that it didn't adhere to the browser APIs. That brought in some fresh air, and gave us buffers, native bindings, streams etc.
Ryan and the team should be capturing some of the value produced by their creation. And because of Deno's a developer tool, it's actually capturing the far minor part of the whole value and enable a much bigger value creation!
Trying to sell something based on FUD is always a bad sign.
However, I personally would prefer Go or .NET Core for my backend any day. We need to wait and see where it's going ...
Good luck and success anyway!
Chrome vs chromium etc
We all know how that turned out to be
History repeats itself, the above two are the recent incidents that comes to my mind
Heck, sign me up. Who wouldn't be up for that? What's the downside supposed to be?
So let me make clear here, if I ever start a company based on open source principles and it looks like I am going to get squeezed out of business by Amazon if I keep sticking to those principles I will probably abandon those principles (unless I'm already a billionaire and have something really cool I want to work on anyway) because damned if I would let Amazon beat me. The chance of my abandoning those principles will correlate closely to how bad my finances will be after losing out to Amazon.
On the other hand if I build up a big enough company and start making money off of using open source technologies as a service for other technologists I hope I would support the open source projects from which I was benefiting.
If you want to keep this option open, then make no such promises or (perhaps better) formulate the promises in a way that is aligned to the options that you do want to keep open for the company.
With respect, and without impugning your right to make this criticism, I find your criticism shallow.
I don't know what your particular circumstances are, but I see your view expounded a lot by developers who are getting their salaries from companies that can afford to pay them because they took VC money in the first place.
We are certainly not entitled to Deno for free (although the MIT license is in their best interests for now). I am glad they found a way to sustain its development for the near future.
No, they figured out a way to delete that problem.
VC money isn't a gift. It's a loan.
Edit: There is more to it, of course. It is also entry into a somewhat exclusive network of future investors + customers if you choose your VCs wisely.
My sense is that GPL3 gets a ton of criticism on HN, but isn't it the perfect defense against freeloaders?
* license the code for proprietary use in your stack * use GPL3 if you have a non-commercial use, and are willing to accept the requirement to open source your own code.
I don't understand why this option isn't used more by open source projects that want to be able to fund themselves.
Can anyone explain? (Even better if there are examples / case studies)
One possible reason is that such dual licensing requires copyright assignment from external contributors.
It is said that they can get away with having it as Public Domain because a key part of their business is SQLite's reliability which is asserted by their large and closed source test codebase.
Oh I didn't know (or forgot about) this! Super interesting. I love that strategy.
That's competition at its best. Don't assert any control over someone else, but do keep a few secrets to yourself so people know to come to you for the best stuff.
Also, it's nice that they're using Tokio for the HTTP server instead of a JS implementation (from what I understand). I want to see Deno near the top of the TechEmpower benchmarks.
Haha, this made me laugh hard, stopped reading
Every time I read something like this I realize how much in the minority I am. I am not a web developer. I have never written JavaScript before in my life. I hate working with “web-first abstractions”. I feel like it is just massive bloat on top of true native application. But given the popularity of things like electron, react-native, Node, and Deno I don’t speak for the majority.
And the thing is, I don’t know if I just learned web dev if I would love this new approach to software that is eating the world and I would “get it”. Or if it just exists because JavaScript developers don’t want to learn something new.
It's probably a big reason. But if you think about it from the other angle... you don't want to learn Javascript, which would be new to you :-)
I’m okay writing JavaScript as long as I don’t have to spend all day every day writing it.
I was primarily a PHP backend dev for 15 years who only used jQuery to toggle classes on click actions, but decided to try something new and switched to Node in 2015.
Node + ECMAScript 2015 just BLEW my mind and was so fun, that not only am I now primarily a Node dev, but I've excelled extensively in the frontend.
I've never enjoyed building websites or web apps as much as I have in the last 5 years.
I have began utilizing Node + React for frontend use cases but find that my build pipelines become incredibly cluttered and esoteric rather quickly.
Am going to explore wasm solutions, thanks :)
Would you mind providing some more details here? After Python packaging drove me batty for the last time, I wouldn't have described the switch to JS/CS/TS as "struggling"?
With respect to "build pipelines", you don't have to use grunt, gulp, etc. It's totally fine to have regular bash commands in npm scripts.
I love using it as a "one-off" scripting language which usually involves interaction with some sort of an existing codebase.
I'm also fairly confident in doing any sort of backend-centric work, in which existing components most likely exist as well (or at the very least something POC-esque to iterate on or scaffold from).
With that said I believe most of these difficulties stem from most of my experience being backend-centric roles, so when it comes time to implement a frontend from scratch, I become unsure of where to start. The sheer amount of technologies available and vast amount of flexibility is also very intimidating.
However I've been slowly but surely immersing myself in the stack(s), and have found that much like my experience with CSS the best way to learn is to simply do it-- making mistakes and learning from them in my exploratory learning.
I do appreciate what you said about build pipelines and feel much better about my current projects :-)
quick edit: I think my lack of experience in functional programming is another factor here, however Typescript's object orientated style is very attractive.
It solves the problem of how to run your non-web based code in a browser, but until it can interoperate with the DOM, JS will continue to be mandatory.
For example, see the wasm-bindgen and the generated web-APIs in web-sys: https://docs.rs/web-sys/0.3.49/web_sys/
A nice framework that takes advantage of this is yew: https://yew.rs/docs/en/
JavaScript consistently ranks as one of the most loved languages in Stack Overflow surveys...
I find plenty of counter-examples of this point on HN too - engineers who have worked across many different stacks and rank JS/TS as one of the best dev experiences they've had (there is one such comment in this comment tree)
Anecdotally, I feel as if pre-ES6 a lot of the complaints you read online were from users of the language. Nowadays, it's as if most of the complaints are from people who don't use it.
I think there is something to be said about refusing to learn anything but JS, as knowing different languages can be a boon for an engineer, but I believe it's an excellent tool to have in one's belt nowadays.
JS has warts, undoubtedly so. But I try to approach it like I would Clojure and it makes the experience much better for me. I think JS has the bones of a Lisp if you're willing to look for them. Sure it doesn't have macros or decent conditional expressions or immutability but using something like Ramda gets you some of the way there. And there are proposals for pattern matching and immutable data structures though they are fairly far off.
I think JS is at its worst when people try to code it as poor version of Java or C#. I have a bit of a love hate relationship with Typescript for this reason. Some aspects of its type system are great like being able to make a union out of anything, I wish OCaml had that. But I think denying Javascript's inherent dynamic nature is a mistake.
Overall I've learned to ignore its worst parts and just focus on what made it good from the start, being a weird cousin of Scheme that runs in the browser.
It takes time to learn an ecosystem, and when people know one ecosystem and not another, most people would rather do high skill, high value work in the ecosystem they know than start over as a noob in a new one.
The only thing unique about the web / JavaScript land is its ubiquity and size due to its place as the language of the browser. So anyone who can make an abstraction that lets JavaScript developers do stuff outside the browser without learning much new has a virtually guaranteed large audience of developers who are likely to think “I would love to be able to build X, I just don’t have time to learn a new ecosystem.” Those folks are then thrilled to dive in and use the new abstraction. And there are a lot of those people. And that’s why we are all stuck using Electron apps for so much stuff. :)
But that doesn’t have to be a bad thing. Electron can evolve to be less of a resource hog, and better alternatives are being tested all the time. The same is true for other non-browser applications of JavaScript.
I don’t know if this vision is reality, but I think that it may be that we’re in the early days of a transition toward the browser stack being the new “GUI.” Which is to say, back in the 80s there was a lot of debate around GUIs and whether they were a good idea etc., and while most people liked them to some degree, they also lamented the idea of losing the command line. But in the end, GUIs didn’t shrink the number of CLI tools in the world, rather they increased the size of the domain that computers are used for my making it more accessible to more people. I think that so far the web vs native debate seems to be following a similar trajectory.
Are you sure? I started building a desktop application recently. As much as I abhor Electron and refuse to touch anything built on top of it, there basically wasn't any other choice due to the absolutely massive amounts of libraries written for the web. I threw a couple of them in and it saved me at least 90% of work compared to what I would have to do if I'd chosen Qt (or anything else native). Would I rather spend a week and have something to show to my client, or roll up my sleeves and re-implement everything myself (which would take about half a year before I'd have anything working at all)?
(For the record, I didn't downvote you. I consider it a shitty practice to downvote somebody for their opinion, without even replying.)
I don’t disagree with you about why people use Electron. There’s a positive feedback loop around ecosystem sizes. The bigger the platform the more devs use it the more tools they make the more libraries are made the more it’s the easiest way to do X the more applications are written for it the bigger the platform gets.
Anything you can offer to a large group of developers that lets them extend their existing high skill level to new domains where they would otherwise be novices is very likely to be adopted.
It doesn't work if you need extensive access to local hardware. But if you're mainly on the network anyway to operate, it's very frictionless and relatively lean.
With my last app, the network asset bundle is about 2MB, uses only ~11 MB on disk on my Mac and ~25MB RAM when running.
Web apps are also a hell of a lot easier to secure these days (as long as you trust / validate the platform’s security, which should be in the contract anyway). Which is also why a lot of “native” apps are pretty much web apps with some wrappers around platform-native hardware integration.
But those wins must also be balanced with the loss of control due to those same platforms distrusting your app. Now your app, for all the wins it's going to achieve on maintenance and updating, is also going to take hits from its inability to do things that other people take for granted on native apps.
They are part of the same story of balancing pros and cons.
This is one of the main reason that I often prefer web apps. (my preference obviously depends on the use case) I would much rather run a random company's messaging/video chat/whatever app inside my browser with strong sandboxing. Because browsers have truly accepted that applications should be considered malicious by default.
Deno are in overlapy
|
|
| /---
/--- -- | /- \---
/--- \-- | /- Best |
| Coders \|- coders \
/ passionate /-|\-- in |
| about - \- world \
\ democratization - |
| of -\ -
\ technology -/ -\ -/
|---\ -/ -\ -/
---- -\ -/
--
Looks to me like they don't want to write stuff twice, and they would have had to write for the web anyway.
The web stack is not good by any measure. The native GUI toolkits are suffering form abandonment, so the web-based toolkits are among the best available (but not at the top). But if you don't have any reason to expect to create web code, your life will be better if you ignore the stack.
SwiftUI is new.
Flutter is new.
Both have taken birth recently and have huge investments and usage.
That was what propelled Atom and VSCode.
What you said is valid of course when you look at Slack and such, but you ommited most important cross-platform target.
Your app can run on Windows/Linux/Mac .. and the Web.
The old way gets _your_ job done _effortlessly_. idk, I guess that’s not ideal in the meat world.
I'm a fairly seasoned developer with experience shipping things written in Java, Scala, Ruby, Python, Perl, and JavaScript/TypeScript to large and high traffic systems and services. The tooling and developer experience of working with TypeScript is still the most pleasant I've interacted with. On the UI side, it isn't even close.
I think you'd be surprised how many modern applications are written in JavaScript or Python.
One of the more prominent ones is VSCode.
There is a case to be made for programmers being at least familiar with Unix utilities and shell scripting so that they can unlock the superpowers described in that anecdote.
However, I largely agree with your sentiment - I pretty much do all of my scripting in JavaScript and Python and would not be particularly happy to have to deal with a large bash script.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Let's go with WebSockets as an example. You decide you need them in the browser. This will likely mean some other component will have to support them too. By now you need a pretty good reason to reimplement it over something else. If you need a handshake you may exploit the fact that WebSockets open with a standard HTTP request. Your handshake over another socket may look pretty different. DDoS services, proxies etc may support WebSockets but not arbitrary TCP or they may support it differently. A WebSocket "message" doesn't exist in plain TCP, will you make your TCP protocol work the same or will you handle frames differently?
Point is - your choice may be between just WebSockets or WebSockets AND something else.
But in a serious answer to your last sentence ” And the thing is, I don’t know if I just learned web dev if I would love this new approach to software that is eating the world and I would “get it”. Or if it just exists because JavaScript developers don’t want to learn something new.”
My opinion is the answer is a resounding “No, you will not just get it”.
This is a complicated question of course, but to distill my thoughts down
1) You do not need to view web development as a threat to your skill set. You didn’t say specifically what stack you work in, but I have to believe that you will be able to continue making a living in it.
2) Tools like Deno are specifically designed for and intended for web developers to be able to easily leverage their skill set in other areas like systems.
So if your not a web developer, and you don’t have a particular interest in learning web languages/ APIs, then don’t worry about it. Just because it’s trendy right now doesn’t make it a better approach technically speaking. It’s quite possibly worse than the approaches you know.
So what I’m saying is this tool isn’t meant for you. And that’s ok. Just because it makes HN front page and web development is huge right now, doesn’t diminish the tech you know to be good.
Last sentence of the blog post: ”The Deno company hopes to enable the millions of web programmers out there to maximally leverage their craft in other domains.”
Most popular, I can agree. Fastest, & only one with industrial standardization process? Have they met Erlang?
edit: you have to be kidding me, downvoted to oblivion for an honest observation. Sorry I hurt javascript's feelings.