maga
Joined 15 years ago
Joined 15 years ago
> 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.
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 ;)
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.
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...
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
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...
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
[email protected]