Casually maybe once a day. No tabs. Two or three separate windows: one for the lists of 30 items — no scrolling, one for the comments on the item, and maybe one to open the article depending on the comments or if the title sparks my interest. I up vote good comments and good articles that I read in full and post an article if someone hasn't already. I've started using HN Angolia more often.
Consumption in moderation.
I am in the world only for the purpose of composing. — Franz Schubert
Ladybird, servo, and Flow are new browsers currently being built. These new browsers are not derived from any of the big three browser engines: Google Chromium, Apple WebKit, and Mozilla Gecko. https://en.wikipedia.org/wiki/Comparison_of_browser_engines
Heard the same thing from React Native - now some of the biggest (Slack, Zoom, Skype, Discord), most performant (Figma) apps are built on both.
Only way I'd have a take like yours is if I was a native dev, and my job security relied on companies hiring 3 people to lead 3 teams for 3 codebases (Web, Android, iOS native) - rather than 1 team and 1 codebase for all 3. I'd dishonestly dismiss the notion of cross-platform programming only out of self-preservation, and not any semblance of pragmatism.
> some of the biggest (Slack, Zoom, Skype, Discord)
If everyone is jumping off a cliff, would you too?
Slack: downloads 500+ megabytes of trash and stores it on your computer. It also is dogshit slow to load conversations. It used to have a bunch of really neat integrations, and then they did the rug-pull for chat history, APIs, and other costs. It's going on momentum now but most businesses and gamers have moved off of it. Its calling feature simply refuses work on Firefox on Linux for no technical reason whatsoever.
Zoom: barely works in a browser tab, and the app receives updates daily, and still has broken user experiences. Chat is barely functional, and screen sharing breaks often. Little or no useful API or integrations. Terrible user experience. But the configuration is probably the best of the apps you cite.
Skype: Microsoft killed this a decade ago, I don't know why you'd bring it up.
Discord: well at least they have best-in-class user experience for gaming voice comms. Up until you have too many people, at which point... good luck getting your whole gaming group together. There's a huge cult for bots and integrations, but I fear its messages will go the way of Slack -- pay for (or otherwise encumber) old/large message histories. It's terribly organized, and doesn't like running more than one client or window at a time, so it's a really terrible user experience for power users -- and it's very hostile to running a third party client to improve that. It's pretty bloated for the capabilities it has (better than Slack though), but it is packaged fairly well (very easy to install or update the Electron app) and integrates into things like Slack used to.
> most performant (Figma)
Figma is performant? Figma is dog slow compared to what functionality it provides. Apps ran faster on Mac OS 9 with a 275MHz PPC processor 30 years ago that do pretty much the same thing that Figma does today.
> Only way I'd have a take like yours is if I was a native dev, and my job security relied on companies hiring 3 people to lead 3 teams for 3 codebases (Web, Android, iOS native) - rather than 1 team and 1 codebase for all 3. I'd dishonestly dismiss the notion of cross-platform programming only out of self-preservation, and not any semblance of pragmatism.
That's a typical thought for someone who's acting on the defensive and hates computer science. Maybe you should change careers into middle management or executives, you seem the type. Or maybe you might want to cut back on personal attacks because there's plenty of pragmatism in wanting native applications if you'd look past your own short-sighted career-driven opinion.
If you don't want to handle the unique benefits that each platforms give then you don't need 3 teams.
Writing for web and Android and iOS native isn't what I'm arguing for, and you're moving the goalpost by trying to change it to that. Native apps have way better performance than web apps there, but they're still put into user-hostile walled gardens. You want pragmatism? Focus on why I want native apps on my desktop platform, discussed in the sibling fork of this comment thread.
I don't know how to answer this. Bloatware is being fixed by cross platform frameworks, but hardware is also being upgraded accordingly to facilitate it. I've heard the theories; and I know 3 codebases for 3 platforms is sooner becoming a relic of a time gone-by than gaining ANY momentum in both the job market AND modern stack statistics. As is one codebase team for native desktop applications - especially when there are technologies now that allow you to reach more market share and accessibility for having the same codebase reach several platforms and device types.
>Zoom: barely works in a browser tab, and the app receives updates daily, and still has broken user experiences. Chat is barely functional, and screen sharing breaks often. Little or no useful API or integrations. Terrible user experience. But the configuration is probably the best of the apps you cite.
You probably don't use Zoom often. It works great in-browser, user experience is rigid, just because YOU don't use the API or integrations doesn't mean it's not useful - there's an entire Zoom Marketplace where you can build apps with scopes that tailor to your needs, I have more than a dozen setup; and my single-most used integration between ALL my stack is a simple Zoom General App that checks attendance for past meetings, and starts a routine based on whether the invitee's email is in that list of past meeting participants or not. But YMMV on both ends of this position.
>"Figma is dog slow compared to what functionality it provides"
Again, not sure where you're coming from. It's very performant.
>"Maybe you should change careers into middle management or executives, you seem the type."
Luckily, Team programmer -> Senior Management -> Executive was my path.
>"Or maybe you might want to cut back on personal attacks because there's plenty of pragmatism in wanting native applications if you'd look past your own short-sighted career-driven opinion."
Sure! But that's the thing; you have to look at PAST and HISTORICAL trends to see its validity.
>"You want pragmatism? Focus on why I want native apps on my desktop platform, discussed in the sibling fork of this comment thread."
Sibling fork shows you're a minority, more and more people are looking up "(function) online" to accomplish something without leaving their browsers; trust in installing exe's, msi's and pkg's are at an all-time low and, in many user experience studies, are seen as hostile.
Instead of complaining about native applications being outside of sandboxes... try looking at existing sandbox solutions. Or, hey, use an open source operating system and extend the existing sandbox solutions for whatever you think is missing.
You're trying to present an "instead of" that assumes I should want native apps and should jump through hoops to find a way to get what I want from apps that aren't designed for it. I want web apps, because they already do what I want, and keep getting better.
The right answer to "download our app!" is "no, stay in your browser tab".
> try looking at existing sandbox solutions.
I have, quite extensively; virtualization and sandboxing are things I have a great deal of expertise in. The best available application sandboxing solution that provides useful comprehensive APIs is the web. The next best solutions are mobile platforms, but that doesn't help laptops/desktops (no, iOS apps on macOS don't count), and aren't designed to let the user do things like block ads.
If an application is open, then sure, there are plenty of other options. If an application isn't open, I want it contained in a sandbox not of its own making, that it can't escape, that provides sufficiently comprehensive APIs such that interesting applications get built for it, and that keeps the user in control.
> You're trying to present an "instead of" that assumes I should want native apps
Yes.
> and should jump through hoops to find a way to get what I want from apps that aren't designed for it
What do you want which isn't designed for a native app?
> I want web apps, because they already do what I want, and keep getting better.
Perhaps. But where a web app might do what you want and get better, a native app can do what you want and get even more better.
> The best available application sandboxing solution that provides useful comprehensive APIs is the web.
You missed the next part: Or, hey, use an open source operating system and extend the existing sandbox solutions for whatever you think is missing.
> If an application is open, then sure, there are plenty of other options. If an application isn't open, I want it contained in a sandbox not of its own making, that it can't escape, that provides sufficiently comprehensive APIs such that interesting applications get built for it, and that keeps the user in control.
So you're either wanting to use and develop for Linux, or you're wanting to build apps that fit in walled gardens.
Guess which one lets you build and/or run native apps in a sandbox not of its own making, and provides comprehensive APIs, and keeps the user in control? It's not macOS or Windows, it's not iOS or Android, and it's definitely not web apps (which are the least common denominator of the list).
> What do you want which isn't designed for a native app?
Running in a user-agent which is explicitly adversarial to the app's interests and capable of e.g. filtering out and rejecting its HTTPS requests and changing its displayed content based on user preferences, such as preventing the loading or display of advertisements/tracking/etc.
Please by all means suggest an established sandboxing technology that applications use that already does that. If your answer is "you could extend existing native-application sandboxes to be capable of that", my response is "why should I bother when I already have one that does what I want and that applications actually use?".
I would love to instead have a world in which everything is Open Source, in which case it'd be less necessary. Given that we're not in that world, the web is the platform I want proprietary applications to live in.
> So you're either wanting to use and develop for Linux, or you're wanting to build apps that fit in walled gardens.
I already use and develop for Linux, for a variety of Open Source applications. When I run other people's applications, I want them to either be Open Source or I want them to stay confined to a browser tab. Browsers aren't a "walled garden", they're a containment mechanism that works for the user.
> Guess which one lets you build and/or run native apps in a sandbox not of its own making, and provides comprehensive APIs, and keeps the user in control?
Delete the word "native" and the answer is "the web". And you've made zero compelling cases for adding the constraint "native".
To be clear, I could easily describe cases where native applications are better. For instance, I don't particularly want to run a code editor on the web, though many people do. 100% of those are cases where I seek out Open Source applications, so that I can trust them to not be doing things counter to my interests. And such applications don't need the same kind of sandboxing; they need to guard against security issues, but they don't generally need to guard against the application itself intentionally doing things against the user's interests. (That said, things like the xz backdoor do happen, which is an argument for being able to sandbox individual libraries and not just whole applications. But again, that's addressed by coarse-grained sandboxes like "this code shouldn't be doing this whole class of things at all".)
> Running in a user-agent which is explicitly adversarial to the app's interests and capable of e.g. filtering out and rejecting its HTTPS requests and changing its displayed content based on user preferences, such as preventing the loading or display of advertisements/tracking/etc.
I would love to have that in my OS. But, let me know what browser you think that is. It's not Firefox, nor Chrome, and certainly not Edge.
> Please by all means suggest an established sandboxing technology that applications use that already does that.
Linux cgroups is an established sandboxing technology. It has the potential to do what you want but currently needs more work to make it simple.
Applications don't use it to the extent that they should.
> why should I bother when I already have one that does what I want and that applications actually use?
Because browsers don't do what you want. Browsers have been subverted to no longer be user agents. Browsers don't reject HTTPS requests that aren't in the best interests of users. You have to install extensions to get that. If you have to customize your "user agent" then I suggest that customization belongs at the OS level. Otherwise, for example, in the case of Windows or macOS, you're just running someone else's game and the browser is merely a veneer.
> When I run other people's applications, I want them to either be Open Source or I want them to stay confined to a browser tab.
I want more restriction than a browser tab. I want more restriction than browsers are going. I want this in the OS and the reason it doesn't yet exist is because there are so many web developers who build terrible web apps instead of learning computer science to build a (terrible) native application and ask for the same restrictions in the OS instead of a browser.
Access to store and retrieve user credentials? No. I want to run multiple instances of the same app without every app seeing all of the credentials. I want a separate password manager that lets me choose when or where to provide credentials.
Access to store things on my computer [0]? No thanks at all. If you're running in a browser, you should be lightweight. You should eat the storage expenses for your app and you should minimize your app's size to minimize your network transfer costs. I have very limited storage space, limited write endurance, and web apps waste both.
Run stuff in the background [1]? No. Run your compute on your own hardware. Power is expensive and that web app running whatever it's running is making my whole system slow down. Ten different tabs, for six different apps, all thinking they can run whatever the hell they want, and leaves very little available for me to actually get work done.
Access to my GPU [2]? Dude, no. I have a slow GPU and that crappy web app is slowing everything down while eating both main memory and also GPU memory. And who knows what kind of security isolation GPUs have these days (protip: none)!
Access to my USB devices [3]? No friggen thanks. That slow hard disk? It's USB. And that USB bus? Yeah it's slow too. And what a security nightmare: that's where my USB-to-ethernet adapter is, on the same slow bus!
Microphone? Camera? System notifications? No, no, no [4].
I want what you want, but I want it at the OS level. Without OS-level control, that web app isolation makes everything worse.
> Linux cgroups is an established sandboxing technology. It has the potential to do what you want but currently needs more work to make it simple.
I'm extremely familiar with cgroups, and no, it really doesn't have anything remotely suitable for interposing application UI elements, nor is it a good fit for intercepting HTTPS requests unless you're prepared to run a proxy that MITMs all requests and you overcome the certificate pinning many applications do. (And the most obvious ways of doing that tend to lower security.)
Browsers are a nearly unique environment in this regard, in which myriad applications are built to let the environment (the browser) handle both the network access and the UI rendering for them. It is a path-dependent marvel of history that we have such a popular platform that gives as much control to users as it does.
> You have to install extensions to get that.
And the Linux kernel alone doesn't do what you want either, you need userspace frameworks for that. The browser provides the necessary APIs to intercept requests, and extensions use those to implement all sorts of useful functionality. "You need an extension" is not a counterargument when the extensions already exist and other frameworks need the equivalent as well.
> If you have to customize your "user agent" then I suggest that customization belongs at the OS level.
As mentioned above, OS sandboxing is substantially worse than browser sandboxing for the purposes I care about, and does not solve the problems I have. In a browser, both the UI and the network access is handled by a user-agent that can be adversarial to the application.
Oh, and the best up-and-coming solution that offers anywhere close to the same thing? WebAssembly components running outside the browser, where you can say to a component "I won't give you raw network access, but if you hand me network requests I'll hand you results".
> in the case of Windows or macOS, you're just running someone else's game
You'll get no argument from me on that point. But that doesn't hold for an Open Source OS and browser.
> I want this in the OS and the reason it doesn't yet exist is because there are so many web developers who build terrible web apps instead of learning computer science to build a (terrible) native application and ask for the same restrictions in the OS instead of a browser.
People who have different preferences and values than you do are not stupid. People who don't care about the windmill you've chosen to tilt at are not ignorant.
Capability systems have been researched and developed for decades, in many different forms. They could, in theory, be used to solve the problem you care about, given sufficient capabilities and substantially different application design to integrate such capabilities. That has both practical implementation challenges nearly on par with "write a new OS" or "write a new web browser", and also has practical adoption challenges of convincing people to write applications for it when many native applications are trying to get more capabilities that the user may not want them to have.
Despite all that, there are people working on many aspects of that problem. The fact that people don't immediately go "let me drop everything I care about that works for me and prioritize working on your approach" suggests that you either need to do more work on developing it yourself (because nobody will ever care about your exact preferences more than you do yourself) or learn to pitch it to people who don't already agree with you.
> I want what you want, but I want it at the OS level.
See the previous paragraph: Feel free to write it then. When you've built something that's anywhere close to the capabilities of a web browser, I look forward to trying it, and I'm sure many other people will too. I hope you succeed.
The reports about this Terms of Use for Firefox pushed me to build from source and run LibreWolf. In the past, I have not been able to successfully build FireFox. Today was a breakthrough for me as I was able to successfully build and run LibreWolf. Things I like so far:
open ... "about:telemetry"
Blocked Page
Your organization has blocked access to this page or website.
Lots of sane defaults that actually respect privacy and security.
uBlock Origin is installed by default.
No information is sent back to Mozilla.
I don’t bookmark. I have a "Home" page with "One-liners & Links of the Day." The links are listed in reverse chronological order by day. Only this month is kept on the home page. There are links to previous months’ home pages at the bottom. Since it's a web page, I am not constrained to how some “Bookmark” manager wants me to view links. I can add whatever I want. Annotations, color, and non-links like code snippets are in there. If there is Too Much Information (TMI) I collapse it in a detail / summary HTML tag.
If I actually go back frequently to a link or to a piece of code, I put that link or code snippet in a more permanent "Document" web page which groups the items by topic. For example:
Typography
— ‘ ’ “ ” • … × °
At the moment, I am keeping the web pages local. There is a duplicate on an actual web server so it can be accessed from other devices.
I feel it is difficult to do anything on the phone and don't use it so much. Adding a bookmark temporarily on the phone and adding the link later is easier from the laptop.
This seems like an interesting way to approach this problem. obviously this is different for everyone, but do you find a chronological approach useful? also do you manually edit the webpage? if you have some code thats helping you manage your system itll be cool if you can share it. I like the approach here, and making it a webpage makes it super easy to do some of the other things i wanted as well
Reverse chronological shows the most recent first which is useful.
It's a manual system. Web pages, HTML and style are manually edited with a text editor. There is more code, HOWTOs and notes on my private home pages. Here is a public page:
The paint program we used was called "fged". It could generate C code for animations. People would spend hours generating their animation masterpiece, then bring their friends to play it back for them.
I think I remember fged. Wire-frame transformations were popular at that time. There was also IPaint. Spectricon could paint in various graphic modes including 16 colors on the newer Icon computer. The flood fill's hand coded 80186 assembly was still slow due required calls to the Cemcorp graphics API.
It's a very preferential opinion because keyboards can be such a personal thing. I used the Nuphy Air75 v2 for a week, and it is the best keyboard that I've ever used. I really like that particular layout: Ctrl Opt Cmd,the arrow keys tucked into the right Shift key and the Del key just to the right of the Backspace key.
https://nuphy.com/products/air75-v2?variant=40635218133101
Stuffing things to the right of the Enter key? So the Enter key is not "in the vertical middle of the right-most area" anymore? This would mean I can't position my finger reliably over the Enter key anymore, and would need to either guess or look?
That would be a hard "No" for me (with an addition of "Why would anyone ever want to use that?", but I understand that tastes differ).
P.S. And don't even get me started on the arrow keys smashed into the rest so not only Enter/Backspace/Right Shift positioning is gone for me but the arrow keys positioning is gone too.
P.P.S. If people like it it's fine, not everything in the world should be conforming to my personal taste, but that picture where they have the keyboard positioned over the MacBook keyboard and the top of the trackpad (and a mouse to the side) just leaves me completely flabbergasted.
My pinkie is what I use for Backspace, Enter, and Right Shift. It resides half on the aluminum, half on plastic. Plastic is a bit taller, and aluminum is a bit cooler -- if I feel that, I know it's in the right spot horizontally. When I move it for an occasional apostrophe (e.g. a moment ago for typing "it's"), I need to put it back in the right position. With an additional set of keys on the right, I can't position it properly without looking at the keyboard.
Consumption in moderation.
I am in the world only for the purpose of composing. — Franz Schubert
reply