maga

Thank you!

> The trick then is a sliding scope context window: with a high-level design doc in context, iterate to produce an architecture document.

Absolutely, I will be stealing this!

> It's a very exciting time, it feels like having worked by hand for decades, only to now have access to power tools and heavy machinery.

Very well put, captures my feeling precisely.

Apologies, no offence to New Yorkers (or the New Yorker) meant.

If you find my handle, "maga", interesting..., I'll have you know that it's been around long before it was appropriated by some movements in US and has nothing to do with them ;)

> It’s unclear whether the suggestions and techniques mentioned in the article came from personal experience or have otherwise been verified or experimented with with a real team and a real project.

Since it's not a New Yorker article, I was hoping to spare the audience a long personal life story and deliver a somewhat succinct list of suggestions that others might find useful.

However, the question is valid, and yes, this is the result of personal experience of following and incorporating AI tools into my own development over the last couple of years, as well as watching my colleagues of various experience levels (in a team of 10 engineers) do the same. These are the practices that we collected, adopted, and trying to codify and develop further.

What was the reason behind not clearing outdated flows automatically?

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.

[1] https://esbuild.github.io/api/#splitting

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.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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!

[1] https://github.com/dprint/dprint-plugin-typescript/issues/9

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.).

[1] https://itnext.io/moving-libraries-to-deno-the-whys-and-hows...

[2] https://github.com/denoland/deno/issues/12577

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.

[1] https://github.com/denoland/dnt

Good catch, thanks!

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.

[1] https://itnext.io/moving-libraries-to-deno-the-whys-and-hows...

edit: spelling

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?

If it's speed you are looking for, give dprint (https://github.com/dprint/dprint) a try, it has a vscode plugin too.

Why not dprint[1]? Does it not "produce a concrete syntax tree (CST) that represents the original code completely, whitespace, comments and all"?

I'm not terribly familiar with the architecture of dprint, but it's used in Deno with JS/TS plugin and works great so far.

[1] https://github.com/dprint/dprint

In the end, I went with this library for now: https://github.com/chris-rudmin/opus-recorder

There are issues reported with the latest iOS, though.

A common reference to the modern (ergo enlightened) age in Terry Pratchett's Discworld series: https://wiki.lspace.org/Century_of_the_Fruitbat

Sorry for the confusion, I'm high on caffeine.

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.

> You’re still missing much the point of the article: WASM isn’t for the browser only. WASI, for example, is a full environment you can run stuff in without any such interoperability cost.

Of course, but we are not arguing about the point of the article, I'm contesting the exact claim that "WebAssembly is almost always faster than JavaScript". Admittedly, not because it's such a big mistake on the author's part, but because I'm a bit irate with the usual flow of discussions about WebAssembly here on HN that take this claim for granted and regurgitate it incessantly. This is not the case for the mentioned reasons: data copying overhead and JS itself being compiled by JIT resulting in pretty performant code if well-optimized. Also, the comparison to JS only makes sense when we are talking about running both in the JS engine, not against a dedicated WASM runtime, otherwise it would be tantamount to arguing that Java is not faster than JS.

By the way, if someone really wants to dig into the issue I recommend an article from one of the V8 authors where he dissects one such WASN success story: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...

You do realize that I didn't put up those benchmarks and wrote the article way back in 2017 just so that I can pick on a passage in this article? I was (and still am to a degree) excited about WASM, actually ported a significant chunk of my business logic from JS to C++ only to discover that the whole thing offered only ~20% performance boost, which didn't merit maintaining a whole separate toolchain. I'm not questioning the exciting results that Figma and such achieve, I'm saying that it's not "almost always" a case, and it's disingenuous to present it as such.

And how is the data going to reach the "unshackled" WASM in the browser, for example? I'm not aware of any way for the web page to interact with WASM other than through the JS land with the said overhead. The article explicitly mentions usage inside the web page and presents WASM as a performant alternative.

And that's another thing about JavaScript engines--they evolve and usually result in better performance. The article is written in 2017 and the results are from Node.js of the time, meanwhile the results in the repository are from the last year.

Yep, that's it. And the data marshalling overhead is even more pronounced with the native addon example (N-API Addon). But that's the thing, it's not "WASM always faster than JavaScript" as the author presents it. And on top of that, JS engines are no slouches either, you can optimize JS code to be pretty competitive in terms of performance even for computationally heavy tasks.

WASM is _predictively_ performant, being less subject to the vicissitudes of JIT, and offers better startup performance, allows for code reusability for existing C++/Rust code, but it's not a cure-all performance solution.

> “Near-Native Performance”: Wasm is often described as having “near-native performance”. What this actually means is that WebAssembly is almost always faster than JavaScript, especially for compute-intensive workloads, and averages between 1.45 and 1.55 times slower than native code, but results do vary by runtime.

Yeah, nah: https://github.com/zandaqo/iswasmfast

JS is about 10x faster than wasm in simple linear regression, and 30% faster in levenstein distance calculation.

As a younger man I was a bit overzealous about this, and having an "assertive personality" (as someone put it) it was mostly me putting the pressure on my drinking peers. On the hand, I was incredibly lucky to find likeminded friends as a student and we needed no extra substances to enjoy each others company, although, people seeing us constantly laughing would assume otherwise. It still puzzles me when people call other people friends but need a drink to relax and/or enjoy their company.

> For those of you who don't drink, how do you fill your Friday and Saturday nights?

As life-long teetotaler, I always had more things to do than time: hobbies, sports, or simply talking to friends and family. I might be workaholic, since most of time I cannot find time for those things because of work, but if/when I do have free time the possibilities seem endless.

It's Saturday evening where I am right now, I'm going to work some more and then do some chores while listening to an audiobook. But if I were not working, I'd be in the gym for couple hours and then meeting someone.

Vanilla JS nowadays means not using a framework, in yesteryears it meant not using jQuery, in either case, it doesn't preclude from having dependencies.

This is great news! Good luck, Luca!

> Better support for explicit resource management

+1

Since everyone is making feature requests, I'd like to point out `ArrayBuffer.transfer`[1] -- ability to effectively move data without copying would do wonders for low-level/high-performance code in JS.

[1] https://github.com/tc39/proposal-resizablearraybuffer

And another one: Structurae[1]

[1]: https://github.com/zandaqo/structurae

> Magnetic therapy

The practice is still pervasive in CIS/Russian medicine despite being considered pseudoscience[1] by the rest of the world. You're almost guaranteed to be prescribed electromagnetic therapy if you're recovering from any sort of tissue injury.

[1] https://en.wikipedia.org/wiki/Magnet_therapy