Aux

Hotel breakfasts tend to be more expensive than eating out.

Getting totally wasted in a forest on cheap beer mixed with antihistamines and vodka was the best thing as a teen!

That's what you get when you allow big tobacco to kill traditional vaping. Where were you when they were pushing bills to destroy the industry and take over it?

Well, the issue is that JSON is based on JS types, but other languages can interpret the values in different ways. For example, Rust can interpret a number as a 64 bit int, but JS will always interpret a number as a double. So you cannot rely on numbers to represent data correctly between systems you don't control or systems written in different languages.

Yaml is cancer.

What that means is that you cannot rely on numbers in JSON. Just use strings.

Well, apart from float numbers and booleans, all other types can only be represented by a string in JSON. Date with timezone? String. BigNumber/Decimal? String. Enum? String. Everything is a string in JSON, so why bother?

I know how React Native works and it doesn't fix anything. For example, if the underlying toolkit punishes you for deep nesting - you're still fucked. Google recommends to have 10 or less levels of nesting, which is bonkers to any web developer. There is similar advice for iOS, Mac and Windows (not sure about GTK and Qt, haven't used them for over a decade). Each platform has its own solution, so you end up with custom code for each and at that point or doesn't matter if you're coding in C or JS.

I vote for nanoid.

There are several issues with native development without a browser layer.

First of all, native UI toolkits are very different and making a robust cross platform app is pretty much impossible. So, the traditional approach is to use one toolkit, which will be native to one platform, and then let your other users deal with it. For example, GTK apps on Windows and Mac look and feel like shit.

Another approach is to use a custom cross platform toolkit, which doesn't use anything native at all. If enough work and thought is put in such application, it can be a very pleasant experience. But often it's shit for all users.

The second issue is that it can be quite hard to manage fluid window sizes and to build a proper responsive UI with native toolkits. Some are better at it, some are worse. Native toolkits also tend to punish developers for deep nesting of components making UI development even more painful.

HTML + CSS solves all that. It's responsive by design, everyone is used to web apps already, nesting is not a problem at all, etc.

Everyone should be poor, great!

I would also like to add some of the higher level features available in most assembly languages.

1. Memory management. You can define variables, for example, a string one containing "Hello, world!" and the compiler will correctly allocate required memory and you don't need to know its address while writing the code, you just reference the variable.
2. Code labels. If you want to do a conditional or unconditional jump, you need to know the address of the code you want to reach. But, obviously, every change you make to your code base will change the memory layout of your binary. Asembly provides code labels. You can think of them like function names.
3. Assembly allows you to reference 3rd party libraries without knowing exact function entry addresses. You just use function names like you would with C or any other language.

Modern assembly languages have even more higher level features, like macros support. And some are even hardware agnostic, like intermediate representation assembly language used in LLVM.