You are mixed up 3 different tech stacks:
1. React Native has nothing in common with web apps except JS runtime. It uses "native" widgets for Android and iOS. You need to add a new "native" runtime for your free OS. There are some third-party attempts to add mac/win/linux support, but they are not feature complete as officially supported platforms. Again, your free OS will be step behind.
2. Yes, you can write PWA with React (Web), but PWA still have many missing features which offered by platform APIs of Android and iOS. Your app will not be in "feature parity" with "native" app. Especially banking app.
3. Electron apps are integrated with desktop platform APIs, you cannot easily port Electron app to mobile.
Every time big company with big investments wins.
Does anyone have a recommendation for a good "Remote Attestation 101" tutorial? I'm trying to wrap my head around why someone couldn't just run an Android emulator to run your banking app or whatever. I mean there then must be hardware keys that are not present in the code, but then there must be a revocation method for compromised hardware keys, etc..
I have a react native app, and can compile it to pwa mode. It runs well in a browser.
99% of the code runs fine in electron to. Index.tsx is the main exception.
I’m not saying you can automatically run software for one of these targets across all three. I’m saying it’s straightforward to write portable software that works on all of them.
Also, I can’t think of any apps I use that require any platform-specific APIs at this point. Even if they did, the phone I want would be able to surface those APIs to pwas.
> the network applet gives lots of information that in other operational systems are either not available or difficult to access.
This macOS functionality goes to the "difficult to access" part. The only reason I know that this feature exist (but again, I never remember which key to press) is because I actually had issues with my last MacBook and Wi-Fi and had to search how to get this information.
But if you feel better, sure, I was "lying" for internet cookie points ¯\_(ツ)_/¯.
This is my personal blog and I can be as unbiased as I want, but saying that I am "proud of Linux" would be misguided at best. I could write one long blog post about all the issues I have using Linux desktop, but I can also write one for Windows and macOS, and from my personal perspective the issues I get in Windows and macOS are worse.
Fun fact, the OS that I am mostly experiencing hard crashes right now (at the point that my only option is to force turn off the system) is macOS, by far. I even know of one particular bug that always freeze the macOS UI (it is not a hard crash since everything still seems to work fine, it is just that I can't do any kind of input), and this is persistent across multiple macOS revisions. I dread now about that notification popup that trigger this bug because it is infuriating.
These two things have nothing to do with each other though:
- HTML doesn't have XML-style empty elements such as in "<div/>" and simply ignores the slash, treating the construct as start-element tag
- HTML is "hardcoded" in that the vocabulary understood by the browser is determined out of band, whether for empty ("void") elements or not. An SGML DTD (like the W3C HTML 4.01 DTD or newer DTDs for HTML 5+, which would be the means to inform a parser about the parsing rules for a markup language dynamically), actually contains declarations for the meta, img, and other elements as having EMPTY content, along with tag inference and attribute shortform rules also necessary for parsing.
It's mentioned in the GitHub readme, SuperHTML only supports HTML5 regardless of what you put in the doctype.
I will probably keep tracking the WHATWG living spec and never implement any other spec (old HTML versions, XHTML), so if you have a keen interest in anything other than contemporary HTML, SuperHTML might not be the right tool for the job.
That said, I'll add a warning if you put something else in the doctype so that users can know what to expect.
I got this error first with HTML doctype, so it is a problem in my code which uses self-closing tags with HTML doctype. Instead of very noninformative "html_elements_cant_self_close" message it should explain that HTML spec does not have "self-closing tags", and this code uses deprecated feature from previous (XHTML) specs.
You're getting a very clear error: your sample is not valid HTML, because, as the error informs you, HTML elements can't self close. Why would it reference some other document type for which this may or may not be valid syntax? Should it also tell you that these are not valid JSON objects or LISP forms?
Now, separately from that, it might be nice if it told you that it doesn't support DOCTYPE == XHTML and will treat the document as HTML anyway, but that should only appear as an error/warning on the DOCTYPE line, it shouldn't confusingly mention XHTML wherever you might have meant some XHTML-ism that is invalid HTML.
Also, XHTML is not "an older version of HTML", it is a completely different standard that is (or was) sometimes used instead of HTML.
"html_elements_cant_self_close" is not a very clear error.
Yes, now it is clear what does it mean, and it would be great if other users should not start a new HN-discussion to receive clear explanations when it can be explained directly on "html_elements_cant_self_close" tooltip. We can polish text, decide to mention XHTML or not, but the error message should be more informative.
> On void elements, it does not mark the start tag as self-closing but instead is unnecessary and has no effect of any kind. For such void elements, it should be used only with caution — especially since, if directly preceded by an unquoted attribute value, it becomes part of the attribute value rather than being discarded by the parser.
