[HN Gopher] Deno Is Webby
___________________________________________________________________
Deno Is Webby
Author : todsacerdoti
Score : 157 points
Date : 2022-03-16 20:21 UTC (2 hours ago)
(HTM) web link (blog.jim-nielsen.com)
(TXT) w3m dump (blog.jim-nielsen.com)
| dpweb wrote:
| Efficiency seems to be a real priority w them. I like the
| simplicity in Deno Deploy also. You literally get a text box and
| just type in your cloud function. You don't have to install cli,
| set up tooling, for a quick try out.
| vlovich123 wrote:
| Shameless plug. Disclaimer. I work for Cloudflare. Have you
| tried Workers? You can do the same in a playground [1].
|
| You can also do the same by deploying a worker through the
| dashboard UI (including writing the code). Nothing to link
| though because you need an account. The playground is limited
| in what it can do because it's not deployed. You can also use
| Pages to point at a repo which lets you build a website and
| server side code (through Pages Functions which actually runs
| your code in a worker).
|
| [1]
| https://developers.cloudflare.com/workers/learning/playgroun...
| dpweb wrote:
| Yes big fan of Workers and Cf. The only issue it was
| confusing tying the domain to the worker, but that was a few
| years ago - last I tried it a couple months ago seemed
| easier.
| qbasic_forever wrote:
| Please purchase Deno the company before dismantling their
| only source of income through deno deploy--deno the tool is
| too nice to lose!
| jokethrowaway wrote:
| I agree on the premises, it's nice to have an open standard - in
| practice the API available on the web is usually a downgrade in
| developer experience.
|
| Think about the old node library request vs fetch, require vs
| import/import(). I hope deno has Buffers and I won't have to use
| atob / btoa.
| dexwiz wrote:
| This is nice, until its not. I have spent a fair amount of time
| over the last several years trying to make node act like the
| browser, or vice versa. It's doubly confusing to juniors who
| don't understand the difference between a language and a runtime.
| alert() looks like a standard function and should be specified by
| the ECMAScript Language Specification. But its actually specified
| by the HTML standard, because its Window.alert(), and
| Javascript's scoping rules let you call it simply as alert().
| Trying to explain what's JS and what's Web is really difficult,
| and design decisions like this only muddy the waters.
| wbobeirne wrote:
| TypeScript is really helpful for this because you can specify
| what runtime(s) you expect your code to run in with the `lib`
| configuration. Looks like Deno provides its own versions of
| libraries: https://deno.land/manual/typescript/configuration
| runarberg wrote:
| There is a TC39 proposal for a standard library[1]. One of the
| ideas reserves a URL scheme built in modules. So to import from
| a language defined standard library you would use the "js"
| scheme (import Temporal from "js:temporal") and importing from
| the runtime you could potentially use e.g. "web" scheme (import
| AudioContext from "web:audio-context").
|
| I really hope we will have something like that. It would both
| give us the option of never using magical globals and make the
| distinction clear whether the module comes from the language or
| the runtime. Although I can see a case where it could get
| annoying if you are writing for multiple runtimes and need to
| get e.g. fetch (import fetch from "runtime:fetch").
|
| 1: https://github.com/tc39/proposal-built-in-modules
| gavinray wrote:
| This has also unfortunately been my experience, even when
| working with developers that have several years of experience
| writing JS.
|
| There seems to be a big gap in knowledge when it comes to
| boundaries between the language specification, runtimes, and
| innate abilities.
|
| People consistently confused about why they can't use JSX
| without a build-step, not understanding that JSX isn't "real",
| why doesn't fetch() work in Node, why does code in my Next.js
| app break randomly (server vs client render context).
|
| Lot of pain in trying to explain to folks that a browser and
| Node are two different universes that happen to speak the same
| general language.
|
| There's too much magic in this ecosystem and not enough
| emphasis placed on taking the time to understand the tools you
| work with, IMO.
| brundolf wrote:
| > Lot of pain in trying to explain to folks that a browser
| and Node are two different universes that happen to speak the
| same general language.
|
| That's exactly why it's so good that Deno is trying to close
| the gap. More consistency = fewer surprises.
| seanp2k2 wrote:
| speaking of next.js, it's always fun to watch web tech come
| full circle back to "maybe we should render this stuff before
| we send the bits, since servers and CDNs are real real good
| at sending bits real real fast, instead of making everyone
| render the same static stuff a billion times per day client-
| side". https://en.wikipedia.org/wiki/Movable_Type was
| generating static blogs back in 2001, and that's still a
| great idea 20 years later. I'm glad that "modern" JS thinking
| has finally caught up :)
| mattigames wrote:
| The people that don't understand the difference between a
| language and a runtime always need to learn it at some point if
| they keep working as programmers, and context issues exist on
| all branches of human knowledge, even English itself has this
| quirk where some words mean the opposite depending on the
| context (these are known as contronyms).
| dfabulich wrote:
| I think it's even worse than that, because by being "webby"
| here Deno has committed itself to alert(); multiple browser
| vendors (including Mozilla) have advocated removing alert()
| from the web platform.
|
| (They want to do that because alert() "stops the world" by
| blocking the main thread event loop, and because they make it
| easy for a site to post a message that appears to come from
| Chrome itself, or from another website.)
|
| https://groups.google.com/a/chromium.org/g/blink-dev/c/hTOXi...
|
| > _We're on a long, slow path to deprecate and remove
| window.alert /confirm/prompt and beforeunload handlers due to
| their role in user-hostile event loop pausing, as well as
| phishing and other abuse mechanisms. We've been successfully
| chipping away at them in various cases, e.g. background tabs,
| subframes with no user interaction, and now cross-origin
| subframes. Each step is hard-fought progress toward the
| eventual goal, and we should consider carefully whether we want
| to regress, even in an opt-in manner._
|
| Rich Harris has a good blog post about this.
| https://dev.to/richharris/stay-alert-d
| seanp2k2 wrote:
| >beforeunload handlers ooh no, how will sites tell me that my
| free offer will expire if I navigate away?
|
| But on the serious side, this is useful for many antiquated
| apps (e.g. government stuff) that break tons of stuff if you
| attempt to re-submit a form, use the back button, etc, so I
| see that causing a ton of problems.
| cxr wrote:
| > I have spent a fair amount of time over the last several
| years trying to make node act like the browser, or vice versa.
|
| And the right thing to resist doing either. It's to think about
| what "services" your program actually needs to be able to
| function and then to isolate those parts from the rest of your
| application by putting it behind a well-defined interface. In
| other words, the best way to fix the incompatibility problem
| caused by API mismatches is to never make the mistake of coding
| directly against the host platform's APIs to begin with. Trying
| to do it with compatibility shims to make one platform look
| like the other is a fool's errand. You end up running around
| trying to achieve parity with a mammoth API surface area (which
| might never have been especially well-designed to begin
| with...).
|
| Let's say you're implementing a program similar in scope to
| UNIX's file(1). For our example, though, suppose you're really
| only concerned with text files and specifically whether a given
| text file is using DOS-style CRLF line separators or UNIX-style
| LF terminators. You really only need two capabilities: a `read`
| operation to get the contents of a file and a `print` operation
| to show the output to the user. Does your program care whether
| that `read` is happening with a Web standards-backed FileReader
| or NodeJS's proprietary `fs` module? There's no reason it
| should. Design the best "system" layer that makes the most
| sense for your application's needs.
|
| You can see this implementation strategy in the way the
| TypeScript team wrote the code for the TypeScript compiler
| itself when it was made public. Even in the early days, it
| could run on multiple platforms--including NodeJS,
| JScript/Windows Script Host, and various browsers (old or
| new)--because it didn't overly concern itself with anything
| except its real job of lexing, parsing, and type-checking its
| inputs--wherever they came from--and then writing the output in
| a platform-agnostic way.
| henning wrote:
| > You Might Not Need NPM
|
| If it's like every other JavaScript project I've been on since
| 2016, it's going to actually require thousands of JavaScript
| packages and doing everything with it is going to be slow as
| molasses even on high-end developer workstations.
| k__ wrote:
| Coming from PHP to Node.js back in the days it felt like quite
| an improvement.
|
| In PHP reinventing the wheel was one of the biggest issues.
| dpweb wrote:
| I think the problem was/is a generation of inexperienced
| developers who were brought up on importing packages for
| padding a number. Thing that always struck me was how easy and
| free it was to publish.
|
| Kinda fun to imagine a packaging system where you have to pay a
| very small crypto fee to publish. I'd bet less packages but
| more useful stuff on the whole.
| cdrini wrote:
| One benefit of deno on this front is that it _only_ pulls down
| the js files you actually need. With npm, even if you only
| import one file from a package, every single other file will
| also be downloaded to your computer. And probably some test
| files, a bunch of package-lock files, maybe some branding
| images. Oh and the same for all the packages it references,
| too. The storage/download time savings of getting just the js
| add up a _lot_ more than I expected. I've toyed with deno on a
| few projects, and my entire deno cache is smaller than any
| single node_modules directory.
| qbasic_forever wrote:
| Deno has a standard library that wants to be 'batteries
| included' so you don't have nonsense like a third party package
| for left padding a string (deno supports string padStart
| natively for this for example).
| yuchi wrote:
| Sorry but padStart/padEnd are part of EcmaScript 2019 (or
| near that year). Deno did not implement it. (AFAIK)
| mrbrownt wrote:
| Both are implemented in deno per MDN's compatibility table.
| Ruphin wrote:
| Deno does not have its own javascript implementation, it
| uses the V8 javascript engine, and V8 happens to
| implement padStart and padEnd.
|
| V8 was originally created as the javascript engine for
| Chrome, but it is used in many products now, including
| Node.js and Deno: https://v8.dev/
| vlovich123 wrote:
| That's true for padding. Deno is still doing a lot to
| standardize on the web platform APIs to be part of the
| base runtime available and that's work they're doing on
| their own and not for free as part of v8. This is similar
| to what we do at Cloudflare and I think there's similar
| efforts within Node in 17 for what it's worth.
| jakear wrote:
| Everything supports padStart natively, for almost half a
| decade by now.
| qbasic_forever wrote:
| I'm referring to the left-pad package on npm that
| infamously ignited a huge controversy years ago and started
| some of the cracks in the entire ecosystem that are growing
| larger and larger today. For more context:
| https://qz.com/646467/how-one-programmer-broke-the-
| internet-...
| o_m wrote:
| Deno is also creating a standard library, so that too should
| reduce the amount of external packages you'll need.
| jay_kyburz wrote:
| This is the real power of Deno!
| the_duke wrote:
| The Deno standard library is not bundled, but separately
| fetched as a dependency for each embedded file.
| qbasic_forever wrote:
| That's a pedantic argument, the deno standard library
| doesn't depend on any other library except itself and
| deno's core. You can know if you depend on it that you
| don't have dozens or hundreds of other dependencies, unlike
| pulling in a random npm package.
| lvass wrote:
| I'm simply unable of not reacting to someone so exhilarantly
| rejoicing you don't need a third party library for taking user
| input with cynicism. Am I living in a bubble, or what the hell
| went wrong here?
| brundolf wrote:
| I cannot help but root for Deno whenever it features on here. It
| offers such a wonderful potential future for JavaScript. It's not
| fully-baked yet, but man, it solves so many problems in one fell
| swoop.
| spacemanmatt wrote:
| It's so good I worry about the Betamax effect
| hyperhopper wrote:
| What betamax effect? Didn't it fail since the cartridge
| design was worse and also held less tape than vhs?
| wwweston wrote:
| Whenever someone has asked me "what would you change about
| Javascript" for the last 15 years, my answer has usually been "it
| badly needs a standard library."
|
| The standards committees have partly advanced that and Deno is
| following those leads, but I've got my fingers crossed that Deno
| will also fill in gaps (and those will make their way back into
| standards committee considerations).
|
| (My other answers have been more ... controversial, like: make []
| false-y, add macros, and bring back `with`!)
| __ryan__ wrote:
| A couple of questions: "Make [] false-y"
|
| Why? "Add macros"
|
| Why? How? "Bring back `with`"
|
| Why?
| SonOfLilit wrote:
| Not GP, but I really like [] being false in ruby and python
| because I often want to ask "is this variable that should
| hold a collection holding a collection of things, or is it
| empty/false?"
| djur wrote:
| [] is truthy in Ruby. Only false and nil are falsy.
| emmelaich wrote:
| Yeah, sadly zero is not falsy in Ruby.
| hyperhopper wrote:
| Luckily, most languages have a `.empty()` method! You
| should use that instead for readability purposes.
| dschooh wrote:
| [] is truthy in Ruby but there is #empty? on collection
| types. Rails also has #blank? which additionally works on
| false and nil.
| PufPufPuf wrote:
| I always found it strange that in Python, stuff doesn't get
| implicitly cast to string (even Java does that!), but for
| whatever reason the idiomatic way to check if a collection
| is empty is to do "if collection:", implicitly casting to
| bool.
| recursive wrote:
| [] should be falsey so it can be used in an if().
|
| I'm not sure about macros.
|
| I kind of want to see `with` back also. The problem with it
| was ambiguity. The syntax could be adjusted to avoid the
| ambiguity. .e.g `.prop = val;` could be legal inside the
| block. But "why though" you ask. A `with` block makes it
| visually obvious that a block of code is specifically
| relating to getters/setters on a particular object instance.
| adam_arthur wrote:
| I'd argue truthiness implicated by the presence of an
| object is more logical than having an arbitrary definition
| of truthiness depending on the data type.
|
| If I have a cup that's empty, there's still a cup there.
| It's presumptuous to assume I care about the contents.
| recursive wrote:
| In that case "" should be truthy. And 0 should be truthy
| too probably.
| adam_arthur wrote:
| They should be, to have consistency in design. Note that
| if the language operated this way, checks on these types
| would be more explicit (though more verbose too).
|
| Checking for presence of a number with a truthy check is
| a common source of errors, if 0 is a valid number.
|
| I just don't agree at all that Python's interpretation of
| truthiness (or equality, for that matter) is the right
| one. If I clone somebody are they equal because they have
| the same genetic makeup? No
| ckolkey wrote:
| Yes and yes. Ruby got it right, no question :)
| wwweston wrote:
| There's a presumption either way. You can make the
| presumption JS did for [] (and there's probably no
| turning back), you can even argue explicit is better than
| implicit (vs the value of context-sensitive concision).
|
| But it's also not consistent with the ways that other
| empty but typed cups are treated ("" for the empty
| string, 0 for empty count / quantity, both of which are
| false-y). Different presumptions for different types of
| cups carries its own implicit hazards from context
| sensitivity.
| PufPufPuf wrote:
| What about not making [] any kind of boolean? Let's be
| explicit and use [].empty() or something, implicit
| conversions are confusing.
| dgb23 wrote:
| Macros with a standard library would have saved us from many
| compatibility and bloat issues when they would have arrived
| before things like the class keyword.
| brundolf wrote:
| Gonna guess you're a lisper ;)
|
| Definitely it's biggest warts are around core data types -
| mainly the implicit-casting rules - but those are also
| impossible to change at this point. "Don't break the web" and
| all that.
| wwweston wrote:
| More like wannabe lisper. Maybe someday I'll land that
| Clojure job.
|
| And yeah, making [] false-y would probably do bad
| compatibility-breaking things. That's from the department of
| wishes more than good practical going-forward choices.
| mcintyre1994 wrote:
| > You can log and style CLI output the same way you do it in the
| browser's developer tools: using what you know with console.log
|
| > console.log("%cHello World", "color: red");
|
| TIL, neat! If anyone else did too -
| https://developer.mozilla.org/en-US/docs/Web/API/console#sty...
| looks great
|
| Using alert/confirm/prompt for CLI tools is nice too, makes a lot
| of sense to build that in and use the web APIs for it.
| amenghra wrote:
| Take a look at the developer console when visiting
| www.facebook.com
| thoughtpalette wrote:
| console.trace looks sweet. Thanks for the link.
| thylacine222 wrote:
| And Zendaya is Meechee.
| rr808 wrote:
| I love the idea of deno over Node. Is it getting traction though?
| binarynate wrote:
| One of the things I love about Deno is that since it implements
| standard web APIs, many libraries built for the browser just
| work. For example, I recently made a simple static site generator
| with Deno to make my blog, and I found that I could use Marked
| for markdown support simply by importing it like this:
| import 'https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js';
| // now I can use window.marked()
| favorited wrote:
| One of the many things about Node that Dahl explicitly wanted
| to "fix"* when building Deno was that the global namespace
| should be `window`, because that's what it is in JavaScript's
| natural habitat.
|
| *scare-quotes because the reader might feel strongly opposed to
| the term, not because I have an agenda
| tshaddox wrote:
| That does seem like it will break a common pattern in web app
| code that runs both in browsers and on a server (such as a
| React app with server-side rendering) to determine whether
| you're on the browser or the server, which is to check if
| typeof window === "undefined".
| lucacasonato wrote:
| You should be branching on the existence of `document` to
| discover if you are running in a DOM context, not `window`.
| Using `window` to branch SSR and CSR code will also
| inevitably will give false positives/negatives in workers
| and worklets when used in libraries.
| treyhuffine wrote:
| A lot of the time that pattern is written, it's because the
| APIs from the web and Node are different and will break if
| you call something that's not isomorphic. Perhaps Deno
| fixes that as well and the pattern isn't needed in the
| first place. Obviously not every case though.
| danbolt wrote:
| > that the global namespace should be `window`, because
| that's what it is in JavaScript's natural habitat.
|
| Oh wow, I had no idea. That rules!
| afiori wrote:
| ecmascript now has both `globalThis` and `self` that can
| act as global namespace (they all point to the same object
| except in workers as window and globalThis cannot be used
| in workers)
| moron4hire wrote:
| No, `globalThis` _is_ available in workers. It points to
| `self`. On the page, `globalThis` points to `window`.
| `globalThis` this becomes the one, safe, global reference
| you can make for coffee that runs in both pages and
| workers.
| colejohnson66 wrote:
| That just seems worse than what npm/yarn have. Despite Node's
| flaws, at least those have a hash check on the downloaded
| package against what's in the lock file.
|
| EDIT: I was wrong. See @spoiler's reply.
| spoiler wrote:
| So does Deno: https://deno.land/manual/linking_to_external_co
| de/integrity_...
|
| It's not part of a package manager, because there isn't one,
| though.
| colejohnson66 wrote:
| Ah. I stand corrected.
| russellbeattie wrote:
| I'm sorry but all those examples and Deno's documentation in
| general should be in JavaScript. I respect the devs right to
| choose which ever language they want, but Deno seems to want to
| be the standard bearer for the power of scripting and web
| standards [1]. If that's the case, then they are causing more
| harm than good by focusing exclusively on TypeScript, which isn't
| a language as much as a set of macros on top of JS. TS should
| remain a niche for those projects that can benefit from type
| safety, not promoted as some sort of better alternative to
| JavaScript, because it's really not.
|
| 1. https://deno.com/blog/v1
| gmac wrote:
| It's essentially a subjective question, but FWIW I disagree.
| I've written quite a bit of JS and quite a bit of TS, and I
| find TS so much better. I'm more productive, generate fewer
| bugs, and have more fun when writing it.
| crate_barre wrote:
| Some part of me wonders if they wrote some clear optimizations
| for defined types that translate easily to Rust. I could give
| two shits about types honestly, but I'm also one of those
| weirdos that keeps function arity low, and object definitions
| concise.
|
| How did people write semi elegant Ruby or python all these
| years, why wasn't there such a massive push for types in those
| languages? Most likely because backend people chose the backend
| language of their choice, but on the frontend they detested
| JavaScript (you have no choice, you must JavaScript you anti
| authoritarian shit heads) so much they had to drown it with
| some kind of ketchup to make it edible (Typescript).
| triyambakam wrote:
| After using typed backend languages like Rust and even Go
| (which is painful in its own right, in my perspective) I
| would hate to work again on a big Ruby or Python codebase.
| They feel just as disgusting, to use your metaphor, as using
| plain Javascript instead of Typescript.
|
| > why wasn't there such a massive push for types in those
| languages
|
| Are you just choosing to ignore all of the history of type
| checking Python and Ruby?
| crate_barre wrote:
| Look, this is going to back and forth. Take a time machine
| to pre Web 2.0 and explain to everyone why OOP programming
| sucks. I'd dare you to take it off your resume. But we're
| here now right?
|
| It's not hard for me to imagine the reversal of this trend
| inevitably where everyone goes 'the fuck are we writing all
| these verbose types for this dumb web app for?'.
| dahauns wrote:
| You're a bit late to the party...Web 2.0 _was_ this
| phase.
| triyambakam wrote:
| I really don't see what the back and forth is. Types are
| not inherently a fad - but there can be people who
| promote them with fanaticism as a cure-all or for
| problems they can't solve. There were people skeptical
| and critical of OOP when it was popular. I don't believe
| that OOP is inherently a fad either - it has its place.
| Different paradigms just get caught in the windstorm of
| fad interest.
|
| > [why] are we writing all these verbose types for this
| dumb web app for?
|
| You can take anything to the extreme, but types are a
| zero risk, low effort investment that has a quick return.
| If someone over-types something it's hardly a problem
| compared to an over engineered OOP codebase.
| jokethrowaway wrote:
| The problem with OOP is that there is not a single
| definition.
|
| There are a bunch of people claiming this and that are
| OOP. To me OOP is encapsulating a mutable state inside a
| dynamic namespace (an object, an instance of class), with
| functions that can access the state and the ability to
| inherit / extend namespaces.
|
| And I absolutely don't need it, I don't agree with the
| view some things are better done with OOP. Even gaming or
| GUI programming, domains typically considered to be the
| best for OOP, turned to ECS (which is very functional)
| and Elm style APIs.
|
| Going back at OOP: I consider mutable state to be a
| necessary evil to be limited as much as possible;
| inheritance makes it hard to track what code is being
| run.
|
| The best practice for writing OOP revolves around
| limiting mutable state and inheritance, so why even
| bother with OOP in the first place?
|
| I can have encapsulation with namespaces / modules in
| functional languages as well. I don't need much else and
| I can live happily without `this` and using composition
| instead of inheritance.
|
| OOP was the first marketing wave focused at developers
| and it's gone.
| crate_barre wrote:
| I guess thats my main deal breaker. It's simply another
| foot gun to allow people to over abstract. I have no
| issues with modest typing, it's nice, it's clear. I have
| issues with what entropy inevitably does.
| triyambakam wrote:
| So why are we in disagreement then? I am not advocating
| fanaticism, you simply seem to have implied and inferred
| that.
| jokethrowaway wrote:
| The idea of TS is not bad, but they had to forbid any and other
| ways to escape the type system. I get tons of runtime errors on
| my TS projects as well because someone down the chain decided
| they couldn't be bothered with types.
|
| Also, having to do type definitions for modules which don't
| have types is a massive pain. Overall, I appreciate the type
| safety, but I don't think TS delivers on that promise and I'd
| rather use a real typed language.
| triyambakam wrote:
| > not promoted as some sort of better alternative to
| JavaScript, because it's really not.
|
| This leaves me skeptical if you have extensive experience with
| Typescript. It's way more than "oh this is a number not a
| string." It's "you forgot this property on an object's return
| type that you built from a response value" or "your Redux
| reducer doesn't handle all of the possible action types so it
| will crash at run time"
| crate_barre wrote:
| _" your Redux reducer doesn't handle all of the possible
| action types so it will crash at run time"_
|
| And what are all these dr. Strange multiverse possibilities
| you speak of? Any semi seasoned JS dev has spidey sense for
| watching out for null and undefined, and generally you should
| know the type of what you are returning. Is there that much
| variability in what you are dealing with? If it's an array of
| objects, that's not hard to hold in your brain, just watch
| out for empty arrays or null/undefined items.
| triyambakam wrote:
| > Is there that much variability in what you are dealing
| with?
|
| Yes.
|
| I don't mean any disrespect but again it sounds like you
| really haven't _tried_ Typescript.
|
| Spidey sense can, often and will fail.
| russellbeattie wrote:
| _Deno attempts to provide a standalone tool for quickly
| scripting complex functionality._
|
| That's from Deno's home page. What I'm talking about isn't
| whether TypeScript is useful for some projects, as that has
| been proven beyond question. What I'm saying is that as a
| tool for "quickly scripting", as claimed by Deno, it is
| unnecessary and counter productive to JavaScript as a whole.
|
| My point is that the Deno project is a high profile
| JavaScript engine which, in my opinion, is misguided in their
| end-user focus on TypeScript and I think it's a shame.
|
| Devs are always searching for the "right" way to do things,
| and can be easily convinced to do things like misuse "const"
| because some pedantic fool convinced them it was sorta like
| type safety, and therefore not using it was "baaaaaaad". And
| the sheep followed and now const is used everywhere, despite
| the clear and unambiguous intended functionality of the
| feature's designers, who added it as a way of tracking,
| incredibly, constants and nothing else.
|
| It would be nice if we saved a generation of devs another
| debacle like const, NoSQL databases and UML.
___________________________________________________________________
(page generated 2022-03-16 23:00 UTC)