[HN Gopher] The web browser I'm dreaming of
___________________________________________________________________
The web browser I'm dreaming of
Author : mvolfik
Score : 39 points
Date : 2021-06-29 17:47 UTC (5 hours ago)
(HTM) web link (dustri.org)
(TXT) w3m dump (dustri.org)
| pavpanchekha wrote:
| I'm not going opine on the list of removed features, but if the
| author is interested in a browser that's easy to understand,
| written in a memory-safe language, and (heh) eschews performance
| in favor of simplicity...
|
| May I recommend the book I'm writing about how web browsers work?
| https://browser.engineering
|
| It implements a (very simple) web browser in about 1000 lines of
| Python, and it's pretty easy to extend with new features (many of
| which are exercises in the book). I'm working on the seventh
| chapter right now---it adds tabs.
| EugeneOZ wrote:
| I want Evian from my kitchen tap. Who cares.
|
| It wouldn't look like a useless hysterical whining, if there
| would be something constructive, or at least some explanations to
| these "I want" lines.
| warpech wrote:
| Sounds like Firefox 1.0 has all the author needs, just disable
| iframes, hook in a modern JS engine and you're good to go.
| roca wrote:
| They don't just want a different Web browser, they want a
| completely different Web that is much less useful.
|
| The difference is quite stark. You can build a different Web
| browser. You can't decree that henceforth all Web sites will
| conform to your preferred subset of Web features.
|
| Ranting and dreaming is fine, but the title is a bait and switch.
| oneplane wrote:
| Sounds like the author isn't a normal web user. Nobody is going
| to pour millions into a browser that the typical user doesn't
| want.
| folkhack wrote:
| 100% they are not a normal web user, I am stating this as a
| fact.
|
| > WebRTC: "real-time communication capabilities", in a web
| browser. Pepperidge farm remembers when chat apps weren't
| running in browsers.
|
| It seems to me that they want media/experience/communications-
| rich features removed from the browser, in-lieu of your local
| OS/software suite. To me, the _core feature_ of "the browser",
| and the web for that matter, is open standards communication +
| cross platform dissemination of information... rich-media
| included (video, audio, RTC).
|
| This list would take us back 10-20 years to when the browser
| was still a fledgling platform for development by ripping out a
| TON of features that people use on a daily basis.
|
| ---
|
| Overall the article feels like a daily Gentoo user trying to
| call shots on what their ideal version of Windows would look
| like:
|
| 1. Your ideals vs. the product the world uses are two _very_
| different things.
|
| 2. Sure it's a valid thought experiment, but I personally
| wouldn't spend the time writing/marking-up/citing a 152-item
| bulleted list expressing an ideal that will _never_ happen.
| dijit wrote:
| Heh. This is my friends blog.
|
| Anyway, I'll repeat here what I told him on IRC: you'll have a
| hard time if you're waiting for a memory safe web renderer. Servo
| is far from there.
|
| I use qutebrowser (which uses QtWebEngine underneath, which uses
| Chromium even more underneath) and I love it to death (even
| though it consumes 24GiB of ram right now).
|
| I even had a mini project to make qute backend onto Servo which
| _mostly_ was working until I gave up because even basic websites
| didn't render correctly with Servo.
|
| But otherwise I think Qute ticks all his boxes, because you can
| disable so much of what the engine is doing- but even though it's
| python it depends, hard, on C++ components, like Qt and Chromiums
| renderer and... you can't turn off subsets of the JavaScript
| language.
| zxzax wrote:
| You might consider advising your friend to shy away from the
| "rant" and "hot take" styles, I know it's popular among
| bloggers and twitter users but it's pretty uninteresting
| reading for someone who's read this type of post about web
| browsers for what feels like the 1000th time... If it was
| feasible from a technical and business standpoint for the
| chromium team to cut costs and remove 95% of the features added
| in the last 5-10 years, they would have done it by now!
| qwerty456127 wrote:
| > Written in a memory-safe-ish language that a plebeian like me
| can understand, review and contribute to, like rust and go or
| even lua or V, but please no lisp, elisp or haskell.
|
| Would "a plebeian like them" care to explain why they don't like
| Lisp? Lisp as I see it is just the ultimate syntax of "(function
| argument argument)" and there is nothing more to learn unless you
| take a specific Lisp and compare it to others. I hardly even
| understand why do people keep inventing languages which are not
| lisps (and why does everybody seemingly find C-like syntax more
| intuitive).
| nerdponx wrote:
| One possible reason: Lisp-like languages more or less require
| decent text editor support for productivity, otherwise you'll
| be stuck counting close parens. The same is not necessarily
| true for most other languages.
| bryanrasmussen wrote:
| I too am excited for the day when bespoke browser development
| will be a product niche serving the very far end of the long
| tail.
| qwerty456127 wrote:
| > maybe tabs
|
| By the way I always believed no app should implement their own
| tabs. A window manager should take care of this. Nevertheless now
| I feel like a browser is a reasonable exception given how many
| tabs I open in it every day.
| dkarras wrote:
| "I personally don't have a use for X and it expands the attack
| surface so it shouldn't be included. These other things I want,
| while they can also expand the attack surface are fine."
| folkhack wrote:
| "And I'm going to post links to merged/released Chromium issues
| that have been in 'Fixed (Closed)' status for 2 years to make
| my security-conscious case against X while I'm at it!"
|
| (referring to controller/gamepad support)
| karamanolev wrote:
| I completely disagree with the author. The browser allows a
| distribution model that vastly improves, in a lost of cases, on
| the alternatives. Not always, of course, but those alternatives
| can be harder to maintain, legacy desktop apps. I love a lot of
| things that desktop apps stand for - control of one's data, more
| privacy, less tracking, etc. But that's what businesses want, not
| something using the web exposes.
|
| WebGL can allow 3D medical, engineering and other productivity
| visualizations and learning.
|
| WebRTC allows people to mess less with installing 8 different
| conferencing apps and keeping them up to date.
|
| A built-in PDF viewer allows it to update frequently along with
| the browser and if properly sandboxes is probably more secure
| than installing some random PDF viewer setup.exe from somewhere.
|
| Gyroscope, accelerometer and compass APIs allow me to install
| fewer crappy small ad-packed native apps that I'll use one in a
| blue moon. Should they be gated by proper permissions? Sure. Why
| should I trust a random native app with more data than a random
| website?
|
| I can probably continue with a lot more of these. They boil down
| to some of:
|
| * If I wouldn't bother installing a native app, then allowing the
| web to do it enables another use case for me.
|
| * If I don't want to trust a website with a piece of data (gated
| by permissions), why would I trust a native app?
|
| * The fact that someone wants to use the web just for document
| browsing doesn't mean there aren't large swaths of users who
| benefit greatly for using it for many other things.
|
| * There are security holes in the browser. Installing native
| applications is, in a lot of cases, more dangerous.
| runarberg wrote:
| Also important to mention is _fun_. The browser allows people
| to make fun stuff, be it a video game (using webGL) or a
| multiplayer instrument (using Web Audio API), and distribute it
| really easily. These API are well documented and are available
| to anyone to write and share. Thanks to the proliferation of
| web APIs you often don't even need a server to make cool stuff
| and share with your friends.
|
| If you have to create an executable for your fun little
| project, and make sure your friends have all the dependencies,
| and then your friends that have only Macs or Iphones won't be
| able to use it because you don't know how to share it with
| them, you might not bother making that thing in the first
| place, and the world becomes so much poorer as a result.
|
| The web with it's many features and API is really democratizing
| how we make fun interactive stuff and share it with each other.
| Most days there is a fun project that serves no purpose except
| to entertain strangers that makes it to the front page of HN.
| How many of those would still be made and shared if browsers
| would be as feature poor as the OP wants.
| pmlnr wrote:
| > medical
|
| You surely don't want medical data on the web, right? What
| could possibly go wrong?
| folkhack wrote:
| Factually we're already there. I've reviewed my own HIPAA-
| sensitive lab results in a patient portal for example. I'd go
| check out some of the solutions Epic Systems has put out if
| you're interested in current product offerings in the space.
|
| Information wants to be shared, collaborated on, and worked
| on in real-time... both private intranets and/or public
| internet provide platforms to do this.
| bufferoverflow wrote:
| Yes, I do. Not all medical info need privacy.
| joshgel wrote:
| It's actually mandated now that providers allow free, on-
| demand, API access to patients for their medical data.
| karamanolev wrote:
| I can argue that it's easier to architect an intranet web
| medical data viewer right now than a typical desktop
| application accessing an intranet server.
|
| Client-server desktop applications typically use custom
| protocols and custom servers leading to a higher likelihood
| of security issues.
|
| They're harder/slower/trickier to update and administer
| within a big organization, leading to a higher chance of
| messing up.
|
| Whatever security issues you can think of running it in a
| browser context, more exist when running it as native code.
|
| If you run an intranet web service with the same security
| precautions as a public web service, which is currently very
| well explored, there are _less_ things to go wrong.
| zxzax wrote:
| Please don't shoot the messenger here, but your doctor and
| insurance company are very likely already using the web to
| exchange information about you. You can either have that in a
| way that is standards-complaint and vetted by a large group
| of browser engineers, or they could try to roll their own...
| which would you prefer?
| kencausey wrote:
| Perhaps, but keep in the mind that Intranets exist. It is
| possible to have 'private' web services.
| pmlnr wrote:
| If you find a way to build dillo with js support, you'll have it.
| chrismsimpson wrote:
| "I don't want WASM or JIT hacks" (paraphrased). The author
| clearly doesn't understand the von Neumann architecture.
| ergot_vacation wrote:
| A lot of this comes down to taste, but for my money almost
| everything about this is wrong.
|
| The first thing a web browser needs is a non-profit, propped up
| by an enormous endowment, so that they can stay independent in
| the face of unthinkable pressure and sabotage attempts from the
| tech monopolies.
|
| The second is to enshrine one concept above all others: you are
| building a tool for the users. Not for yourself, and not for any
| company. Serve the users. Do not harm or exploit them.
|
| The third is to understand that a web browser in the modern era
| is no longer a document viewer: it's a weapon of war. It must be
| assumed that every page you load is trying to do something
| nefarious to the user, from low grade like dark patterns and ads
| to high grade like phishing and full-on malware and hacking
| attempts. Start from a point of extreme skepticism. Nobody can be
| trusted, including (especially) not leading tech companies.
|
| The fourth is to get rid of cancerous, masturbatory habits in
| programming like chasing after whatever language is most hip and
| stylish this week. Only three things matter: How efficient is the
| program, how secure is the program, and how quickly can you build
| it? These obviously pull in different directions, so a balance
| will have to be struck, but the point is there's no space for
| chasing languages or programming practices for vague ideological
| aspirations. Tried-and-true over shiny and new.
|
| A new browser is definitely needed, and probably won't happen
| thanks to a near complete market capture by tech monopolies. But
| the solution to current issues isn't to make a browser that's
| even more drenched in them.
|
| Edit: I will agree with the author on one thing though, which is
| that modern browsers do too goddamn much. Scale the shit back.
| fungiblecog wrote:
| Lost me at no lisp...
| diegocg wrote:
| What we need is OS-level innovation that allows to safely run
| remote applications. Inferno partly went in that direction, but
| nothing else seems to have done any better AFAIK.
| MaxBarraclough wrote:
| Java tried, but failed.
|
| Personally I think it's fair to say Java didn't try hard
| enough. It never took sandboxing of untrusted code very
| seriously (compared to, say, modern web browsers).
|
| It also made things awkward for the user, expecting them to
| install and maintain a JVM rather than hiding that away and
| delivering a native experience.
| reayn wrote:
| 'just need someone to write it now'
___________________________________________________________________
(page generated 2021-06-29 23:00 UTC)