Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

201–210 of 362 posts

Re: Google is killing the open web, part 2

#201
post #152

Earlier quoted context omitted.

JavaScript is backwards compatible. You can use an older standard supported by everything if you wish.

Really? Because I have an old iPad (4th gen?) that no longer works on many sites. If it was backwards compatible they'd still function.

You are talking about forward compatibility.

JS is backwards compatible: new engines support code using old features.

JS is not forward compatible: old engines don't support code using new features.

Regarding your iPad woes, the problem is not the engine but websites breaking compat with it.

The distinction matters as it means that once a website is published it will keep working. The only way to break an existing website is to publish a new version usually. The XSLT situation is note-worthy as it's an exception to this rule.

Re: Google is killing the open web, part 2

#202

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…

XSL is a Turing-complete functional programming language, not a declarative language. When you xsl:apply-template, you're calling a function. Functional programming languages can often feel declarative. When XSL is doing trivial, functional transformations, when you keep your hands off of xsl:for-each, XSL feels declarative, and doesn't feel that bad. The problem is: no clean API is perfectly shaped for UI, so you al…

Come on. With XSLT you write a rule and then write a fragment of the resulting document.

    
      
    
This is one of simplest ways to do things. With JavaScript you what? Call methods?

    CreateElement("def").setAttribute("def", "jkl")
There is a ton of "template engines" (all strictly worse than XSLT); why people keep writing them? Why people invented JSX with all the complicated machinery if plain JavaScript is better?

Re: Google is killing the open web, part 2

#203

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…

> 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…

Nobody learned web programming by putting XSLT on top of XML.

This is a fantasy world that does not exist.

People used PHP, or a tool which created HTML (DreamWeaver), or a website, or maybe a LLM today.

Re: Google is killing the open web, part 2

#204

Earlier quoted context omitted.

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.

It doesn't seem like much of a charge to be led. The decision appears to have been pretty unanimous.

Re: Google is killing the open web, part 2

#205

Earlier quoted context omitted.

Probably if Mozilla didn't push for it initially XSLT would stay around for another decade or longer. Their board syphons the little money that is left out of their "foundation + corporation" combo, and they keep cutting people from Firefox dev team every year. Of course they don't want to maintain pieces of web standards if it means extra million for their board members.

Mozilla's board are basically Google yes-people. I'm convinced Mozilla is purposefully engineered to be rudderless: C-suite draw down huge salaries, approve dumb, mission-orthgonal objectives, in order to keep Mozilla itself impotent in ever threatening Google. Mozilla is Google's antitrust litigation sponge. But it's also kept dumb and obedient. Google would never want Mozilla to actually be a threat. If Mozilla had…

So the idea is that some group has been perpetuating a decade or so's worth of ongoing conspiracy to ensure that Mozilla continues to exist but makes decisions that "keep Mozilla itself impotent"?

That seems to fail occam's razor pretty hard, given the competing hypotheses for each of their decisions include "Mozilla staff think they're doing a smart thing but they're wrong" and "Mozilla staff are doing a smart thing, it's just not what you would have done".

Re: Google is killing the open web, part 2

#206
post #54
post #44

Earlier quoted context omitted.

> Removing XSLT from browsers was long overdue > Google is willing to remove standards-compliant XML support as well. > They're the same picture. To spell it out, "if it's inconvenient, it goes", is something that the _owner_ does. The culture of the web was "the owners are those who run the web sites, the servants are the software that provides an entry point to the web (read or publish or both)". This kind of "well…

Can you cite where this "servant-oriented" mentality is from? I don't recall a part of the web where browser developers were viewed as not having agency about what code they ship in their software.

I’ve never heard of servant oriented, but I understand the point. Browsers process and render whatever the server returns. Whether they’re advertisements that download malware or a long rambling page on whatever I’m interested in now, browsers really don’t have much control over what they run.

Re: Google is killing the open web, part 2

#207
post #142

Earlier quoted context omitted.

Of course built-in support for RSS would be better. But what are the chances of that happening?

Probably better than browser makers committing to maintaining an xslt library.

They didn’t have to maintain it. There was a simpler solution and switch to a library that wasn’t broken.

Re: Google is killing the open web, part 2

#208

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…

> not at all approachable for someone who just wants to make a web page If someone wants to make a web page they need to learn HTML and CSS. Why would adding a fragile and little-used technology like XSLT help?

Because you do not want to create web pages, but to render some information in the form of web pages. And as you write that information you make distinctions unique to a) this information and b) your approach to it. And one of the best ways to do this is to come up with a custom set of XML tags. You write about chess? Fine: invent tags to decribe parties, positions and moves. Or maybe a tutorial on Esperanto? Fine; invent a notation to highlight the lexical structure and the grammar. You can be as detailed as you want and at the same time you can ignore anything you do not care about.

And then you want to merely render this semantically rich document into HTML. This is where XSLT comes in.

Re: Google is killing the open web, part 2

#209
post #151

Earlier quoted context omitted.

> Chromium commits are controlled by a pool of Google developers, so it's not open in the sense that anyone can contribute or steer the direction of the project. By these criteria no software is open source.

I would disagree, corporate open source involves corporate dominance over governance that fits internal priorities. It meets the legal definition rather than the cultural model which is community driven and often multi-stakeholder. I would put Debian, VLC, LibreOffice in the latter camp.

Is it often multi-stakeholder? Debian has bureaucracy and a set group of people with commit permissions. VLC likewise has the VideoLAN organization. LibreOffice has The Document Foundation.

It seems like most open source projects either have:

1. A singular developer, who controls what contributions are accepted and sets the direction of the project 2. An in-group / foundation / organization / etc that does the same.

Do you have an example of an open source project whose roadmap is community-driven, any more than Google or Mozilla accepts bug reports and feature reports and patches and then decides if they want to merge them?

Re: Google is killing the open web, part 2

#210
post #148
post #140

Earlier quoted context omitted.

The web wasn’t the browser it was the protocols.

That’s not an accurate statement. The web was not just the protocols. It was the protocols and the servers that served them and the browsers that supported them and the web sites that were built with them. There is no web without browsers just like there is no web without websites.

I can’t understand why you’re splitting hairs to this extent. The web is protocols; some are implemented at server side whereas others are implemented at browser side. They’re all still protocols with a big dollop of marketing.

That statement was accurate enough if you’re willing to read actively and provide people with the most minimal benefit of the doubt.

Post reply on HN