It’s what all the Patagonia-clads are raving about. They tell me it solves all perf problems in a snap.
Update
Here’s an NPM package. And, of course, Java if you’d like to deploy this in an Enterprise™ setting.
A fantastic introduction to Node (for maybe someone coming in from Python or Ruby land.)
The key takeaways in no particular order.
<noscript>. If you are using it, use it a lot more.I’m omitting CDN uptime (can’t do anything about this) and Browser compatibility (supporting 5+ year-old browsers is not something I care about doing given the work I do.)
Finally, not every fucking thing needs to be an App. For instance, your Terms of Service page can actually be a document on the Internet 😱
And not just the ones you install. I know of situations where a Chrome plugin was mandated by Corporate IT security (not my current employer.) ↩︎
From over 10 years ago (I’m sorting through my old bookmarks). A single object looks like this:
{
"ACCTOUNT_NUMBER":"1234567890",
"CUSTOMER_NAME":"ACME Products and Services, Inc.",
"ADDRESS":"123 Main Street",
"CITY":"Albuquerque",
"STATE":"NM",
"ZIP":"87101-1234"
}
He tested the usability of a given browser while it loaded between 1 and 1,000,000 such records.
From this test, I am considering the sweet spot to be around 10,000 records at (1.55MB). The maximum number of usable records I would push to a browser would be around 25,000 records (3.87MB). Keep in mind there are numerous factors to keep in mind when determining how many records you should return to your JavaScript application. The purpose of this test was to help identify a general maximum number for conversations around large record sets with JSON.
Would love to see an updated version of the tests.
A handy-dandy visual guide to the <script> tag, its various attributes, and how they relate to HTML parsing. Source unknown.
It’s very simple and clever. This is an example of what’s rendered from this giant Markdown file 💙
The argument here being that, since the ‘general form’ of the conjecture is undecidable, TypeScript’s type system is undecidable. How does one even think of doing these things?
I love Typescript, but it isn’t nearly ambitious enough. It would be vastly improved with an
--extremelyStrictflag enforcing that your Typescript code is free of side-effects; that is – no Javascript code is generated at all. Real programmers do all of their computation within the type system. Otherwise, they can’t be sure their program will work in production and should be duly fired.
Mad Lad. Via HN. (Cached)
Nexe and pkg are two compilers that create self-contained executables out of your Node scripts.
Deno introduced this in a recent release, which got me looking for Node-based alternatives.
This is a new personal record. Will go six months the next time 🎸
In programming, it is also common to refer to the “NIH syndrome” as the tendency towards reinventing the wheel (reimplementing something that is already available) based on the belief that in-house developments are inherently better suited, more secure, more controlled, quicker to develop, and incur lower overall cost (including maintenance cost) than using existing implementations. In-house developments are often collaborative with each other. When two in-house developments come together, it is informally known as “computer incest.”
Found when I was looking for a dependency-free XML-to-JSON parser wherein the author notes the “fine NIH tradition of JavaScript developers everywhere.” Reminded me of this
