7 ms·

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 in

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
        mrtesthah 5y ago
        >Shipping an entire regex engine with your app: right, that's the only way to do something like that. You mean like shipping an entire 100+ MB browser and rendering engine with your app?
        fabiospampinato 5y ago
        Electron does not weigh 300+ MB for starter, and one means basically statically linking your app so that it ships with its own dependencies and works more consistently, while the other means shipping a language because the one you have to use is not implemented properly by the platform, pretty different things when you look at them. I'll give you though that in both cases you are shipping a big engine with your app, so it kinda sounds like the same thing.
  - edflsafoiewq 5y ago
    What advancements do you have in mind?
    - fabiospampinato 5y ago
      A lot got released in the past 4/5 years. I don't have a list of favorites off the top of my mind. Many useful things got shipped though.
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.

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
        mrtesthah 5y ago
        >Shipping an entire regex engine with your app: right, that's the only way to do something like that. You mean like shipping an entire 100+ MB browser and rendering engine with your app?
        fabiospampinato 5y ago
        Electron does not weigh 300+ MB for starter, and one means basically statically linking your app so that it ships with its own dependencies and works more consistently, while the other means shipping a language because the one you have to use is not implemented properly by the platform, pretty different things when you look at them. I'll give you though that in both cases you are shipping a big engine with your app, so it kinda sounds like the same thing.
- edflsafoiewq 5y ago
  What advancements do you have in mind?
  - fabiospampinato 5y ago
    A lot got released in the past 4/5 years. I don't have a list of favorites off the top of my mind. Many useful things got shipped though.

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.