Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

Post reply on HN
Print view View original

171–180 of 362 posts

Re: Google is killing the open web, part 2

#171

Post by meindnoch »

bigyabai wrote: post #167
Forgeties79 wrote: post #153

Earlier quoted context omitted.

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.

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

This gave me a superb belly laugh.

Re: Google is killing the open web, part 2

#172

Post by 6510 »

Aurornis wrote: post #16

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.

If you have a lot of xml data and need an UI that does complex operations that scream xpath it would be rather spectacular if it could be done without much of a back end, in the browser without js.

I'm not good enough with XSLT to know if it is worth creating the problem that fits the solution.

Re: Google is killing the open web, part 2

#173

Post by kuschku »

shadowgovt wrote: post #165
James_K wrote: post #134

Earlier quoted context omitted.

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.

> So put them on separate pages because they are separate protocols

Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response?

It's the same content, just supplied in a different format. It should be the same URL.

Re: Google is killing the open web, part 2

#174

Post by LtWorf »

dfabulich wrote: post #31

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…

No you can't, since opening an RSS feed won't run a javascript.

Re: Google is killing the open web, part 2

#176

Post by kuschku »

matthews3 wrote: post #88
James_K wrote: post #83

Earlier quoted context omitted.

I use XSLT because I want my website to work for users with JavaScript disabled and I want to present my Atom feed link as an HTML document on a statically hosted site without breaking standards compliance. Hope this helps.

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

I have arduinos with sensors providing their measurements as XML, with an external XSLT stylesheet to make them user-friendly. The arduinos have 2KB RAM and 16 MIPS.

Which build process are you talking about? Which XSLT library would you recommend for running on microcontrollers?

Re: Google is killing the open web, part 2

#177

Post by LtWorf »

gbalduzzi wrote: post #75
charcircuit wrote: post #64

>Mozilla bent over to Google's pressure to kill off RSS by removing the “Live Bookmarks” features from the browser They both were just responding to similar market demands because end users didn't want to use RSS. Users want to use social media instead. >This is a trillion-dollar ad company who has been actively destroying the open web for over a decade Google has both done more for and invested more into progressing…

I agree with everything, but just to be clear: > This is what web developers want I don't think it is what web developers want, it is what customers expect. Of course there are plenty of situation where the page is totally bloated and could be much leaner, but the overall trend to build web applications instead of web pages is dictated by user expectations and, as a consequence, requirements.

Users say "the page shall not load in less than 15 seconds and shall not use less than 5% of my monthly dataplan"?

Odd… are these people with us?

Re: Google is killing the open web, part 2

#178

Post by LtWorf »

zetanor wrote: post #162
bilog wrote: post #98

Earlier quoted context omitted.

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.

You redownload your browser every request‽

Re: Google is killing the open web, part 2

#179

Post by amarant »

pmontra wrote: post #154
amarant wrote: post #118

Earlier quoted context omitted.

It's just ill-informed ideological thinking. People see Google doing anything and automatically assume it's a bad thing and that it's only happening because Google are evil. HN has historically been relatively free of such dogma, but it seems times are changing, even here

Maybe free of the "evil Google" dogma but not free from dogma. The few who dared to express one tenth of the disapproval what we usually express about Apple nowadays were downvoted to transparent ink in a matter of minutes. Microsoft had its honeymoon period with HN after their pro open source campaign, WSL, VSCode etc. People who prudently remembered the Microsoft of the 90s and the 2000s did get their fair share of…

"relatively" is meant to be doing a lot of work in my previous comment. Allow me to clarify: Obviously some amount was always there, but it used to be so much less than it is now, and, more importantly, the difference between HN and other social media, such as Reddit, used to be bigger, in terms of amount of dogma.

HN still has less dogma than Reddit, but it's closer than it used to be in my estimation. Reddit is still getting more dogma each day, but HN is slowly catching up.

I don't know where to turn to for online discourse that is at least mostly free from dogma these days. This used to be it.

Re: Google is killing the open web, part 2

#180

Post by zzo38computer »

kuschku wrote: post #173
shadowgovt wrote: post #165

Earlier quoted context omitted.

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.

> So put them on separate pages because they are separate protocols Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response? It's the same content, just supplied in a different format. It should be the same URL.

There are separate URLs for "https:" vs "http:" although they are usually the same content when both are available (although I have seen some where it isn't the same), although the compression (and some other stuff) is decided by headers. However, it might make sense to include some of these things optionally within the URL (within the authority section and/or scheme section somehow), for compression, version of the internet, version of the protocol, certificate pinning, etc, in a way that these things are easily delimited so that a program that understands this convention can ignore them. However, that might make a mess.

I had also defined a "hashed:" scheme for specifying the hash of the file that is referenced by the URL, and this is a scheme that includes another URL. (The "jar:" scheme is another one that also includes other URL, and is used for referencing files within a ZIP archive.)

Post reply on HN