Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

161–170 of 362 posts

Re: Google is killing the open web, part 2

#161

Earlier quoted context omitted.

Also, the protocol is pretty much a holdover from the earliest days, before encryption, or complicated NATs. I remember using it with just telnet a few times. It's pretty cool, but absolutely nobody should be using FTP these days. I remember saying this back in the 2005, and here we are 20 years later, someone still lamenting dropping FTP support from a browser? I think we're decades overdue.

The problem wasn't that FTP got deprecated, but that we never got a proper successor. With FTP you could browse a directory tree like it was a real file system. With HTTP you can't, it has no concept of a directory. rsync is the closest thing to a real successor, but no Web browser support that either.

I agree that we should get a successor, but if it got deprecated way back, I think we would have more likely gotten one. For just downloads, I have used apache and nginx directory and file listing functionality with ease.

Re: Google is killing the open web, part 2

#162
post #98

Earlier quoted context omitted.

Could you run XSLT as part of your build process, and serve the generated HTML?

XML source + XSLT can be considerably more compact than the resulting transformation, saving on hosting and bandwidth.

The Internet saves a lot more on storage and bandwidth costs by not shipping an XSLT implementation with every browser than it does by allowing Joe's Blog to present XML as an index.

Re: Google is killing the open web, part 2

#163

I have yet to read an article complaining about XSLT deprecation from someone who can explain why they actually used it and why it’s important to them. > I will keep using XSLT, and in fact will look for new opportunities to rely on it. This is the closest I’ve seen, but it’s not an explanation of why it was important before the deprecation. It’s a declaration that they’re using it as an act of rebellion.

Making RSS/Atom feeds friendly to new users is key for its adoption, and for the open web. XSLT is the best way to do that. I made a website to promote doing using XSLT for RSS/Atom feeds. Look at the before/after screenshots: which one will scare off a non-techie user? https://www.rss.style/

RSS and Atom feeds are at this point a solution looking for a problem.

I use RSS all the time... To keep up-to-date on podcasts. But for keeping up to date on news, people use social media. RSS isn't the missing piece of the puzzle for changing that, an app on top of RSS is. And in the absence of Reader, nothing has shown up to fill that role that can compete with just trading gossip on Facebook.

Re: Google is killing the open web, part 2

#164
post #95

Earlier quoted context omitted.

Could you run XSLT as part of your build process, and serve the generated HTML?

No because then it would not be an Atom feed. Atom is a syndication format, the successor to RSS. I must provide users with a link to a valid Atom XML document, and I want them to see a web page when this link is clicked. This is why so many people find this objectionable. If you want to have a basic blog, you need some HTML docments and and RSS/Atom feed. The technologies required to do this are HTML for the documen…

>I must provide users with a link to a valid Atom XML document, and I want them to see a web page when this link is clicked.

Do RSS readers and browsers send the same Accept header?

Re: Google is killing the open web, part 2

#165

Earlier quoted context omitted.

> Google is now removing one of those technologies, which makes it essentially impossible to serve a truly static website. How so? You're just generating static pages. Generate ones that work.

You cannot generate a valid RRS/Atom document which also renders as HTML.

So put them on separate pages because they are separate protocols (HTML for the browser and XML for a feed reader), with a link on the HTML page to be copied and pasted into a feed reader.

It really feels like the developer has over-constrained the problem to work with browsers as they are right now in this context.

Re: Google is killing the open web, part 2

#166
post #127

This has nothing to do with the “open web”. I don’t know if the people saying this just don’t have a meaningful definition of what open means or what. “Open” doesn’t mean “supports everything anyone has ever shipped in a browser”. (Chrome should support Gopher, really? Gopher was literally never part of the World Wide Web.) What’s happening is that Google (along with Mozilla and Safari) are changing the html spec to…

> Google Reader deprecation probably hurt RSS more than anything else

And, indeed, if the protocol was one killer app deprecation and removal away from being obsolete, the problem was the use case, not the protocol.

(Personally, I don't think RSS is dead; it's very much alive in podcasting. What's dead is people consuming content from specific sites as a subscription model instead of getting most of their input slop-melanged in through their social media feeds; they don't care about the source of the info, they just want the info. I don't think that's something we fix with improved RSS support; it's a behavior issue looking for a better experience than Facebook, not for everyone to wake up one day and decide to install their own feed reader and stop browsing Facebook or Twitter or even Mastodon for links all day).

Re: Google is killing the open web, part 2

#167
post #119

Earlier quoted context omitted.

I guess you mean except Mozilla and Safari...which are the two other competing browser engines? It's not like a it's a room full of Chromium based browsers.

Safari yes Mozilla…are they actually competing? Like really and truly.

Mozilla has proven they can exist in a free market; really and truly, they do compete.

Safari is what I'm concerned about. Without Apple's monopoly control, Safari is guaranteed to be a dead engine. WebKit isn't well-enough supported on Linux and Windows to compete against Blink and Gecko, which suggests that Safari is the most expendable engine of the three.

Re: Google is killing the open web, part 2

#168

In part 1 of this article, the author wrote, "XSLT is an essential companion to RSS, as it allows the feed itself to be perused in the browser" Actually, you can make an RSS feed user-browsable by using JavaScript instead. You can even run XSLT in JavaScript, which is what Google's polyfill does. I've written thousands of lines of XSLT. JavaScript is better than XSLT in every way, which is why JavaScript has thrived…

> Actually, you can make an RSS feed user-browsable by using JavaScript instead

Say I have an XML document that uses XSLT, how do I modify it to apply your suggestion?

I've previously suggested the XML stylesheet tag should allow

    
which would then allow the script to use the service-worker APIs to intercept and transform the request.

But with the implementation available today, I see no way to provide a first-class XSLT-like experience with JS.

Re: Google is killing the open web, part 2

#169

Earlier quoted context omitted.

There's a lot of history behind WhatWG that revolves around XML. WhatWG is focused on maintaining specs that browsers intend to implement and maintain. When Chrome, Firefox, and Safari agree to remove XSLT that effectively decides for WhatWG's removal of the spec. I wouldn't put too much weight behind who originally proposed the removal. It's a pretty small world when it comes to web specifications, the discussions l…

The issue is you can’t say to put little weight who originally proposed the removal if the other poster is putting all the weight on Google, who didn’t even initially propose it

I wouldn't put weight on the initial proposer either way. As best I've been able to keep up with the topic, google has been the party leading the charge arguing for the removal. I thought they were also the first to announce their decision, though maybe my timing is off there.

Re: Google is killing the open web, part 2

#170

Earlier quoted context omitted.

> JavaScript is better than XSLT in every way Obviously not in every way. XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. It gives a very low-effort but fairly high power (especially considering its neglect) on-ramp to templated web pages with no build steps or special server software (e.g. PHP, Ruby) that you need to maintain. It's an extremely natu…

> XSLT is declarative and builds pretty naturally off of HTML for someone who doesn't know any programming languages. Have you ever met a single non-programmer who successfully picked up XSLT of their own volition and used it productively? I'd be willing to bet good money that the Venn diagram of users that fit the intersection of "authoring content for the web", "care about separating content from HTML", "comfortabl…

I did. Just because the herd says it's dead doesn't mean XSLT is dead or "bad"
Post reply on HN