Hacker News Reader

Comment by rektide | Hacker News Reader

> Just when you thought there weren’t enough different kinds of workers, there’s a new type of worker...

SharedWorkers shipping Chrome 4 in January 2010[1]!! Firefox eventually shipped in 2014 (Firefox 29).

> ...in Safari

Haha yeah. Maybe re-do your marketing on this one.

It took Apple well over a decade to support a basic, essential function required for webapps to be able to have elementary cross-tab capabilities. Apple kept the web down on this one, super super hard. Absolutely brutal punching down. They mercilessly said they would not do it, that it was not going to happen. And that kept the whole web down. iOS said no. The titan has spoken.

[1] https://caniuse.com/sharedworkers

View on HN

> Safari 16 introduces a re-architecture of WebKit’s accessibility support on macOS that delivers improved performance and increased responsiveness

This is a magnitudes more important improvement and pushing the web forward than pretending that whateverworkers are a thing that is usable beyond very few convoluted examples (even if those examples end up running in production somewhere)

Webworkers are a pretty critical foundational component of a lot of apps these days. You can probably skate by without them on simple cases but they are up there with ES6+, fetch, virtual DOM, etc.

We had that functionality back in the 80s even, with anothe type of app, called a "native app". Those apps are not why the web was created, it's just using browsers as a poor man's cross platform sandboxed app delivery mechanism...

The web was created to serve users. Users benefit from rich web apps.

The web was created to share text documents with a few images here and there among the text.

That's it.

Sure, users benefit from rich apps. The web isn't a suitable platform for rich apps and will hardly ever be.

Native apps is not why the web was created by Berners-Lee and gang, but a certain segment of the web has been chasing the desktop-like experience since, on, 1990-something. The obsession with the desktop experience, and the associated inferiority complex, are pretty much part of the web DNA.

> The obsession with the desktop experience,

The "obsession" is with having a good common platform for development. Powered by some of the fastest rendering engines on the planet, some of the fastest language runtimes out there. With an unbelievably joyous continuous development brought about by fantastic live tools. For over a decade, with ongoing & continuous & highly visible improvement.

It's disgraceful what sad moaning & endless disdain people who like working here have to suffer, how berated we get for seeing potential & chasing it. Getting insulted & slandered is so common, this is so typical, so regular; endless dogpiles by the haters, and it's so cheap, such an expression of negativity & bias & cruelty.

I never enjoyed writing Win32 or .NET. I never enjoyed writing Qt. I never enjoyed writing FLTK nor GTK. These systems did not spark joy. The native platforms always felt crap, were so much ceremony & encumbrance, and so controlled & crufty & verbose to work with. On the web, I had a live canvas of hypertext, with rich information, ready to go, with a couple lines of HTML. And then I could sprinkle in programmability, add some JavaScript & start to move & shake things. This was an endlessly rewarding loop, was pure joy. The web is joyful. It keeps bringing better & better capabilities, more and more joy. People can go play with WebMIDI now, we can work with Gamepads, or magnenometers or accelerometers. This is fun, this is amazing. It works on all devices (some iOS exceptions may apply).

> the associated inferiority complex,

News-flash: the web won. It's creaming everything else. It's where jobs & development are done today, the default-go-to. It's just better. Webapps like VSCode run stupid fast & do everything better than native did, and because they're built on JS & the web they have sick sick sickeningly awesome plugins that were fast & easy to build.

It's a tragedy that there's so many grumpy hurt feeling abound, around this great & good rise, that such a wonderful fantastic capable & competent system has so many cranky sad mopey feelings. If there's anyone that feels an inferiority complex, it's definitely native people. They will not simmer down & chill the frak out with their endless bemoaning & whining & belittling of the web. The web is constantly endlessly dragged on, shat on, in thread after thread after thread, by people acting high & mighty & telling us, effectively, how dare we? I didn't give you permission to be awesome! My skills are the only ones that count! What you do isn't right!

So again,

> the desktop experience,

This is a relic, ancient dust to us. Our medium is networked by default, can be reached instantly via any device. We have rich servers providing powerful capabilities behind our thick-client user interfaces. Network architectures & information design underpin & shape our implementation decisions, are considered as we model & extend. The word API? It basically means "web interface" more than it means "native library interface" for most people now- because the web is awesome, because what we do is visible & engageable & more a part of the world & active than any lonely, isolated, compiled-down desktop app ever can be.

That we happen to also have buttons & click on things doesn't make us the same.

I will try to insult your platform a little less in the future. But please ya'll, you too need to show a modicum of respect. Having nothing but degrading insults for the web is small, it's out of touch, and the complaining is seemingly bottomless: here ya'll are, in a submission about the web, once again complaining that it's advancing.

> The "obsession" is with having a good common platform for development. Powered by some of the fastest rendering engines on the planet, some of the fastest language runtimes out there.

Nothing in this sentence applies to web browsers. The rendering in browsers is abysmally slow and extremely inefficient due to the way DOM is structured and rendered on-screen.

> Webapps like VSCode run stupid fast

Sure, if you're a trillion-dollar corporation with thousands of man-hours dedicated to a single app, then sure, you can have a decent app. However, the whole story of VS Code is the story of fighting against its browser origins. You could, for example, read up on how they tried to make the terminal in VS Code fast.

> This is a relic, ancient dust to us.

You do not have the right to talk for all of "us".

Could you execute those native apps using only a simple URL in a secure environment in under a second without any need for installation or cleanup?

There was a time when Apple supporters were huge fans of web apps. When Gmail and the like meant that it was possible to have a decent experience on a Mac as well, because software developers offered web apps. (Let’s not talk about that one year when Web Apps were the best thing since sliced bread before someone convinced Jobs that native apps on iOS is actually a good idea).

But now that it’s in Apple’s financial interests (not even its users’ interests) to push for native apps so Apple can collect their tax, the Apple supporters have seamlessly switched sides.

> the Apple supporters have seamlessly switched sides.

Good try at subtle insult, but it missed the mark.

Yes, the web had some promise many years ago. Now it's a monstrosity fuelled by Chrome non-standards that's one step away from collapsing under its own weight.

Cases in point: https://www.quirksmode.org/blog/archives/2021/08/breaking_th... and https://toot.cafe/@nolan/106715828929897555 and https://drewdevault.com/2020/03/18/Reckless-limitless-scope....

> were the best thing since sliced bread

sliced bread is disaster

I don't see apple pushing some sort of open standard for how to write native apps that is cross platform. Google has done some efforts (like flutter), but all of those seem to tie the library/runtime to it instead of trying to make it an open standard.

The web is the best standardized, cross platform, multi-runtime app platform we have.

When has accessibility pushed things forward? In my mind, accessibility is about parity with some existing standard, not about pushing the envelope forward.

Accessibility has made some sites and apps expose their data in more-easily understandable ways. In general if you need to make your interfaces accessible you will also make them easier to parse.

> [Accessibility performance improvements are] a magnitudes more important improvement and pushing the web forward than...

I don't think zero-sum adversarial X vs Y thinking is helpful. Both of these have value. As a developer, it sounds like accessibility already worked, and that the benefit to the accessibilities-using features is speed, which is good, but likely not groundbreaking. But I also would like some of the many features of the web to be unlocked by this slow-to-implement browser, and SharedWorkers is over a decade old & sits in an important & unique spot. Trying to play favorites isn't in my interest, but recognizing the values of each I think is informative.

> pretending that whateverworkers are a thing that is usable beyond very few convoluted examples

If you don't even know what the thing is you probably aren't qualified to judge. You don't seem to be interested in learning or informing; you seem to be trying to score points, & doing so by mockery & cruelty. I hope we can find better manners, more appropriate for good, learned, engaged Hackers, than this.

Someone correct me if I'm wrong but isn't it just entirely about competition with the app store? That they don't want to invest in features for apps on a platform "owned" by their largest competitor that then compete with apps on their own platform? On the app store Apple makes 15%, on the web they make zero and Google likely gets whatever ad revenue. I'm not defending Apple, Safari causes has caused me professional pain in the past, but it seems predictable.

It's a mystery! Who knows? But it's not a mystery.

There's definitely good people working to advance the web at Apple. That's clear. Apple's even hired up some. But there's still endless struggles, endless conflicts, huge huge parts of the map Apple insists are bad for users that they will not do. Like SharedWorkers, which until recently they insisted they would not do & were bad for users.

> Someone correct me if I'm wrong but isn't it just entirely about competition with the app store

At a previous WWDC they talked about service workers and how they have the potential to significantly impact the performance and battery life of devices if abused.

And so a lot of effort has been made trying to isolate and optimise them.

They did have it in Safari, and they took it out. There was a webkit bug open since 2015 asking them to put it back in, finally closed earlier this year.

> basic, essential function

Simply not true.

> a basic, essential function required for webapps to be able to have elementary cross-tab capabilities

Simply get out of here. Clipping my argument down to fit a contrite cheezy meanspirited vacuous soundbite rebuttal is gross & lacks respect. My statement is absolutely true. Go spread empty misleading hate somewhere else.

"Cross-tab capabilities" are not basic or essential either.

I think the answer is, it depends. It's been a pretty common-sense part of the web for a decade, powers a lot of experience, & allows developing much better user experiences in many cases. If you have an experience that needs to work across tabs, the alternatives are barbaric & crude & difficult, fault prone, & often waste network traffic.

As usual, the Apple fanboys show up to defend the prison they're locked into. By crudely rejecting basic longstanding technology. Typical. I'd like to see a little more high-road in some discussions, something beyond snide defensiveness.

And what kind of experience needs to work across tabs?

A spreadsheet. A chat app. A document editor. A map editor. Anything where information is on screen & needs to be live. Aka, what a huge part of the web today does.

Except all that information is on screen, shared live, via the web. A chat app talking to the next tab in the window isn’t worth much.

So what you do when your users have 20+ tabs open to the same service? Have each tab keep just itself up to date?

Is 20+ tabs of the same service, each needing the exact same data, a common scenario?

It depends. Sometimes, yes, users do have many different conversations going & tabs for different conversations.

Or they might be flipping between different sheets in the spreadsheet. And perhaps those sheets have cross relationships. Or perhaps the user changes which sheet they're looking at & has old data.

Whether or not it's common doesn't change that it's a concern that good developers strive to develop for, and it's something that ought be expected. Tabs are part of the web, are something that support user-agency, and it ought to be common that they are well supported. Now, we can start doing the job we ought to do.

The "exact same data" is often some change. Like user statuses in Slack. It's not terribly uncommon.

Opening a bunch of tabs is up to the user. I develop web apps for business users and often they open many tabs. But even me on reddit or hn I'll open a bunch of tabs to basically queue up reading.

This kind of flamewar comment will get you banned here. I don't want to ban you, so please stop posting like this.

More at https://news.ycombinator.com/item?id=31682131.

Reply on news.ycombinator.com