thoughts^Σ=13

Codsen.com was previously on Eleventy, pure static HTML+CSS, served from the Edge via Cloudflare workers.

The problems with that setup were:

1. Flashing when navigating between pages
2. Components written in Nunjucks — not as universal as JSX
3. Absence of MDX
4. A poorer DX in general, stemming from Nunjucks itself — for example, compare the Nunjucks and TS linting
5. Cloudflare Workers can be fragile, the wrangler program which serves the sites is buggy
6. Being on edge, without a server, doesn’t mean you spend any less than using a server + CDN
7. Unable to share Nunjucks components in tester web apps driven by Vue

I’m sure most of that could be solved one way or another. But I just outgrew the 11ty baby shirt.

Our packages email-comb and html-crush had dedicated GUI websites and considerable amount of people have been using them. Over time, these two websites became hard to maintain; they were coded in vanilla JS without consistent components, tests and styling. Since they were created, a lot has changed; for example, Remix.js appeared and shook up everything. For example, the codsen.com theme toggle detects when a user switches the theme on the OS Preferences panel. There’s also no initial flash either. Those two old websites didn’t have this technology.

It took me a few weeks to recode them on codsen.com. Five minutes ago, I set up the redirects:

• https://emailcomb.com to 301-redirect to https://codsen.com/os/email-comb/play
• https://htmlcrush.com to 301-redirect to https://codsen.com/os/html-crush/play

Plus, I created a playground for string-strip-html; it didn’t have a domain before.

The next one is https://detergent.io — the final remaining dedicated library GUI website. I have a few ideas on further improving both the package and its GUI, so I kept them to the last.

2022-SEPT-11 update: detergent.io has been migrated to codsen.com playground.

It’s a day off today and I’m adding exports to all unexported-yet TS types and interfaces defined in every program, especially Opts and Res:

like that⤴, on every single program-package.

PS. I can’t stop thinking about deno and being able to run TS natively. How nice would it be to have the whole monorepo in deno, on rust tooling! Theoretically, we could get rid of: prettier, uvu, c8, esbuild, benchmark, turbo, and (shocker) eslint.

Few arguments in favour to BYOD company policies:

1. Passwords
2. Notes
3. Snippets
4. ZSH aliases
5. Time wasting syncing all above
6. Money wasting on two sets of licences

Besides pairing, I think the greatest practical learning comes from well-configured linting rules. For example, ESLint plugins for React hooks or RTL.

Since you’ll see a suggestion only if you make a mistake, it’s perfectly-relevant.

Codsen.com runs on Remix, the framework which won’t process anything CSS-related. To scale the styling task, some people use Tailwind; I use good old SASS on style-dictionary design tokens. SASS CLI watches the styles folder with .scss files from outside Remix and places the processed files inside the Remix project folder. From Remix’s point of view, CSS files just magically appear and update themselves.

Enter Autoprefixer. It doesn’t fit into this workflow! We either need to set up a proper JS-script pipeline (à la Gulp) or, two-level setup with an intermediary folder where Autoprefixer CLI’s watches the output of SASS directory (so two CLI’s watching), or some fancy terminal pipe contraption.

None of the options seem suitable.

The alternative is to run VSCode plugin manually, on .scss files.

I’m OK with that, this website needs to be simple.

Don’t know if you noticed but many extraordinary developers mastered their code editors to such level, that they started teaching productivity, editor plugins and, heck, in some cases, writing code editors.

The first two quick examples that pop to my mind:

• Wes Bos (online educator) has once published a Sublime Text Power User book
• Steve Francia (creator of Hugo the static site generator and many famous Golang libraries) has his Vim

It does not matter what code editor you use but it’s imperative to master all keyboard shortcuts and tricks of the one you picked.

As you know, JSDelivr broadcasts all npm content from its CDNs for free. You can access any file of any package’s version ever published to npm. For example, there are “ever-green” URLs:

https://cdn.jsdelivr.net/npm/detergent/dist/detergent.umd.js

and exact versions:

https://cdn.jsdelivr.net/npm/detergent@3.2.0/dist/detergent.umd.js

Besides this cdn. URL, there’s also a purge URL — replace cdn. with purge.:

https://purge.jsdelivr.net/npm/detergent/dist/detergent.umd.js

Calling that URL will trigger JSDelivr to purge the CDN assets and fetch the latest from npm. That’s handy with ever-green UMDs because they power GUI’s (like these), and it can take up to a day for CDN to fetch the latest.

“Our obsession with quality is renowned as every Jaeger‑LeCoultre watch undergoes strict “1,000 Hour Control” testing.”

—official websiteopens in a new tab

I wonder, what would be the Software Engineering field equivalent of that?

We’ve just published a new npm package, string-truncator. First and foremost, it’s for our own use. A picture is worth a thousand words; here’s our <aside>, before and after:

The string truncation is optimised to fit in as much letters as possible within “X line length across Y lines”.Check it out!

Interestingly, the scanerless-parser algorithm of string-strip-html is paying off. It strips JSX tags from MDX! I’m using it myself, on this website, to build the fuse.js search indexes.

Mr Toh posted a good article comparing various means to strip tags from HTML, including our npm package string-strip-html.

To add 2p.

It’s not just about speed.

The primary reason why you’d use an npm package, rather than regex, is whitespace management. The string-strip-html ensures the stripped results looks as if a human deleted the tags. Our program can even be used to generate email text versions, placing URLs besides the stripped link labels.

The second reason is string-strip-html can tackle broken HTML, dirty HTML and HTML mixed with other languages.

The third reason is string-strip-html saves you time: writing unit tests, writing correct type definitions (you’re using TypeScript, right?) and tackling edge cases.

The typescript-eslint ESLint plugin’s rule prefer-optional-chain is buggy on 5.35.1, it’s blocking me from bumping all deps in the monorepo. It took me around 4 hours to investigate, extract and raise https://github.com/typescript-eslint/typescript-eslint/issues/5556

People also raised similar issues regarding the latest prefer-optional-chain.

I hope maintainers will fix it soon.

Until it’s fixed, don’t bump it beyond 5.33.1.