If this were a commercial project then I could understand the complaint.. but this is just a small, for-fun project and they have little motivation to put the extra effort into support for all browsers.
Bellard (yes, him) already had a working VM of Windows 2000 in the browser around a decade ago, with no specific "support for all browsers" (whatever that means):
Also, look at 8086tiny, or PCulator/XTulator. These could be ported with ease to EMSCripten and run everywhere, not just in Chrome.
Chrome almost became the new IE and Google, despite it's motto, the new Microsoft. Ok, the desktop? Android rules the smartphone sales in the world, and its online services are used by millions, with far more metadata grabbing than w9x/wxp on its day and with the same propietary OSes.
Consider: maybe it's not a matter of non-standard APIs, but bad performance. It's not simply porting to the lowest common denominator, it's making sure the code doesn't run at a snail's pace because the JIT/wasm compiler has a pathological edge case.
I'm not really complaining; just harking back to a shitty time that is, on some commercial sites, threatening to return. Especially as Apple finally allows Chrome on iOS, eroding the main bastion against it: Safari.
The link isn't working, but anyone handing over unnecessary data to LinkedIn (AKA Facebook Pro) is probably too gullible to be online safely at this point.
The main idea is removing friction: you can open an SVG from your phone or computer and make quick edits without installing anything. That’s especially useful for small fixes, quick tweaks, or when you’re on a device where you don’t have your usual design tools.
It’s not meant to replace full desktop editors, but to make “edit this SVG right now” fast and accessible anywhere.
I started using it around 2018. After being reasonably conversant in Objective-C, I fully adopted Swift for a new iOS app and thought it was a big improvement.
But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes."
But then: "Have one source of truth." Um... you can't do that when every data structure is COPIED on every function call. So now what? I spent so much time dicking around trying to conform to Swift's contradictory "best practices" that developing became a joyless trudge with glacial progress. I finally realized that a lot of the sources I was reading didn't know WTF they were talking about and shitcanned their edicts.
A lot of the crap in Swift and SwiftUI remind me of object orientation, and how experienced programmers arrived at a distilled version of it that kept the useful parts and rejected dumb or utterly impractical ideas that were preached in the early days.
I think Swift was developed to keep a number of constituencies happy.
You can do classic OOP, FP, Protocol-Oriented Programming, etc., or mix them all (like I do).
A lot of purists get salty that it doesn’t force implementation of their choice, but I’m actually fine with it. I tend to have a “chimeric” approach, so it suits me.
Been using it since 2014 (the day it was announced). I enjoy it.
No Swift was developed as a strategic moat around Apple's devices. They cannot be dependent on any other party for the main language that runs on their hardware. Controlling your own destiny full stack means having your own language.
Apple already had that "strategic moat" with Objective-C. It was already a language you could effectively only use on Apple platforms (the runtime and the standard library only run on Darwin) and for which Apple controlled the compiler (they have their own fork of Clang).
I suspect that it was developed, in order to make native development more accessible. SwiftUI is also doing that.
They want native, partly as a “moat,” but also as a driver for hardware and services sales. They don’t want folks shrugging and saying “It doesn’t matter what you buy; they’re all the same.”
I hear exactly that, with regard to many hybrid apps.
There are plenty of valid reasons to use classes in Swift. For example if you want to have shared state you will need to use a class so that each client has the same reference instead of a copy.
> But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes."
This is the same way that C# works and C and C++ why is this a surprise?
Nowhere does it say structs provide “one source of truth”. It says the opposite actually- that classes are to be used when unique instances are required. All classes have a unique ID, which is simply it’s virtual memory address. Structs by contrast get memcpy’d left and right and have no uniqueness.
You can also look at the source code for the language if any it’s confusing. It’s very readable.
Have one source of truth is a universal guideline.
Prefer structs over classes is a universal, if weak, guideline.
It's funny how people can be all hung up on composability of things like type systems, and then completely blow off the desire for composability of guidelines.
no, the word "fabricated" means a deliberate action which could quite possibly have negative connotations for the fabricator, "hallucinated" is something more, its fabrication laundered through an llm.
I don't know where this guy has worked, but I've never worked for anyone who communicates like an ignorant, lazy ass.
Also, while I find his criticism valid for having had indeed seen it, this is ironic: "how sloppy and unprofessional emails from executives looked like."
The lifeswork of a thousand and one engineers all for the end consumer to not appreciate a difference watching netflix between this and a 1080p backlit panel on a couch with astigmatism.
When I was young, I had excellent eyesight and crappy CRTs. Might even have been 20/15. Could even read the microprint added to currency.
Now we have amazing displays but not as striking now even if the glasses correct minor astigmatism well.
Doesn’t seem like an enormous difference between modern TVs and LED backlit panels almost 20 years ago. (Yes, newer displays are a bit brighter, but nothing like the CRT to LCD transition then)
Recently got a nice 4k 27" OLED, and it's been a considerable upgrade over the regular backlit 27" LCD I had before.
When I got my first LCD, it looked a bit better for reading and such, but had worse motion clarity than my CRT for games, so I'd say this OLED upgrade was comparable.
reply