That said, I hate electron. I hate that I have to run 4-5 instances of chrome on my machine all day long for various different apps instead of the developer checking that their stuff works across the 3 main rendering engines.
Personally, I view Safari in 2022 the same way I viewed IE in 2012 - as a backwards browser holding back web development because the company developing it just doesn't care about the web. The compatibility issues aren't as bad, but I have to care about Safari because iOS still won't let any browser use anything other than WebKit, where there was a point where saying "Anyone choosing to use IE11 deserves a bad experience" made a certain amount of sense. No one gets a choice on their iPhone, so Apple makes things harder for web developers, probably because they want them all to be iOS app developers instead.
Safari development does seem to go through spurts, depending on who is working at Apple. Let's not forget that in the past, it's been a major driver of web innovation, particularly in the late 2000s to early 2010s.
[1]: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/A...
The world has circled back to the bad practices around IE 6! History doesn't repeat, but it sure does rhyme!
With the usual compiler / transpiler stack, you'll have a nice, fast-to-market, non-esoteric development environment. All without the need to ship 100MB binaries.
Not that that would fix the situation, there are still rendering inconsistencies between browsers when using stuff like margins floats and tables.
But this it not for "web devs", but for general UI development on desktops. Given some conventions there are decades old 4-5 years does not sound very ancient in comparison. And for desktop you probably want to trade bleeding edge hotness for tested and tried methods anyway. 4-5 years on desktop is a very brief span of time.
Less testing, less bugs. Whats not to like?
Contrast to Chrome first developers who often get caught by cross browsers incompatibilities just like they did back in the days when they were IE first developers : )
There are plenty of gotchas in layout/rendering as well, where either the standard is under specified, or Firefox has some small bugs. Maybe Chrome has many-chrome only APIs, but the developer will always need to test in Chrome and iOS Safari 13 (or whatever your oldest supported iOS version is).
Chrome and iOS are where the users are, and a good website or app should be usable and beautiful for everyone.
1/5, would not recommend. (But sometimes there's no way around it.)
Just wondering where you're getting "30 years" from?
That asked, a Chrome-shaped monoculture doesn't help anybody. We need more competing implementations, not less. Anyone feel like collaborating on such?
I'm not entirely sure how I feel about this statement (and comparison to IE). If anything, Safari is "the new IE" rather than Chrome.
MOST (hopefully the nitpickers pick up the caps lock) stuff in Chrome are drafts or standards.
Sure, Google pioneered/championed some of them, but that's kinda irrelevant if developers voted for those features. There's very little Chrome-specific stuff.
Also, other browsers have vendor specific stuff in them too, yet people rarely fling shit in their direction?
FWIW I also mostly use Firefox for dev because I prefer how some devtool features are designed/implemented.
Most of my cross browser issues in FF were "brief" in the senses that they were bugs that got fixed eventual.
Some people who either don't know history or willfully ignores it keeps claiming that Safari is the new IE, at one point one even made a webside out of it.
Don't fall for it.
Chrome is the new IE:
- technologically advanced? Check!
- implement a number of things without asking or waiting for consensus? Check!
- will be abandoned as soon as they have crushed every competitor? Well, it is produced by the worlds most famous company when it comes to killing its own software.
Next up, Microsoft is going to abandon Word. Also, Facebook is going to abandon Facebook. This is why no one takes these conversations seriously. All vitriol, no substance.
Sure, some piece of software will have that name, but it won’t be aggressively developed like MS abandoned IE a few times.
I also won’t be shocked if Word or Facebook are like Edge where it’s a new different thing with an old name.
I doubt google would spend much on chrome if no other browser were popular.
Fork Chromium.
Love, Your Old Users
Writing for a standards compliant browser like Firefox makes your code more well defined today just as it did back then because you won't get away with the same sloppyness. (This also makes you catch and fix problems in early iterations over the problem instead of after QA calls to complain so it saves you time and context switching too and if you are good you might look like a cross browser superhero almost for free ;-)
Earlier on not every basic thing was supported everywhere, many people here will remember the ACID tests. Younger devs won't remember them as we stopped talking about them after every browser became compliant. Today every mainstream browser has comprehensive test suites to cover everything we need from CSS I think.
How?
> caniuse.com kinda works better for that as you get data about other browsers too.
caniuse.com is nice but unlike using a standards compliant browser it requires you to be mentally alert and aware of it.
Using a standards compliant browser means you'll see the result of sloppy css immediately on the screen.
Sorry I meant "Firefox" and "Chrome-only" there.
In general though it's not like Firefox is spec compliant and others aren't, pretty much every browser works a little different in some areas. Just for the sake of saying something verifiable: no browser is spec compliant because the spec mandates a precise maximum length for strings and each main browser has a different, arbitrary (= I have the RAM, they just won't let me use it), lower limit on that.
No it's not. "Web dev" is one of the things in my toolbox and I still clicked on this well-knowing it was likely not truly cross-platform and keeping up with bleeding-edge features.
Truth is all development is about tradeoffs and Electron is one heck of a blob to ship to users... in a lot of applications a lighter weight artifact may be desirable where the trade off of the last 4-5 years of browser advancements may be perfectly OK.
Is it unacceptable? Sure - if your application needs features out of the last 4-5 years of browser advancements... but that's not most applications. If you need a bleeding-edge solution that's truly cross-platform then Electron clearly still is your choice as you're just shipping around a fancied up Chromium.
Having web developers learn C++ and Qt instead would be much more unacceptable.
The platform changed significantly, improved significantly, in the past few years, some of these major advancements can't be ignored just because a browser doesn't implement them.
> The polyfill supports just a limited number of proxy 'traps'. It also works by calling seal on the object passed to Proxy. This means that the properties you want to proxy must be known at creation time.
i.e. that's not a polyfill for Proxy. It's a polyfill for a subset of the thing, maybe that's useful for somebody, but it's useless for the use cases I had for Proxy so far.
Shipping an entire regex engine with your app: right, that's the only way to do something like that. Not that that's actually the same thing though, I can't just load this and use lookarounds as normal, i.e. it's not a polyfill.
For all practical purposes these features are not polyfillable. If your idea of a polyfill includes not actually polyfilling the entire thing or shipping an entire engine with your app then sure, anything is polyfillable, you could even run Java in the browser.
You mean like shipping an entire 100+ MB browser and rendering engine with your app?
Render-wise, browsers are pretty uniform these days. I experience very few problems in this regard, and my app Pony runs out of the same web codebase on all platforms (iOS, Android, web). The worst offender is Safari, but it’s not that bad. The potential gains from something like Tauri (and I plan to try Tauri for Pony desktop) far exceed the compatibility concerns for me (which I’ve already had to address due to web).
- The performance you are going to get will be terrible compared to the native implementation.
- Oniguruma, which I think is Ruby's engine, weighs half a megabyte on its own, that's comparable to the core bundle of the app I'm working on. That's a lot to my eyes.
- If you need to use this engine in dependencies that just assume that lookarounds are available then you are going to need to fork every single dependency just to wire it with the regex engine you compiled, super messy.
.clearfix
However the only reason I ever used the clearfix hack was when using float to do layout. I haven’t done that for ages (i.e. since CSS grew to include flexbox and grid). And I only ever use float to—well—float images inside text where the inside display is always inline. So I haven’t ever seen a need for display flow-root in the wild... Although I’m sure it exists.
If I'm building an electron app, it's because I need native code running in nodejs/V8 as native addons, often in the render process, or I'm using bleeding edge APIs not available on Safari.
This type of framework is simply not an option.