8 ms·

I guess but compatibility issues on the web, while they existe, are pretty discrete these days. Browser monoculture is exceedingly worse, both practically and f

I guess but compatibility issues on the web, while they existe, are pretty discrete these days. Browser monoculture is exceedingly worse, both practically and from a business perspective, in my opinion.

fabiospampinato 5y ago
I don't know about that, one data point: an ES2018 feature, regex lookarounds, is still not implemented in Safari. And the JS engine is the thing that's the most compatible across browsers, nowhere near the level of incompatibility of the rendering engine for example.
- nine_k 5y ago
  Ignore stuff that was added to HTML, CSS, and JS for last 4-5 years. You'll still have a pretty solid? GUI platform, likely more capable and accessible than Qt or GTK or AWT. 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.
  - fabiospampinato 5y ago
    Sorry but requiring web devs to ignore the last 4~5 years of progress is just unacceptable. Not that that would fix the situation, there are still rendering inconsistencies between browsers when using stuff like margins floats and tables.
    - nine_k 5y ago
      But you won't be developing a web app, you'd be developing a desktop app, much like with React Native. Having web developers learn C++ and Qt instead would be much more unacceptable.
      - fabiospampinato 5y ago
        By this logic requiring web devs to write ES3 code should be acceptable too. 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.
        shukantpal 5y ago
        Nope, you can compile code back to whatever ECMAScript version you like with tools like Babel or TypeScript. So the devs don’t even notice that they’re compiling to 4-5 year old ES.
        fabiospampinato 5y ago
        That's actually not true in general, tell me how to compile Proxy and regex lookarounds to ES5 or whatever version that doesn't support these features. In fact tell me how to polyfill these features in any way at all.
        projct 5y ago
        There's a proxy polyfill. And if you really wanted there's at least one pcre2 wasm build you could wrap to make a polyfill, lol. Barely anyone uses lookahead/lookbehind even in pcre, though.
        fabiospampinato 5y ago
        Proxy polyfill: assuming you are referring to this [0], since I haven't seen anything else like this, then I'll paste here what the readme says: > 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. [0]: https://github.com/GoogleChrome/proxy-polyfill https://github.com/GoogleChrome/proxy-polyfill
    - skinkestek 5y ago
      Then do as I: develop in Firefox and if it works there (and isn't a PWA where maybe you get in trouble with Safari?) then it works everywhere. 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 : )
      - fabiospampinato 5y ago
        Unless I'm missing something that doesn't fixes the issue, the problem is symmetrical, browser A is different than browser B, so browser B is different than browser A, testing in either of them doesn't guarantee a correct output in both of them.
        skinkestek 5y ago
        Chrome - like IE before it - has a number of "features" that only work/ed in Chrome/IE. 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.
        fabiospampinato 5y ago
        Testing on ~~Chrome~~ Firefox would save you from accidentally using Chrome-only features, but that's only part of the problem, caniuse.com kinda works better for that as you get data about other browsers too.
        skinkestek 5y ago
    - fsloth 5y ago
      "requiring web devs to ignore the last 4~5 years of progress is just unacceptable." 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.
    - peterangular 5y ago
      > Sorry but requiring web devs to ignore the last 4~5 years of progress is just unacceptable. 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.
    - deleted 5y ago
      [deleted]
    - hlbjhblbljib 5y ago
      The last 4-5 years of "progress" have been pretty unacceptable.
- kjleitz 5y ago
  Safari not supporting lookbehinds is a bigger PitA than I ever imagined it would be.
  - fabiospampinato 5y ago
    Right? And that's not the kind of feature that you can just polyfill back in. I don't understand how it's possible that that's not implemented yet.
- dmitryminkovsky 5y ago
  For language issues I assume using Babel, which in my opinion is not a big deal if you’re already making an 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).
- duped 5y ago
  Couldn't you just package your favorite regex library and expose it through a JS function binding in your app?
  - fabiospampinato 5y ago
    That's a big "just", but yes in theory that's doable, however: - 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.
wolframhempel 5y ago
As a guy who started web development when IE6 was the dominant platform I cannot cherish "browser monoculture" enough. .clearfix
- runarberg 5y ago
  And now we have display of "flow-root" instead of 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.
cpuguy83 5y ago
As someone who uses Safari on Mac, I can say that compatibility issues are a big deal. Granted many of the issues are simply from sites checking for Chrome and telling everything else to f--- off. I've even seen a site fail to run on (chromium) Edge because it really wanted Chrome. However, real compatibility issues are a thing as well. 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.
- stcredzero 5y ago
  Granted many of the issues are simply from sites checking for Chrome and telling everything else to f--- off. The world has circled back to the bad practices around IE 6! History doesn't repeat, but it sure does rhyme!
- jchw 5y ago
  To be fair, I hate Safari with a passion. It took until iOS 15 for support for WebAssembly.initiateStreaming and there’s still no support for WebM or Opus on iPhones. Curiously, on platforms where Apple doesn’t mandate a browser engine, Safari is magically able to support codecs that aren’t patent-encumbered…
  - tombofry 5y ago
    Just to clarify - WebKit does support Opus, but using their CAF container [1], which is a pain to deal as it requires double the space to store essentially the same encoded audio twice. [1]: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Audio_codecs#opus https://developer.mozilla.org/en-US/docs/Web/Media/Formats/A...
- hlbjhblbljib 5y ago
  Nobody tests on a Mac. If Apple wanted the platform to be supported they could make it much cheaper to test on, but instead they've made developer hostile moves for the last ten years.
kyriakos 5y ago
Safari is missing features and has its own quirks so I wouldn't say that.
baxuz 5y ago
It's much bigger than you think. 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.

fabiospampinato 5y ago

I don't know about that, one data point: an ES2018 feature, regex lookarounds, is still not implemented in Safari. And the JS engine is the thing that's the most compatible across browsers, nowhere near the level of incompatibility of the rendering engine for example.

nine_k 5y ago
Ignore stuff that was added to HTML, CSS, and JS for last 4-5 years. You'll still have a pretty solid? GUI platform, likely more capable and accessible than Qt or GTK or AWT. 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.
- fabiospampinato 5y ago
  Sorry but requiring web devs to ignore the last 4~5 years of progress is just unacceptable. Not that that would fix the situation, there are still rendering inconsistencies between browsers when using stuff like margins floats and tables.
  - nine_k 5y ago
    But you won't be developing a web app, you'd be developing a desktop app, much like with React Native. Having web developers learn C++ and Qt instead would be much more unacceptable.
    - fabiospampinato 5y ago
      By this logic requiring web devs to write ES3 code should be acceptable too. 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.
      - shukantpal 5y ago
        Nope, you can compile code back to whatever ECMAScript version you like with tools like Babel or TypeScript. So the devs don’t even notice that they’re compiling to 4-5 year old ES.
        fabiospampinato 5y ago
        That's actually not true in general, tell me how to compile Proxy and regex lookarounds to ES5 or whatever version that doesn't support these features. In fact tell me how to polyfill these features in any way at all.
        projct 5y ago
        There's a proxy polyfill. And if you really wanted there's at least one pcre2 wasm build you could wrap to make a polyfill, lol. Barely anyone uses lookahead/lookbehind even in pcre, though.
        fabiospampinato 5y ago
        Proxy polyfill: assuming you are referring to this [0], since I haven't seen anything else like this, then I'll paste here what the readme says: > 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. [0]: https://github.com/GoogleChrome/proxy-polyfill https://github.com/GoogleChrome/proxy-polyfill
  - skinkestek 5y ago
    Then do as I: develop in Firefox and if it works there (and isn't a PWA where maybe you get in trouble with Safari?) then it works everywhere. 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 : )
    - fabiospampinato 5y ago
      Unless I'm missing something that doesn't fixes the issue, the problem is symmetrical, browser A is different than browser B, so browser B is different than browser A, testing in either of them doesn't guarantee a correct output in both of them.
      - skinkestek 5y ago
        Chrome - like IE before it - has a number of "features" that only work/ed in Chrome/IE. 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.
        fabiospampinato 5y ago
        Testing on ~~Chrome~~ Firefox would save you from accidentally using Chrome-only features, but that's only part of the problem, caniuse.com kinda works better for that as you get data about other browsers too.
        skinkestek 5y ago
  - fsloth 5y ago
    "requiring web devs to ignore the last 4~5 years of progress is just unacceptable." 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.
  - peterangular 5y ago
    > Sorry but requiring web devs to ignore the last 4~5 years of progress is just unacceptable. 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.
  - deleted 5y ago
    [deleted]
  - hlbjhblbljib 5y ago
    The last 4-5 years of "progress" have been pretty unacceptable.
kjleitz 5y ago
Safari not supporting lookbehinds is a bigger PitA than I ever imagined it would be.
- fabiospampinato 5y ago
  Right? And that's not the kind of feature that you can just polyfill back in. I don't understand how it's possible that that's not implemented yet.
dmitryminkovsky 5y ago
For language issues I assume using Babel, which in my opinion is not a big deal if you’re already making an 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).
duped 5y ago
Couldn't you just package your favorite regex library and expose it through a JS function binding in your app?
- fabiospampinato 5y ago
  That's a big "just", but yes in theory that's doable, however: - 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.

wolframhempel 5y ago

As a guy who started web development when IE6 was the dominant platform I cannot cherish "browser monoculture" enough. .clearfix

runarberg 5y ago
And now we have display of "flow-root" instead of 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.

cpuguy83 5y ago

As someone who uses Safari on Mac, I can say that compatibility issues are a big deal. Granted many of the issues are simply from sites checking for Chrome and telling everything else to f--- off. I've even seen a site fail to run on (chromium) Edge because it really wanted Chrome. However, real compatibility issues are a thing as well. 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.

stcredzero 5y ago
Granted many of the issues are simply from sites checking for Chrome and telling everything else to f--- off. The world has circled back to the bad practices around IE 6! History doesn't repeat, but it sure does rhyme!
jchw 5y ago
To be fair, I hate Safari with a passion. It took until iOS 15 for support for WebAssembly.initiateStreaming and there’s still no support for WebM or Opus on iPhones. Curiously, on platforms where Apple doesn’t mandate a browser engine, Safari is magically able to support codecs that aren’t patent-encumbered…
- tombofry 5y ago
  Just to clarify - WebKit does support Opus, but using their CAF container [1], which is a pain to deal as it requires double the space to store essentially the same encoded audio twice. [1]: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Audio_codecs#opus https://developer.mozilla.org/en-US/docs/Web/Media/Formats/A...
hlbjhblbljib 5y ago
Nobody tests on a Mac. If Apple wanted the platform to be supported they could make it much cheaper to test on, but instead they've made developer hostile moves for the last ten years.

kyriakos 5y ago

Safari is missing features and has its own quirks so I wouldn't say that.

baxuz 5y ago

It's much bigger than you think. 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.