According to the Kickstarter:

"From the very inception, we had a vision to fix a lot of the issues with hardware, starting by getting Mono (the open-source runtime that powers Xamarin) running on a microcontroller in order to bring a modern runtime to the class of computing that powers real IoT."

Which would seem to indicate it runs Mono.

I'm going to argue that, while the .NET environment may be unfamiliar, it's as good (if not better!) than the NodeJS environment for "getting stuff done." You may have fewer libraries (depending on what you're looking for), but with .NET Standard 2, you need fewer of them. The standard library has support for everything from Memory Mapped Files [0], to Parallel loops [1], every collection type under the sun [2], globalisation [3], and HTTP applications [4].

Memory management is just as automatic as well (they seem to just be using the mono runtime).

[0]: https://docs.microsoft.com/en-us/dotnet/api/system.io.memory...

[1]: https://docs.microsoft.com/en-us/dotnet/api/system.threading...

[2]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...

[3]: https://docs.microsoft.com/en-us/dotnet/api/system.globaliza...

[4]: https://docs.microsoft.com/en-us/dotnet/api/system.net.http?...

The development tools are wonderful. The debugger in Microsoft Visual Studio Community Edition (free) is better than anything else out there.

And bringing it back to small embedded systems, there are some really nice plugins for VS that let you stay in that familiar environment. I am so much more productive with Visual Studio and the VisualMicro and Visual GDB plugins than I would be in the respective "native" IDEs.

> every collection type under the sun [2]

Except heaps / priority queues, which always irked me because it's in the Java standard library :-(

> But if Latin-style scripts are so much easier to input into computers, and if computers are not just the wave of the future but the present as well

But the hard part isn't supporting _a_ script, it's supporting _all_ scripts (or at least, all relevant scripts, in our modern interconnected age). It's only moderately more complicated, even with existing latin-centric tools, to only support a single script. Heck, If you only support Chinese + Japanese for example: you can always assume monospacing, which makes layout a breeze; line-wrapping rules are extremely simple [0]; and word-breaking (and associated headaches, like hyphenation and inter-word spacing) is practically a non-factor.

[0]: https://en.wikipedia.org/wiki/Line_breaking_rules_in_East_As...

I can speak a little on Chinese and Japanese. In neither of these countries, English (or sometimes even Latin) literacy is high enough to replace the domestic language. (And anyway, maybe it's just me, but reading romanized Chinese or Japanese is exhausting.)

With China, the market's so big that there's an entire ecosystem of homegrown (or Chinese-modified) software and websites, everything from office suites to web browsers, and I have to imagine those support Chinese input just fine.

With Japanese, generally the same software and sites are used, but Japanese support is also pretty good across common software.

Some niche or open source software struggle with IMEs in general, but in those cases, the solution is just to not use that software.

UWP is hardly consistent. Just as a quick example, the context menu in the start menu is slightly different from the context menu for the task bar, which are both very different from the context menu(s!) which appear in the Windows Mail app. Or how the context menu in the start menu can exit the bounds of the start menu, but most popups/menus in UWP apps are fully bound to their parents.

> Is this not what is being withdrawn?

What's being withdrawn is their original CUI, linked in the article [0]. From what I can tell, this is very distinct from their new digital service manual, which seems to be replacing the old CUI.

> ...but this would need to be either extended or abstracted to be applicable to, say, administrative systems.

Based on nothing more than a rough skim of the CUI, admittedly, it seems like the original was a very web/interface-oriented design system in the first place. A focus on web components makes sense, since administrative systems can be implemented with a web-based frontend, and web design systems can be adapted to other user interfaces, because they provide a set of baseline, expected behaviours to replicate.

[0]: https://webarchive.nationalarchives.gov.uk/20160921140920/ht...

Interestingly enough, from my quick tests, the highlighting behaviour works as normal in Firefox, but not in Chrome.

Here's a CSS-only hacky version I threw together:

  #hnmain td td:last-child .pagetop {
    font-size: 0;
  }
  #hnmain td td:last-child .pagetop a {
    font-size: 10pt;
  }
  #hnmain td td:last-child .pagetop a:first-child::after {
    content: ' | ';
  }

And for anyone who isn't familiar with (what I would consider) the most important difference in this use-case: borders affect the positioning of other elements, whereas outlines do not. You don't want to be using a temporary border, since it can significantly affect the layout of your site when you remove it.

* { box-sizing: border-box; }

I have never wanted anything other than this behaviour, so I pretty much always include it when starting on a fresh project.

Borders still affect the positioning of things even with box-sizing set to border-box. For example, here "Block 1" is still two pixels taller than "Block 2":

<div style="padding: 8px; border: 1px solid black"> Block 1 </div>

<div style="padding: 8px;"> Block 2 </div>

https://jsfiddle.net/t4rkvfzx/

Does that really matter though? A difference of 2px for something temporary doesn't seem like much concern. While I understand the implication is that these can accumulate and cause larger layout issues, the purpose of this practice is to highlight those areas to remove that accumulation anyway

The bigger issue is that you don't know if a UI inconsistency is a bug or a side-effect.

For this case of debugging, though, borders might actually be preferable because outlines would overlap, potentially obscuring the DOM depth

When I'm coding DIV layouts by hand, I temporarily assign each DIV with a random background-color. Once I have the layout and responsiveness required, I strip the background-color setting on each DIV as I fill them up with content. Works for me.

Yep, that is exactly why I do this! Great explanation.

From my understand, Japan pretty much only recycles anything that doesn't burn, which doesn't include the vast majority of the excessive amount of plastic packaging and plastic bags the country throws at you.