Speeding up the JavaScript ecosystem – one library at a time

Re:Speeding up the JavaScript ecosystem – one library at a time by 9dev on Tuesday November 29, 2022 @05:16PM (#33794159)

I share your opinion, but recently got very disappointed to find out that safari still needs lots of -webkit- prefixes; even for stuff seemingly available for ages now. So we’re not fully out of the pit yet, at least until the most valuable company in the world finally cares to fix their fucking browser (yes, dear Apple engineer, I’m talking to you!)

[ Parent | on HN ]

Re:Speeding up the JavaScript ecosystem – one library at a time by _hyn3 on Tuesday November 29, 2022 @05:30PM (#33794298)

Apple's app monopoly gets stronger when the browser gets weaker.

[ Parent | on HN ]

Re:Speeding up the JavaScript ecosystem – one library at a time by CharlesW on Tuesday November 29, 2022 @05:47PM (#33794471)

> recently got very disappointed to find out that safari still needs lots of -webkit- prefixes; even for stuff seemingly available for ages now.

Safari is fairly conservative in de-prefixing new features, but also sometimes beats Firefox (e.g. Container Queries and Container Query Units).

For reference, here's the caniuse.com list of Safari CSS features which need prefixing, compared to Firefox: https://caniuse.com/?compare=safari+16.1,firefox+107,ios_saf...

[ Parent | on HN ]

Re:Speeding up the JavaScript ecosystem – one library at a time by easrng on Tuesday November 29, 2022 @08:08PM (#33795619)

It feels kinda weird but a lot of the time you can just use the -webkit- prefixed versions and they'll work in firefox too.

[ Parent | on HN ]

Re:Speeding up the JavaScript ecosystem – one library at a time by zerocrates on Tuesday November 29, 2022 @08:59PM (#33795991)

Firefox added support for -webkit prefixes several years ago now... I think mostly to capture things written for mobile Safari but also Chrome I imagine.

I don't know if anybody really does other directions of that, though. There was probably no percentage in working with -moz prefixes for other browsers by the time this became an idea to do.

[ Parent | on HN ]

Re:Speeding up the JavaScript ecosystem – one library at a time by hajile on Tuesday November 29, 2022 @10:54PM (#33796851)

It's like user agent strings. Developers didn't fix their user agents, so other browsers just lied about what they were so the website would run properly. Only now they were stuck with the lie as long as devs depended on the user agent string for stuff leading to abominations like this one from Chrome on Android where it basically claims to be every single browser out there.

Mozilla/5.0 (Linux; Android 12; Pixel 6 Build/SD1A.210817.023; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/94.0.4606.71 Mobile Safari/537.36

Devs were NOT supposed to use prefixes in production, but they did anyway (best viewed in Chrome). Unfortunately they then proceeded to NEVER UPDATE these as other browsers added support. Non-webkit browsers had the choice of interpreting the CSS or leaving their users with a broken experience.

Major browsers moved away from vendor prefixes between 2012 and 2016 (when webkit finally stopped), but it was too late. Browsers 50 years from now will still be supporting this garbage because of what devs did.

The key takeaway: Never give devs a tool you don't want to be stuck with forever. Also, can we please not do this yet again in the future?

[ Parent | on HN ]

Re:Speeding up the JavaScript ecosystem – one library at a time by kibibu on Wednesday November 30, 2022 @01:14AM (#33797566)

> Never give devs a tool you don't want to be stuck with forever.

That's right. You can pry the <layer> element out of my cold, dead, hands.

[ Parent | on HN ]

Re:Speeding up the JavaScript ecosystem – one library at a time by robertoandred on Tuesday November 29, 2022 @08:51PM (#33795929)

Prefixes for what?

[ Parent | on HN ]

Re:Speeding up the JavaScript ecosystem – one library at a time by piskerpan on Wednesday November 30, 2022 @06:10AM (#33799213)

I don’t know what you’re using but most developers most likely don’t need “lots of -webkit- prefixes”.

In the link posted by the sibling commenter, I see 2-3 properties that could be useful to the general public. The rest is esoteric, never-ratified, or straight up user hostile (font-smooth)

[ Parent | on HN ]