Hacker News new | ask | show | jobs
by thatsaguy 2809 days ago
RSS support in FF was always poor, but that was often enough to preview a subscription. It didn't need to be more complicated than that.

On the other hand, or hay, Firefox Screenshots!! Sooo useful. Pocket? It doesn't get more federated than that! Or the dozen of DOM APIs added every year, which are probably much more complicated to maintain than a simple RSS preview feature.

I really hate the general direction of how browsers are developed.

3 comments

I really hate the general direction of how browsers are developed.

I've hated it for a while, especially as browsers move more and more away from "browsing" and become more and more of a half-ass "universal application runtime" combined with "something kinda like an X-server but not really".

I kinda think we need to split browsers so they support two "modes": content mode, and application mode (or something like that) where the core functionality of the browser is rendering HTML content and, well, browsing. But a given page should be able to signal (through a meta tag or an HTTP header or something) "I'm an application" where it gets run as an application... which could still mean running in the browser as JS, or it could mean handing the thing off to a content handler to run the application outside of the browser. In my vision, the difference between "application mode" and "content mode" would be things like: in "application mode" all keybindings would pass through to the application, so you could - for example - use F1 for context sensitive help, instead of F1 triggering the browser's help menu. Also, app mode could allow things like altering the right-click context menu, while content mode might disable that. Etc. etc.

Prediction: 99% of sites would signal "I'm an application", including those that obviously are content sites. The only ones who wouldn't (personal blogs and the like) are already pretty usable, so they wouldn't gain much.
You may be right. And honestly, I haven't spent a ton of time yet thinking about all the ways "content mode" and "application mode" would differ. A couple of obvious ideas jump out, but there's probably more to be said about this.

It might also be that the right thing to do is have a fine-grained permission model where pages request specific capabilities from the browser, and the user can allow or deny, with the ability to revoke permissions if abused, or white-list sites in advance, etc.

The web is shit as it is because of the war on control over content presentation. Both users and publishers want to have 100% control over users' screen. The reason 99% of sites will declare they're applications because they just won't give up control.

(This is the core of the ad blocking issue, BTW.)

Of course I'm an user, I'd love the split between browser and app runtime, even just so that I could not launch the latter much, telling all the sites pretending to be applications to just go to hell.

Honestly the last time I wrote an app for a website it was specifically because browser incompatibilities had me tearing my hair out. Calling HTML/CSS/JS standards is fucking laughable.
Out of curiosity, when was that? Modern frontend has many issues (npm is at least a hundred of them) but browser compatibility is a solved problem for the majority of purposes.

HTML had been stable since forever, and browsers will render pretty much any old shit you throw at them without too much cajoling. SVG/canvas were the last things to be cleaned up iirc, but they're pretty usable now.

Most of the sharp edges on JS' DOM API implementations were smoothed off ages ago and if you want to use the newest features stuff like babel and typescript transpile es6 back to es5 with selection of polyfills. AFAIK safari still can't round opacity properly, but since that's usually a stylistic thing just use css.

Vendor prefixes in css have been less relevant for a fair while, were easy to use if you wanted to throw some @keyframes down, and are a non issue of you use an auto prefixer of some description.

The only problem browser is IE11, which had some admittedly wacky implementations and out-dates most of the modern frontend stack by several years.

There are still weirdnesses (Firefox's font rendering, literally everything Safari does, features being implemented and deprecated simultaneously) but nothing insurmountable.

Browsers already have a permission model - sites have to ask to access the webcam or microphone or location or show notifications.

But when 99% of sites are already using a feature, introducing a permission dialog would just be hell for users, since they'd have to click Allow hundreds of times a day.

Browsers already have a permission model - sites have to ask to access the webcam or microphone or location or show notifications.

True enough. And it does get tiring having to click "no" all the time on those notification dialogs.

But again, this is a very nascent idea. I've spent more time thinking about in the last 20 minutes than I had in aggregate before today. I'm not convinced that there isn't a way to make something like this work, but the details are a bit fuzzy. Of course it's also possible that it's just a dead-end from the start. But it sure feels like there needs to be some way to distinguish "apps" and "regular content" and the way browsers handle each.

I don't think it's a bad idea, my main objection is seeing it as a technical problem. It's not - making a more basic browser is a solved problem. What you really need to solve is the economics problem; specifically, the two-sided market of users and publishers. Users have an incentive to use it, but what incentive do website makers have to join?

Google - for good or ill - was able to push AMP because they have the power to reward the sites that complied. You need something similar.

I would love browsers to split document-mode (think static content) and application mode (think single-page web app).

When browsing documents, I don't want application cruft (I probably don't want JavaScript). I really don't want "application" features getting abused by adverts.

For our SPA we have needs that are not related to documents (restricting the viewport zoom, fixed toolbars at top and bottom, preferably hide browser URL and toolbars). Heaps of modern browser functionality such as WebWorkers and notifications is only really relevant to web apps.

I would love browsers to split document-mode (think static content) and application mode (think single-page web app).

Yeah, exactly. A given page should be able to request "application mode" and the user should be able to say "OK" or "NO", or just navigate away if they don't want an "application" doing stuff.

For our SPA we have needs that are not related to documents (restricting the viewport zoom, fixed toolbars at top and bottom, preferably hide browser URL and toolbars). Heaps of modern browser functionality such as WebWorkers and notifications is only really relevant to web apps.

Yep, yep. Glad I'm not the only one who agrees with this. I've been thinking about floating this idea for a while, but I kinda figured everybody would just say "that's stupid". :-)

That's not stupid. That's awesome, and probably the right thing to do.

Except it won't happen, because users and publishers have conflicting interests in this. I refer to it as war over control over presentation. This is why publishers say that ad-blocking is wrong (they assume it's their right to tell you exactly how you should consume content). This is why you get DRM. This is part of the reason why Flash used to be popular with companies. This is why RSS is not. I believe that if given a chance, most companies would gladly send you their webpages as opaque .exe files. We just got lucky that the Web, down to HTTP protocol itself, was initially designed to give users most of control.

I don't know of a solution. I know we can try to win battles, by building and proposing software that lets more people exercise more control over their browsers. Unfortunately, I feel that organizations responsible for the Web - the consortia and browser vendors - are all fighting on the side of publishers now. Browsers are starting to function less as User Agents, and more as remote terminals.

I don't know of a solution. I know we can try to win battles, by building and proposing software that lets more people exercise more control over their browsers. Unfortunately, I feel that organizations responsible for the Web - the consortia and browser vendors - are all fighting on the side of publishers now.

Yeah, that's a real problem for sure.

Browsers are starting to function less as User Agents, and more as remote terminals.

I know, I've been railing against this for probably 8 or 9 years now... with little to show for it, unfortunately. Probably for the reasons you just cited. sigh

I fear that the only thing we can do is to keep on designing user-respecting sites and tooling that lets users control the way they consume content, and just let the web fork. Leave the money-driven web for moneymakers and people satisfied with that state, and let a productive web develop on the side of it.
> I believe that if given a chance, most companies would gladly send you their webpages as opaque .exe files.

This is exactly why "mobile app" versions of webpages (facebook, reddit, you name it) are so prevalent. Of course it's also why I would never use them under any circumstance.

I like the way you put it, "war over control over presentation". It hits the nail on the head and it describes something that has been happening for a long, long time.

There's no solution as long as you are dealing with companies whose business is to sell information (the "publishers").

The only winning condition is to deal with people who are willing to exchange information. FOSS, Wikipedia are projects based on this model. They have shown that throwing contributors at the problem can achieve decent results.

Part of the solution is to use a distributed file system for this, so that users who don't contribute to the content however support hosting and transmission costs directly and automatically.

We don't need yet another commercial or non-profit social network. We need non-commercial contribution networks.

> This is part of the reason why Flash used to be popular with companies.

I would happily go back to flash. However bad flash was, it was at least external to the browser. I could turn it off globally and things would get much lighter and memory would be freed up. All we have done with html5 is integrate the shitty functionality into the core of our browser.

The one thing that Mozilla had to do was not normalize this crap, and they wouldn't do it because they weren't hip enough or something.

Publishers don't have as much control as you think. I've seen so many failed experiments in years past. This is our fault. We enabled them to abuse us.

It’s always the users who have the final word. Otherwise we’d still be watching TV.
It's more complex than that. When every page out of given category (e.g. news, shopping) makes the same decisions, you don't have anything to say except not to use them at all. Not read the news (easy) and not participate in discussions your friends have about those news (harder), or not shop on-line (hard), etc. The situation persists because on day-to-day basis, our need to use a particular product or service is greater than our discomfort with it.
Welcome to saying OK to every site. Not sure how you've improved things.
I've considered this same approach, but I would create two different applications instead of one. The first one would be a light-weight "browser" with built-in layout styles. The site would merely have to specify the content, and the browser could display it in a way that fits the user's screen size. Content could be laid out in a way the user approves, eliminating the need for special site design. Payment information security could be built in. Companies would love to target this application because their online stores would already be optimized for user viewing and click-through. (It's easier than a company having to ask "How would you like us to send you content in a way that would get you to click on it". No more guessing game! No more client-side analytics!) And heck - RSS could be made useful by there being a built-in feed-reader.

The other program would be an application runner with internet capabilities (and permissions settings), tailored more towards heavy-weight applications that need lots of features (like audio editing), but they have to do it manually - no built-in play(audio.ogg) like in the first program.

Of course, there are a number of downsides. Users don't generally want to open separate programs much less download them (unless they're bundled). But the way apps are these days, I don't think people would mind.

I feel the same way about Pocket, and I didn't like the idea of Screenshots being merged into core (was a test-pilot extension for quite some time before). I have found though that Screenshots built-in is really nice for less technical users, especially for some more "complex" screenshot types, like webpage only, or full page screenshots. I rarely use it, but I've gotten many of my less-technical co-workers to use Firefox's screenshotting feature quite often.
So one thing I'm going to be looking into is whether this let's plugins handle / intercept the feed content now instead of Firefox's rather confusing preview.

All in all, I'd say this had just about zero impact on folks who actually use feeds.