Code splitting is supported just fine for ESM bundles[1] (and there is little reason to use other formats nowadays), CSS handling works ok as well. I have been using ESBuild since forever and the only instability that I experienced was around sourcemap generation early on.
That's why we introduced the strict mode ("use strict" pragma)[1]. Among other things, it prevents from accidentally declaring a global variable this way, throwing a ReferenceError.
Actually, at this point, with the prolifiration of strict mode and linters, I'd say that these old gotchas mostly belong to quizzes and spec discussions, since personally I have not seen new code written this way even in vanilla JS for years by now.
I should apologize, my normal way of writing made it seem like I wasn't sure about having seen it but I was sure, I often use phrases that imply inexact information (for example: I guess) when what I mean oh yeah, I am sure about this thing.
Great to see dprint on the front page! While here it's speeding up prettier with caching/wasm, it can replace prettier altogether and be even faster (for example, with `dprint-plugin-typescript` for TS/JS dev). So, if you are doing web dev and not yet ready to switch to Deno, you can at least speed up formatting by using `dprint`.
David, I already owe you guys more beer than I can buy for all the great work on the Deno toolchain, but if we could get this issue[1] with HTML template tags going, it would be easier for me to convince the Lit crowd to chip in. Tanks again for the great work!
It's definitely something I would like to implement. I haven't found a parser that would be good for formatting yet so maybe I will have to write my own :/
Leo, your comments save me a lot of typing on threads like this, and since I recently wrote[1] what beeandapenguin wrote above almost to a point (sans security), I feel obliged to expand a bit.
You are right about incompatibility being a major issue; Deno recognizes that as well, hence, they are working on a compatibility mode that allows using Node specific libraries in Deno[2].
> migrating to Deno is, charitably, likely a monumental task that nobody would ever undertake, even considering the upsides.
This is, of course, contingent on the architecture used: for code tightly coupled to frameworks/runtimes it is indeed a monumental task. I have two small to mid size SaaS apps happily running on Node.js, but I'm looking forward to replacing it with Deno solely for the streamlined DX. The apps follow DDD architecture, thus, framework specific stuff is decoupled into a service/adapter and changing it is a day's work. The major technical road-block for now is indeed incompatibility of third-party libraries/SDKs written for Node.js (google sdk, mongdbo driver, etc.).
Yeah, this is primarily what I'd expect would hold back migrations, both in actual technical terms (e.g. Deno-flavored libraries for some tasks may not exist at all) and buy-in from engineers. Don't get me wrong, I'd love to seriously consider Deno for our (very large) codebase (a 1000+ package monorepo with 400+ engineers committing), and I say this as someone who's successfully lead a number of massive migrations for this monorepo. But Node -> Deno at even 1/100 of this scale is, in my mind, potentially orders of magnitude more difficult than even a monorepo-wide Flow -> Typescript conversion, which is already fairly daunting migration.
I have moved all my library development to Deno and described the experience in a blog post[1].
To summarize, the two killer features for me are Web APIs and the built-in toolchain.
I understand the skepticism other Node devs have when faced with Deno. I have been using Node since 2010, and there is hardly anything I cannot do with it (or didn't do at one point), yet Deno makes a lot of these things much simpler. My last straw was trying to run Jest tests on TS code compiled into a Node.js ESM module. I believe I spent more time figuring out workarounds for a myriad of issues in Jest+ Node+TSC chain, than it took me to switch to Deno where all of it came out of the box.
thanks for posting this. Much needed.
When you said:
> The process of reconciliation has been slow and painful, cue ESM modules.
I too have run into the similar issues when trying to use JS isomorphically. Especially in combination with typescript. Just wonder how Deno is addressing this? For example: when es import for module server side, in typescript it is ok to omit the file extension, (in typescript development mode it is expecting .ts files), however that breaks when the same code is run on the client side or production mode when it is tsc. How is Deno dealing with this issue? Does Deno just compile all the code to work in broser, serverside typescript all together?
Yes, TS code is compiled to run in browsers. You can compile and bundle using `deno bundle` if your project is developed in Deno. Since I'm using Deno for library development, I use the `dnt`[1] tool to compile them into ESM modules later consumed by esbuild in my Node-based projects/toolchains.
To be fair we have most web APIs that Deno has in Node with the exception of some we probably don't want to have. Namely: stuff like URL, fetch, AbortSignal, EventTarget, BroadcastChannel and a few others.
We can still appreciate that Deno puts some "pressure" on Node to continue improving and to copy any good idea Deno might introduce, which is a net win for everyone, even if most people continue using Node.
I was a little confused at first, but I think you mean “killer features”. “Killing features” is not idiomatic, and has kind of the opposite (i.e. negative) connotation
By any chance, are you aware of any good surveys comparing the open models to the cloud providers for other NLP tasks like speech recognition or POS tagging?
Sounds almost too good to be true, but here is hoping for the best.
> Opus audio decoder (enabled)
Considering the track record of codec support, I bet it only works when packaged as CAF, singed by QuickTime, and played during the daytime to a limited audience... I joke, but the amount of gotchas I encounter while working with WebAudio API is mindboggling and reminiscent of good ol' days of IE6. Would you guess that despite all three browsers declaring support for audio recording (MediaSource API) and all three supporting opus on paper, there is no way to produce the same opus file in all three? Safari only supports playing opus in <audio> tag, no recording; Chrome doesn't support ogg, and while both Chrome and FF allow you to record opus in webm container, the resulting file is not seekable... There are of course third-party solutions, but it's just sad to watch in the century of the fruitbat.
I just spent the weekend banging my head against the wall trying to record and upload audio in Safari. Chrome and FF were relatively easy. Know of any good open source examples or documentation on how to do this?
It really is sad that something so simple is so hard. I refuse to pay 10 cents a minute to a third party.
