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.
> It seems to me that they want media/experience/communications-rich features removed from the browser, in-lieu of your local OS/software suite.
I got this impression too. I dislike that their solution seems to be nerfing web-browsers in hopes that developers begrudgingly go back to desktop apps instead of buffing the tools used for building desktop apps so that they're what people want to develop.
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.
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!
I will not be advising him of that because I share his opinion that the web is fast becoming/has become an application delivery system and not a document reading system with some media additions; in fact many here reading this will say "duh!" because they assume this is a good thing.
I don't think it's a good thing, I think it's inefficient and used against people as much as it's used _for_ people. Standards such as "WebUSB" are just incredulous.
The fact that some very smart people managed to get a javascript renderer to go real fast seems to have spawned millions of people just to dump garbage into it constantly, and -require it to be enabled- to do things that used to be possible without it.. it's shockingly bad for accessibility, bad for performance, bad for my ram. But I guess you don't have to worry about _my_ ram.
I'm very sure it's profitable to turn the web into an application platform, and it _is_ delivering a lot of actual value to a lot of people, certain things would never be possible, but it's abused too, and honestly it takes a lot away, privacy among them... but we can't talk about that as an industry because half of the people in it depend on that ecosystem being maintained.
I'm not going to go as far as to say that "the web" is the new oil industry; because we have no oil spill equivalent and we havent gone to war about it (though the e-waste due to inefficiencies and "everyone has 8G of ram, right!?" is likely not helping the ecological situation).
But the industry is propped up because it's too big to fail now, and you're damned if you get in the way.
Basically Google woke up and decided it wanted to be Microsoft without actually dealing with hardware vendors so let’s just put everything on web and hey, let’s track and show you ads while we do it at .98 efficiency
> I will not be advising him of that because I share his opinion that the web is fast becoming an application delivery system and not a document reading system with some media additions; in fact many here reading this will say "duh!" because they assume this is a good thing.
I guess I'm one of those "duh" people. I think it already is an application platform/delivery system (has been for a long time), and I think that the ever-evolving web is a good thing.
In college, I had professors literally laugh at me when I said I believed most software was moving toward the internet. Fast-forward to today and I'd say that their actual insults against my chosen direction of software engineering (targeting standards-based web solutions) were not only unprofessional - they were entirely not correct.
Reading this document literally felt like I was hearing their arguments as to "what the internet should be" all over again... And, as someone who embraces the internet, I feel so much of this is regressive. Especially in regards to taking shots at stuff like WebRTC...
Your friend and I differ so much in-that they argue against things like communication, graphics, gaming, etc in the browser where-as I have built a career off of embracing it.
> I'm very sure it's profitable to turn the web into an application platform
The web has been an application platform since ECMA landed in Netscape, and arguably long before that too. The anti-application "content presentation only" take has been something for a long time, and it is not going to happen or we'd still be on the original "Hyper Text Markup Language" spec. The web has always wanted to be more than it's previous spec... it's an ever-evolving standard that is designed to meet the changing needs of it's users in an ever-changing world.
Information, capability, and expression all want to be free.
If by free you mean mandatory accounts, activity trackers, 50% screen ads, background crypto miners, 8gb ram for reading the news and email, abysmal performance for what is essentially displaying text, media and information, literally WASM VMs and background webagents running in browser.
No thanks, I'd like native back.
I worked with a startup that is putting IDE into the web, and I kinda did like web at first. Then I worked at a startup that wanted to run jobs in client browser using WASM instead of cloud compute resources.
At first, I really liked being able to run interpreted code, to change code at runtime without having to recompile, to be able to visit a website and then borrow code for theme/animations I liked. But that is long past now in the vDOM age for performance in what is a very inefficient system.
> If by free you mean mandatory accounts, activity trackers, 50% screen ads, background crypto miners, 8gb ram for reading the news and email, abysmal performance for what is essentially displaying text, media and information, literally WASM VMs and background webagents running in browser.
When I said "information/capability/expression want to be free" it was not inclusive of all of these negative things. And, I find it a direct bad-faith argument to say "well that's what you get when X", given "X" is my statement "information/capability/expression want to be free".
I find your "I'd like native back" statement to be akin to "people abuse stuff so we should just outlaw what they abuse"... Features in tech are going to be pushed toward capitalistic ends because we live in a capitalistic world. Truly - I am the money I make... I am as important as my bank account dictates. My access to healthcare, education, resources, everything dictates this. I live in America - if I am not profitable I literally do not deserve to exist within civil society, and this problem is not exclusive to the US.
"Mandatory accounts, activity trackers, 50% screen ads, background crypto miners, 8gb ram for reading the news and email" - these are more a product of the content of the above paragraph than my claim "information/capability/expression want to be free". My entire life has been about the world trying to milk every dollar it can from some sucker - in every freakin' aspect. I am what I spend.
Until we fix what I am outlining in the above paragraphs, I think every bit of tech is going to be pushed toward hyper-capitalistic purposes because it is literally our culture to worship money above all else. Even services/solutions that should service social means are bastardized for privatized profits - including browsers.
I probably shouldn't be making these arguments here on HN as I find most of us here are so stubborn that we would willingly neuter parts of our computing experience to realizing personal ideals which alienate us from the general population of computer users. Even re-reading this comment makes me feel like some self-aggrandizing prick which I find most of us here are.
> When I said "information/capability/expression want to be free" it was not inclusive of all of these negative things. And, I find it a direct bad-faith argument to say "well that's what you get when X", given "X" is my statement "information/capability/expression want to be free".
There's a lot of bad things about native too, but it is not trying to replace an existing working system while failing the end-users so bad. Neither is my argument to outlaw items that are abused.
> I am the money I make... I am as important as my bank account dictates.
I'm not saying one solution is bad over the other (ie: feature-rich browsers vs. "native" ones).
I'm saying you made a bad-faith argument misrepresenting what I was saying when I said "information/capability/expression want to be free" by conflating that phrase/statement with literal anti-user dark patterns that I find are more rooted in capitalistic practices...
I'm presenting the argument that information does want to be free but web as a whole is quite less free than its proponents would like us to believe. And I'm definitely saying web is bad over native for the consumer, maybe not for the developer who can worry less about knowing native development which is arguably not just more complex but has quite a lot more of legacy baggage as well.
Web is quite largely controlled and censored by a handful of corporations - Google, Facebook, Amazon, Microsoft, Twitter.
Even the standards are largely dictated by Google (who ring! ring! also owns the web platform in name of Chrome).
> If by free you mean mandatory accounts, activity trackers, 50% screen ads, background crypto miners, 8gb ram for reading the news and email, abysmal performance for what is essentially displaying text, media and information, literally WASM VMs and background webagents running in browser.
Let me repeat... when you conflate my whole "information, capability, and expression all want to be free" with a ton of negative/gray-pattern stuff you're invalidating my original point in the above comments with what I see as a separate concern, ie: everything has to be built to milk money from people.
Exploitative capitalism/money making dark patterns !== "information, capability, and expression all want to be free"
I'm not sure I understand what your opinion actually is? What you've stated is a fact, not an opinion: that's what the web platform is now. So it really makes no sense to rant about that, in context. You say you won't be advising him of that, but you also seem to be arguing in favor of advising him of that, not against, and are in fact already somewhat doing it already, so it's not clear what you meant there. It may benefit to be more consistent here, and make the advice to him anyway.
What would make more sense, and be more valuable, would be to talk about what value was actually taken away, and what steps could be done to provide that value again, without taking other bits of value away in the process. The blog post, as it's written, only argues for taking more value away. So I didn't find it convincing towards that end, and it seems you didn't either, as per your GP comment. So I'm pretty confused by this follow up response.
When you spend more time arguing about how the message was said rather than what the message is actually trying to convey, it doesn’t matter what the response is: it’s unlikely that you were ever going to listen to the message anyway.
This isn’t directly specifically at you, just this whole thread in general.
"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."
"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!"
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.
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.
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.
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?
Most of the offices use cloud based patient management apps. In my anecdotal experience, as soon as they enter my phone number into one of those, I start getting significantly increased spam call volume. The spike lasts a few weeks.
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.
If only we had tried making a browser plugin for multimedia applications with a separate runtime. We could call it something flashy, for example ... Flash. That totally went better than browser security.
Another option would be feature-enabling plugins, for example a plugin that enables WebRTC developed by some random company. I still don't see how it won't be massively worse than browser security.
Flash was AWESOME in that it enabled all that everyone whining on here wanted in their browsers, not to mention the lowest barrier to entry on content creation not reached again on this day.
But you had the option! Want your computer to the unsafe man-child playgroud? go ahead, install flash. Want something serious for work, don't touch it.
But the advertisement industry had their way and apple and microsoft started to include flash by default. Do you think Google fought flash because they care about you? heh. Google helped kill flash because it gave an edge to microsoft since their ad network at the time was text only and microsoft et al were making bank on swf banners.
anyway, you had the option! it was a plugin, not the browser. Instead of a better plugin, you killed the radio star, took over w3C so that feature for your ad network would be part of the standard.
Now chrome is worse than flash. Features like Federated Learning of Cohorts will be shoved down your throat like or not and it won't even allow you to play web games or something FUN.
no view source! that broke the basic treatise of the internet. it wasn't a protocol, wasnt a medium: it was someone else highjacking your shit & doing what they wanted in a filthy untouchable applicationized sandbox you had no power over it. you the user has no power, no visibility, no say. application,. it a medium: out of your reach.
very little of this submitted screed touches upon this area, but to me the anti-webassembly remarks feel very close fit to anti-flash remarks. js has gotten bad, but I continue to think eventually we'll see better actors (especially with an arisal of custom elements). webassembly makes me think the web will get anti-web anti-understandable, anti-user as a medium increasingly for the next 50 years probably, most of my remaining life. doing good & being a respectful medium will be just as possible as without webassembly, but there will be so much energy & focus on an industrialized non-user non-acessible non-user-agency dark world shadow-nightmare hell-web because of webhassembly, that will absolutely dominate & be enticing to so so so wide a range of the alpha geeks... while users lose & lose & lose.
flash 2.0 is coming & it will be cheered & celebrated & far far worse for users than the flash we have finally killed.
> no view source! that broke the basic treatise of the internet.
I was pretty young, but I'm pretty sure I remember opening someone else's swf file in a decompiler in middle school. It was a little weird but I was able to make the changes I wanted.
Well, that was my point about SWF files. You could edit them with the right tools. But like WASM, they are far less editable than the original source files.
Unfortunately, there are very practical performance reasons to send information in a "compiled," less-editable format. Which is why even static sites nowadays typically use some type of build system.
I do wonder if with the 'somewhat standard' min.map files that can point out what the rendered versions relate to in the 'source' versions could somehow be enforced. That way you can still use the compact version first and if you do want to see what's happening you can just get the map and the source and explore.
Even if you do decompile the SWF & edit it, the flash can still interact with the page. In many cases you'd need to alter the page too, to inject your hacked swf.
Wasm code is editable via the very very good dev tools systems we have today, mostly dictated via the Chrome DevTools protocol which even Mozilla largely harkens to & which is being semi-standardized through wicg[1]. Still fairly early days but support is not bad! But... it's a monumentally harder challenge imo than JS. There are source maps, so if the site is nice, you can see what the authored uncompiled code was, but there's no facility to author in that language & recompile your changes via the debugger. And I fear few sites will post the source maps to make webassembly comprehendible. Few sites have morals, ethics, or respect for the web as a medium: they see it as a platform for them alone to dictate to you the user what you get. This, to me, is the sad end Flash had forced upon us, that the web was so much better than.
Flash was a nightmare, but you know something that's good about flash?
It wasn't enabled everywhere by default and the majority of sites didn't assume you had it, unless it was something that genuinely needed it (like, habbo hotel, or youtube back in the day) it often never got enabled, meaning people couldn't use it for tracking me, or eating up all my local resources.
That's a freedom we've lost, disabling javascript just breaks everything.
Though webgl continues to be a toggle, though enabled by default.
it was pretty assumed you'd have it, it did have an install rate of over 90% at one point. I think it was just used less often for essential things since it wasn't as smooth to integrate with the rest of the page, and pages used to be less dynamic back then in general
100% on the possibility & amazingness of the platform, and hugely in agreeance that the wide range of well specified semi-publicly owned standards that make up the web is by far one of the best most empowering things we society have done. I have colossal awe & I can see use after use after use for all the sad salty disgruntled anti- opinions poses in the sad-sheet here.
still: I have some residual sympathies i'd share. for one, I am pretty terrified the webassembly based world will radically increase the un-observabity of the already virtualizing (as in, vdom) web dev world. understanding & working with the web medium we are given has gotten increasingly hard and the webassembly world sounds like an immoral indecypherable wreck for users with all good user agency pummeled away.
but, i would not halt that. the web medium needs great liberties to grow.
but, more so, in strong strong agreeance about "what we should do" that this article sets up, I think features should be flaggable. if someone wants to be a salty crufter, let em. it's the users right to their own experience. no website is obligated to function, to work, so if you disable webgpu, the good stuff just won't work: it's your choice to break maps, & dozens of others. let users turn features off broadly as they might & enable higher powers case by case.
I think the poster is a grizzly salty refusenik, a denialist, which we hear a lot from a lot, way overmuch. these people are ultra vocal. I'm so glad their attitude is condensed into somethong reasonable. and to me: sure, I think they should have their asks. we should give folks the abity to disarm parts of the web platform. to let them have the experience they want. mostly I think these folks are kind of idiots, devuan class reactionaries harking a denialist small minded set of expectations they falsely impose on others. but the web should allow them what they want. it should make turning things off easy. because the web is about user agency. and the cost of letting folks turn capabilities off is almost nothing. they can have their broken bad experiences, when various features are required by a site. maximalize the user, even when they want the web to still be living in a barrel.
Yup!, the browser is such a great environment. It's sandboxed to death, easy to use/install, and cross compatible. (Can use any Modern Browser/OS combo). I'd rather play games in my browser than install a native app that has wide access to my personal documents.
Not to mention, Web Crypto API is the literal opposite of roll your own crypto. and is SOO much better than someone implementing cryptographic operations on JS. and can have so many use cases. End to End encryption with key stored in browser. (You can have the raw key inaccessible by JS even, only allow decryption/signing). Though I agree there are some APIs that are pretty dumb.
> Not to mention, Web Crypto API is the literal opposite of roll your own crypto. and is SOO much better than someone implementing cryptographic operations on JS
I'm glad someone is pointing this out as I felt like the author didn't even attempt to understand the Web Crypto API assuming an incorrect worst-case scenario.
WebCrypto is "roll your own crypto" as it implements low level algorithms instead of high-level protocols. The issue with rolling your own crypto wasn't "you will implement sha3 incorrectly" it was "you will use an algorithm for authenticated streaming symmetric encryption but accidentally reuse an initialization vector or fail to verify a checksum" or whatever.
Perhaps the author is just dreaming of another browser in addition to the one you prefer. One with different/less features. It is interesting how this is somehow a controversial idea. Is there some reason that the number of web browsers needs to remain small.
Different browsers can be really useful. Personally I do not need want the browser the author suggests at all, but that's just me. Every user is different. I use "links" heavily for reading HTML; it is particularly good for printing HTML tables. I do not expect anyone else to use it. (But some do, including user who actually paid money for features.) A different browser is simply an optional program I choose to make use of. I do not use it for anything financial or otherwise sensitive. There are other browsers for that.
In recent years I frequently see comments that seem hostile to the mere idea of more web browsers. I do not understand this. If this author wants some browser with some certain set of features, that is his business.
"Disagreeing" with someone's desire for a browser with different/less features because of the annoyance of native apps. It make no sense. (Blame the developers of today's "native apps", not users who want alternatives.) AFAICT, there is no suggestion in this blog post of trying to take away anyone's preferred web browser and make them use native apps. The author just wants more options besides the popular ones. A browser with different/fewer features in addition to all the everything-but-the-kitchen-sink, do-everything-under-sun ones written by online advertising-supported organisations.
or even just a "web browser mode" vs "multimedia gateway mode."
the techwizardry demands of heavy hitters like YouTube and Facebook have created an "attack surface" that forces active and constantly evolving opt out behavior. the web is actively hostile towards the lay browser (person who browses.) a million notifications to allow and enable things on first visit to a site is a terrible experience. sane defaults should disallow these apis on most popular properties.
furthermore, I personally wouldnt mind a split between the browser and a communicator. a separate webrtc phonelike app that handles all teleconferencing. i get why people dont want a native app installed for each voip solution, but a single tool that is cross compatible, pushed out of the "web browser" would make web browsers safer.
the average person is using a web browser to look at celebrity news, pictures, youtube videos. delivering those things efficiently doesnt need to be much more complicated than the web was 10 years ago. having a separate button to launch "3d game rendering mode" would be preferable to every site on the web abusing the tech behind the scenes to deliver targeted ads.
There are many things I trust neither a native app nor a website to access. Most browsers seem to opt into far too many APIs and expect me to blacklist them all in hidden advanced options. But there is no reason that everything about reading from my computer isn't off by default. Geolocation, accelerometer, raw mouse data, battery level, hardware info, fonts supported, etc.
Heck, default to running code on every site is too much for me and the first thing I turn off. All the fine grained stuff is always I fight to find and remove.
You can sandbox native apps as well, without buying into all the complexity and unplanned obsolescence (have you tried browsing on an old 32bit computer?) that web browsers come with. Also, sandboxing web apps is incredibly limited; how do you restrict a web app from accessing the network?
Web apps also provide no degree of trust. You can't know what will be loaded in advance. Native software can allow you to inspect source code and modify it beforehand without resorting to maintaining a web server for self-hosting. Hell, Debian's working on reproducible builds and F-Droid has had it for years, while the web just figured out script verification with SHAs (entirely controlled by the vendor, which misses half the point).
> 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.
Even better: let's try to build a world where people don't have to run proprietary malware, on the web or otherwise.
> 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.
Better idea: have a PDF reader that just opens documents without any scripts or internet connection. muPDF is a good option. Also, don't use random apps (native or web); distro packages are a good start for some trust beyond the vendor.
We've reached the point at which running two web apps cuts down battery life twice as much as me running my desktop, mail client, editor, newsreader, music player, and IRC client combined. The only "native" programs that come close to this level of resource abuse are Java IDEs. Web browsers are so complex that they essentially can't be forked or created anew without hundreds of millions of dollars in annual funding. And with the increasing footprint of web apps, it's no wonder people feel the need to turn their computers into e-waste every N years.
This is a rosy picture of the browser but one of the reasons I really dislike my browser exposing all this is privacy: all if this is stuff that companies can use to uniquely identify you.
I get that this is the von Neumann architecture. What I don't get is how not understanding it connects to not wanting WASM or JITs in your web browser.
Note also that the author explicitly mentions they are not that concerned with JavaScript performance and would instead prefer a supposed simpler and easier to understand interpreter.
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.
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.
> 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).
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.
> why do people keep inventing languages which are not lisps
Apparently people like to make syntax optimized for what they do most frequently.
I like C programming, and not having a concise syntax to dereference, index, and access struct members would drive me nuts. Something like foo->bar.baz += quux(42); is not too rare to have to write, but feels very natural to write this way. In Lisp, that would be terrible in comparison.
Sometimes, just sometimes, I try to add some metaprogramming and imagine how nice it would be to code in Lisp, only to realize soon after that I was overthinking it. It's a rare situation that the "special" syntax that is in my preferred language causes friction for what I do. 99% of the time, it is there to support me, to help me read and write code faster.
I am very attuned to this specific problem. Whereas the lack of infix for numeric calculation is hardly an impediment, good ways of dealing with objects and structures strike at the heart of program organization.
Numeric calculations are confined to small isolated pieces of code; they do not involve reference and collaboration. In some ways, parenthesized prefix improves the readability of nested expressions by eliminating ambiguity, and n-ary operators like * and + taking multiple arguments can even reduce clutter.
But struct access; it helps that have that convenient.
This is why in TXR Lisp there is a comprehensive referencing dot notation. What's more, there is also a blueprint for how to integrate that into any Lisp.
This is the thing about Lisp; the research is not over.
Here is some example code.
(defmeth win-drawing draw-text (fe x y fonttype fontsize align colour text)
(whenlet ((dstat fe.drawstatus))
(if (eq dstat :printing)
(upd fontsize (* fe.printpixelscale) toint))
(let ((xy (win-transform-point fe x y))
(key (cons fonttype fontsize)))
;; find or create the font.
;;
;; NB: We don't implement the C versions "font stack marker" for
;; allocating printing fonts within the array and then discarding them.
;; In Lisp, it's trivial to save and clear the entire font list before
;; printing, and restore it after.
(let* ((font (or (find key fe.fonts)
(win-new-font fe fonttype fontsize)))
(oldfnt (SelectObject fe.hdc font.font))
(tm (new TEXTMETRIC))
(size (new SIZE)))
(if (GetTextMetrics fe.hdc tm)
(if (logtest align align-vcentre)
(dec xy.y (trunc (+ tm.tmAscent tm.tmDescent) 2))
(dec xy.y tm.tmAscent)))
(if (GetTextExtentPoint32 fe.hdc text (len text) size)
(if (logtest align align-hcentre)
(dec xy.x (trunc size.cx 2))
(dec xy.x size.cx)))
(SetBkMode fe.hdc TRANSPARENT)
(win-text-colour fe colour)
(ExtTextOut fe.hdc xy.x xy.y 0 nil text (len text) NULL)
(SelectObject fe.hdc oldfnt)))))
(defun win-new-font (fe fonttype fontsize)
(let ((lf (znew LOGFONT
lfHeight (- fontsize)
lfWeight (if (eq fe.drawstatus :printing) 0 FW_BOLD)
lfCharSet DEFAULT_CHARSET
lfOutPrecision OUT_DEFAULT_PRECIS
lfClipPrecision CLIP_DEFAULT_PRECIS
lfQuality DEFAULT_QUALITY
lfPitchAndFamily (if (eq fonttype :font-fixed)
(logior FIXED_PITCH FF_DONTCARE)
(logior VARIABLE_PITCH FF_SWISS)))))
(push (new font
font (CreateFontIndirect lf)
type fonttype
size fontsize)
fe.fonts)
(car fe.fonts)))
This is a translation of the following function, which is from Simon Tatham's Puzzles.
The code to get the font was factored out into a separate function in the above Lisp:
static void win_draw_text(void *handle, int x, int y, int fonttype,
int fontsize, int align, int colour,
const char *text)
{
frontend *fe = (frontend *)handle;
POINT xy;
int i;
LOGFONT lf;
if (fe->drawstatus == NOTHING)
return;
if (fe->drawstatus == PRINTING)
fontsize = (int)(fontsize * fe->printpixelscale);
xy = win_transform_point(fe, x, y);
/*
* Find or create the font.
*/
for (i = fe->fontstart; i < fe->nfonts; i++)
if (fe->fonts[i].type == fonttype && fe->fonts[i].size == fontsize)
break;
if (i == fe->nfonts) {
if (fe->fontsize <= fe->nfonts) {
fe->fontsize = fe->nfonts + 10;
...
One of my biggest complaints about Lisp and Scheme are the dynamic typing aspects; in the C code, one can see what type is at least supposed to be in "oldfont" and "tm"; in the corresponding Lisp, only an IDE can tell the user what type should be in "dstat"
Since oldfont is a lexical variable being initialized from (SelectObject fe.hdc font.font), you probably get the most information about this by going off to MSDN to study what is SelectObject. If we select an object, like a font or a brush, into a device context, we get the previous object of that type: new font kicks out old font, new brush kicks out old brush, and so on.
SelectObject's return value is a HGDIOBJ whichi s just a void * in disguise. Thus oldfont is just a FFI foreign pointer (cptr). You can do nothing with it other than compare it for equality with NULL and pass it to Win32 functions.
I have simply mirrored the C more or less as-is.
tm is a local variable; again, you just have to look where it is bound:
(tm (new TEXTMETRIC))
so you know the type from the lexical scope. This corresponds to the line of C which goes
TEXTMETRIC tm;
It's exactly the same process. In the C code if I see tm.tmAscent, I look backwards for the declaration of tm, perhaps using the Vim # key. If I see tm.tmAscent in Lisp, I look backwards to see where tm is bound, perhaps using the Vim # key. (new TEXTMETRIC) is exactly as informative as TEXTMETRIC tm;.
Any time you see a simple variable being accessed in Lisp code, it is either lexically scoped or global. If you don't see it in the lexical scope, it is the latter.
So that brings us to dstat. Another lexical which is a copy of fe.drawstatus. We can see that fe is a parameter, but what is drawstatus? No fancy IDE is needed; just Vim. Put the cursor on drawstatus, and Ctrl-] chases the tag to the definition, a line in a big struct definition:
fe is an important parameter; it is the self object of the method.
I used the pattern matching notation in the above comment to remind myself the values this can hold. The front end objects in Simon Tatham's design have a mode variable which indicates whether printing or ordinary rendering is taking place. If you're printing, you have to do different things with colors and such (possibly using hatched pens on a black-and-white printer, plus scaling of coordinates and whatnot). I just used the three symbols :drawing, :printing and nil.
Popular languages like Javascript and Python have a worse version of this "what is drawstatus" problem, yet are used by legions of programmers in all sorts of successful projects, even large ones. In these languages there is no clear place where object properties are defined, and objects can even be monkey patched with new properties, which I do not allow.
Finding out what is returned by SelectObject is the same: put the cursor on SelectObject, Ctrl-], and it jumps to the FFI definition:
In reading Lisp, there is no panic if we are calling some function, and capturing its return value without that being declared. Firstly, most of the time we shouldn't have to know anyway; if the program is well designed, we shouldn't care about the implementation details. Unless we are specifically looking for a bug in that aspect of the code, we can just trust that it's okay.
The trend in modern languages, including statically typed ones, is to have fewer declarations. If the original code here were C++ you could probably do:
I've never grown to like that very much. Being a little bit more verbose, in my mind, only pessimizes (keyboard) typing efficiency - when scripting at full speed, but not to the extent that it would harm when "just" being productive and in the zone.
But the explicitness comes with advantages, one I assume is compilation speed (to an extent), but then also having to fix issues when type resolution is (or becomes, after a change) ambiguous, which requires small local and sometimes not-so-local changes.
Another advantage is ease of caching in a piece of code when bumping around the codebase - which is important even if I was the original author.
Also navigation to the definition of the type is faster/easier if the type is written explicitly, when using bare-bones editors but also in IDEs.
Structure helps people understand programs better. Because lisp has basically the minimal amount of structure required to make it parseable it is harder for people to understand than other languages that enforce structure via syntax.
Yes, I know that lisp programmers often structure their programs well, but there is a reason most of the good parts of lisp got incorporated into other languages and yet lisp stayed relatively niche.
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.
Why does the author think JS/TS would be useful in the browser without the APIs we have today? Most people want to do things online aside from reading text.
This was extremely perplexing for me, I saw that and thought "Ok, I like that, let's see what other ideas you have" but then I got to all the API's they want removed and that's of no interest to me. It seems the author pines for a simpler web, one that only uses JS/TS for tiny UI reasons (think jQuery-type operations) and ignores the world of web apps.
Would be nice to have two classes of browser you could switch between.
a Webapp browser which is full fat and heavy, like an OS with task managers and so on. (this is what Chrome is today)
and a basic web browser for reading news, banking, watching youtube or commenting on forums.
The issue is that we're all forced to always run #1, which leads to developers thinking every site should be a full fat webapp... when webapps should be reserved for actually advanced things like games or google maps.
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.
> 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.
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...
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.
Hi, this looks interesting, but I personally preferred the style of https://hpbn.co/.
There, instead of teaching me how to implement my own internet, it gave me a high level overview of networking history and design decisions.
After reading that book I can now keep those constraints in the back of my head when developing web applications.
I would love to read something like that for browsers:
Instead of teaching me how to write a browser in Python (which is cool I guess for a weekend project if one is into that), it would show me a high level history and design decision overview and explain what was difficult and how it was solved, what hacks were necessary, what is still an unsolved problem, etc.
My hope would be that from such a website I could take away key bits of information that I could leverage in daily coding, say „DOM nodes earlier in the document get rendered faster than later in the document because X“ or „display: none is much more costly than opacity 0 because X“ or „XSS attacks will never be able to be 100% solved because X“ or something like that.
Thanks. I agree a sort of "design decisions behind web browsers" would be an interesting book, and some of the later chapters we're writing now (11 and onward) have more of that flavor. But there's a lot of background knowledge necessary to even fill in those "X"s.
You know, all the major browsers are, like, tens of millions of lines of code, bigger than (say) the Linux kernel. And unlike the kernel, there's no good overview out there on the basic architecture and the basic concepts, stuff like the layer tree or the task queue or hit testing. It's hard to discuss, say, why one DOM API is slower than another without having those concepts in mind.
So, like, DOM nodes earlier get rendered faster (if the network is real slow and if ...) because they arrive over the network earlier. "display: none" is a lot cheaper because it doesn't produce a layout object, while opacity 0 probably goes all the way to the layer tree. XSS attacks are hard because JS can be embedded into HTML without being demarcated or separated from it. But these explanations presume some understanding of browser networking and the layout tree and the JS environment. For some simple things the "folk understanding" of these things suffices, but the joy of the toy web browser isn't that it's a fun weekend project, it's that each of those concepts is something you can pull up on the screen, read, and then understand as a concrete piece of code.
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.
i do have some sympathy to the author's point but this strikes me as overly conservative. e.g. iframes have a lot of genuinely good use cases in being a completely seperate unit. e.g. try doing something like codepen without iframes. embedded widgets that need some sort of backend or a form that needs to be seperated from user-supplied html.
i'm also appreciative of things like e.g. webcam support and webrtc, since it means i don't have to run proprietary always-on applications on my actual operating system, which don't have to ask permission for anything.
and some are also just weird. favicon svg support? why do you care if favicons support one additional image format? should we get rid of jpg as well? maybe only use bmp for everything, then we can simplify things further and not have to include any complicated decoders in the browser
true. but the point of the article everyone is missing is that by assuming you will have even the kitchen sink available to everyone at all times, is the problem.
I've never understood the obsession with memory-safe languages. I get that they are easier to program in and they eliminate certain classes of bugs, but most end users don't care. They just want a product that works. The security argument also makes less sense for browsers because most web app exploits are unrelated to memory safety.
I wrote "they are easier to program in", which I think most people would agree with. Go is obviously a much easier language than C++. It is hard to find a memory-safe language that is harder to program in unless it is something like Haskell, which is hard because it is foreign to most programmers not because of memory safety per se.
Edit: Maybe Rust is harder to program in than C++, I'm not sure (don't know Rust really). But probably most people who find Rust hard would be writing buggy C++ programs and Rust is preventing them from making bugs that they would otherwise not be aware of.
No, Rust isn’t harder. I just had a wrong understanding of the “memory-safe language” term. Sorry, I thought it’s about guarantees that Rust gives, but looks like the bar (from the official term) is much lower. Sorry for misunderstanding.
Because when I see some image written in Russian alphabet having a little canvas where I can draw those cyrillics and gets recognized automatically and later translated it's a great utility. Like it or not, internet is global and various alphabets do exists.
Personally I disagree with the mix of features / lack of features the OP is going for, but I totally understand the desire to play with some aspect of the browser to make it fit a long-tail use-case. I wish for a composable set of utilities that can be put together into a browser even if they aren't very good.
For instance, I have often wanted to experiment with a CLI browser that had js support. If A platform existed that just allowed me to swap out the renderer with my own thing it would make that dream easier.
I'm curious how far one could get by leveraging jsdom inside of node or quickjs. Clearly the result would be compromised, but if it is even slightly usable, it may fill the needs of the OP and other experimenters.
117 comments
[ 3.4 ms ] story [ 188 ms ] thread> 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.
I got this impression too. I dislike that their solution seems to be nerfing web-browsers in hopes that developers begrudgingly go back to desktop apps instead of buffing the tools used for building desktop apps so that they're what people want to develop.
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.
I don't think it's a good thing, I think it's inefficient and used against people as much as it's used _for_ people. Standards such as "WebUSB" are just incredulous.
The fact that some very smart people managed to get a javascript renderer to go real fast seems to have spawned millions of people just to dump garbage into it constantly, and -require it to be enabled- to do things that used to be possible without it.. it's shockingly bad for accessibility, bad for performance, bad for my ram. But I guess you don't have to worry about _my_ ram.
I'm very sure it's profitable to turn the web into an application platform, and it _is_ delivering a lot of actual value to a lot of people, certain things would never be possible, but it's abused too, and honestly it takes a lot away, privacy among them... but we can't talk about that as an industry because half of the people in it depend on that ecosystem being maintained.
I'm not going to go as far as to say that "the web" is the new oil industry; because we have no oil spill equivalent and we havent gone to war about it (though the e-waste due to inefficiencies and "everyone has 8G of ram, right!?" is likely not helping the ecological situation).
But the industry is propped up because it's too big to fail now, and you're damned if you get in the way.
I guess I'm one of those "duh" people. I think it already is an application platform/delivery system (has been for a long time), and I think that the ever-evolving web is a good thing.
In college, I had professors literally laugh at me when I said I believed most software was moving toward the internet. Fast-forward to today and I'd say that their actual insults against my chosen direction of software engineering (targeting standards-based web solutions) were not only unprofessional - they were entirely not correct.
Reading this document literally felt like I was hearing their arguments as to "what the internet should be" all over again... And, as someone who embraces the internet, I feel so much of this is regressive. Especially in regards to taking shots at stuff like WebRTC...
Your friend and I differ so much in-that they argue against things like communication, graphics, gaming, etc in the browser where-as I have built a career off of embracing it.
> I'm very sure it's profitable to turn the web into an application platform
The web has been an application platform since ECMA landed in Netscape, and arguably long before that too. The anti-application "content presentation only" take has been something for a long time, and it is not going to happen or we'd still be on the original "Hyper Text Markup Language" spec. The web has always wanted to be more than it's previous spec... it's an ever-evolving standard that is designed to meet the changing needs of it's users in an ever-changing world.
Information, capability, and expression all want to be free.
No thanks, I'd like native back.
I worked with a startup that is putting IDE into the web, and I kinda did like web at first. Then I worked at a startup that wanted to run jobs in client browser using WASM instead of cloud compute resources.
At first, I really liked being able to run interpreted code, to change code at runtime without having to recompile, to be able to visit a website and then borrow code for theme/animations I liked. But that is long past now in the vDOM age for performance in what is a very inefficient system.
When I said "information/capability/expression want to be free" it was not inclusive of all of these negative things. And, I find it a direct bad-faith argument to say "well that's what you get when X", given "X" is my statement "information/capability/expression want to be free".
I find your "I'd like native back" statement to be akin to "people abuse stuff so we should just outlaw what they abuse"... Features in tech are going to be pushed toward capitalistic ends because we live in a capitalistic world. Truly - I am the money I make... I am as important as my bank account dictates. My access to healthcare, education, resources, everything dictates this. I live in America - if I am not profitable I literally do not deserve to exist within civil society, and this problem is not exclusive to the US.
"Mandatory accounts, activity trackers, 50% screen ads, background crypto miners, 8gb ram for reading the news and email" - these are more a product of the content of the above paragraph than my claim "information/capability/expression want to be free". My entire life has been about the world trying to milk every dollar it can from some sucker - in every freakin' aspect. I am what I spend.
Until we fix what I am outlining in the above paragraphs, I think every bit of tech is going to be pushed toward hyper-capitalistic purposes because it is literally our culture to worship money above all else. Even services/solutions that should service social means are bastardized for privatized profits - including browsers.
I probably shouldn't be making these arguments here on HN as I find most of us here are so stubborn that we would willingly neuter parts of our computing experience to realizing personal ideals which alienate us from the general population of computer users. Even re-reading this comment makes me feel like some self-aggrandizing prick which I find most of us here are.
There's a lot of bad things about native too, but it is not trying to replace an existing working system while failing the end-users so bad. Neither is my argument to outlaw items that are abused.
> I am the money I make... I am as important as my bank account dictates.
No thanks.
I'm saying you made a bad-faith argument misrepresenting what I was saying when I said "information/capability/expression want to be free" by conflating that phrase/statement with literal anti-user dark patterns that I find are more rooted in capitalistic practices...
Web is quite largely controlled and censored by a handful of corporations - Google, Facebook, Amazon, Microsoft, Twitter.
Even the standards are largely dictated by Google (who ring! ring! also owns the web platform in name of Chrome).
> If by free you mean mandatory accounts, activity trackers, 50% screen ads, background crypto miners, 8gb ram for reading the news and email, abysmal performance for what is essentially displaying text, media and information, literally WASM VMs and background webagents running in browser.
Let me repeat... when you conflate my whole "information, capability, and expression all want to be free" with a ton of negative/gray-pattern stuff you're invalidating my original point in the above comments with what I see as a separate concern, ie: everything has to be built to milk money from people.
Exploitative capitalism/money making dark patterns !== "information, capability, and expression all want to be free"
---
I'm done.
What would make more sense, and be more valuable, would be to talk about what value was actually taken away, and what steps could be done to provide that value again, without taking other bits of value away in the process. The blog post, as it's written, only argues for taking more value away. So I didn't find it convincing towards that end, and it seems you didn't either, as per your GP comment. So I'm pretty confused by this follow up response.
This isn’t directly specifically at you, just this whole thread in general.
(referring to controller/gamepad support)
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.
You surely don't want medical data on the web, right? What could possibly go wrong?
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.
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.
edit: typo
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.
Another option would be feature-enabling plugins, for example a plugin that enables WebRTC developed by some random company. I still don't see how it won't be massively worse than browser security.
But you had the option! Want your computer to the unsafe man-child playgroud? go ahead, install flash. Want something serious for work, don't touch it.
But the advertisement industry had their way and apple and microsoft started to include flash by default. Do you think Google fought flash because they care about you? heh. Google helped kill flash because it gave an edge to microsoft since their ad network at the time was text only and microsoft et al were making bank on swf banners.
anyway, you had the option! it was a plugin, not the browser. Instead of a better plugin, you killed the radio star, took over w3C so that feature for your ad network would be part of the standard.
Now chrome is worse than flash. Features like Federated Learning of Cohorts will be shoved down your throat like or not and it won't even allow you to play web games or something FUN.
very little of this submitted screed touches upon this area, but to me the anti-webassembly remarks feel very close fit to anti-flash remarks. js has gotten bad, but I continue to think eventually we'll see better actors (especially with an arisal of custom elements). webassembly makes me think the web will get anti-web anti-understandable, anti-user as a medium increasingly for the next 50 years probably, most of my remaining life. doing good & being a respectful medium will be just as possible as without webassembly, but there will be so much energy & focus on an industrialized non-user non-acessible non-user-agency dark world shadow-nightmare hell-web because of webhassembly, that will absolutely dominate & be enticing to so so so wide a range of the alpha geeks... while users lose & lose & lose.
flash 2.0 is coming & it will be cheered & celebrated & far far worse for users than the flash we have finally killed.
I was pretty young, but I'm pretty sure I remember opening someone else's swf file in a decompiler in middle school. It was a little weird but I was able to make the changes I wanted.
How editable is WASM code, really?
It's not as much how you can hack around it but more about open-by-default and open-by-design.
Unfortunately, there are very practical performance reasons to send information in a "compiled," less-editable format. Which is why even static sites nowadays typically use some type of build system.
I do wonder if with the 'somewhat standard' min.map files that can point out what the rendered versions relate to in the 'source' versions could somehow be enforced. That way you can still use the compact version first and if you do want to see what's happening you can just get the map and the source and explore.
Wasm code is editable via the very very good dev tools systems we have today, mostly dictated via the Chrome DevTools protocol which even Mozilla largely harkens to & which is being semi-standardized through wicg[1]. Still fairly early days but support is not bad! But... it's a monumentally harder challenge imo than JS. There are source maps, so if the site is nice, you can see what the authored uncompiled code was, but there's no facility to author in that language & recompile your changes via the debugger. And I fear few sites will post the source maps to make webassembly comprehendible. Few sites have morals, ethics, or respect for the web as a medium: they see it as a platform for them alone to dictate to you the user what you get. This, to me, is the sad end Flash had forced upon us, that the web was so much better than.
[1] https://github.com/WICG/devtools-protocol
It wasn't enabled everywhere by default and the majority of sites didn't assume you had it, unless it was something that genuinely needed it (like, habbo hotel, or youtube back in the day) it often never got enabled, meaning people couldn't use it for tracking me, or eating up all my local resources.
That's a freedom we've lost, disabling javascript just breaks everything.
Though webgl continues to be a toggle, though enabled by default.
still: I have some residual sympathies i'd share. for one, I am pretty terrified the webassembly based world will radically increase the un-observabity of the already virtualizing (as in, vdom) web dev world. understanding & working with the web medium we are given has gotten increasingly hard and the webassembly world sounds like an immoral indecypherable wreck for users with all good user agency pummeled away.
but, i would not halt that. the web medium needs great liberties to grow.
but, more so, in strong strong agreeance about "what we should do" that this article sets up, I think features should be flaggable. if someone wants to be a salty crufter, let em. it's the users right to their own experience. no website is obligated to function, to work, so if you disable webgpu, the good stuff just won't work: it's your choice to break maps, & dozens of others. let users turn features off broadly as they might & enable higher powers case by case.
I think the poster is a grizzly salty refusenik, a denialist, which we hear a lot from a lot, way overmuch. these people are ultra vocal. I'm so glad their attitude is condensed into somethong reasonable. and to me: sure, I think they should have their asks. we should give folks the abity to disarm parts of the web platform. to let them have the experience they want. mostly I think these folks are kind of idiots, devuan class reactionaries harking a denialist small minded set of expectations they falsely impose on others. but the web should allow them what they want. it should make turning things off easy. because the web is about user agency. and the cost of letting folks turn capabilities off is almost nothing. they can have their broken bad experiences, when various features are required by a site. maximalize the user, even when they want the web to still be living in a barrel.
Not to mention, Web Crypto API is the literal opposite of roll your own crypto. and is SOO much better than someone implementing cryptographic operations on JS. and can have so many use cases. End to End encryption with key stored in browser. (You can have the raw key inaccessible by JS even, only allow decryption/signing). Though I agree there are some APIs that are pretty dumb.
I'm glad someone is pointing this out as I felt like the author didn't even attempt to understand the Web Crypto API assuming an incorrect worst-case scenario.
Different browsers can be really useful. Personally I do not need want the browser the author suggests at all, but that's just me. Every user is different. I use "links" heavily for reading HTML; it is particularly good for printing HTML tables. I do not expect anyone else to use it. (But some do, including user who actually paid money for features.) A different browser is simply an optional program I choose to make use of. I do not use it for anything financial or otherwise sensitive. There are other browsers for that.
In recent years I frequently see comments that seem hostile to the mere idea of more web browsers. I do not understand this. If this author wants some browser with some certain set of features, that is his business.
"Disagreeing" with someone's desire for a browser with different/less features because of the annoyance of native apps. It make no sense. (Blame the developers of today's "native apps", not users who want alternatives.) AFAICT, there is no suggestion in this blog post of trying to take away anyone's preferred web browser and make them use native apps. The author just wants more options besides the popular ones. A browser with different/fewer features in addition to all the everything-but-the-kitchen-sink, do-everything-under-sun ones written by online advertising-supported organisations.
the techwizardry demands of heavy hitters like YouTube and Facebook have created an "attack surface" that forces active and constantly evolving opt out behavior. the web is actively hostile towards the lay browser (person who browses.) a million notifications to allow and enable things on first visit to a site is a terrible experience. sane defaults should disallow these apis on most popular properties.
furthermore, I personally wouldnt mind a split between the browser and a communicator. a separate webrtc phonelike app that handles all teleconferencing. i get why people dont want a native app installed for each voip solution, but a single tool that is cross compatible, pushed out of the "web browser" would make web browsers safer.
the average person is using a web browser to look at celebrity news, pictures, youtube videos. delivering those things efficiently doesnt need to be much more complicated than the web was 10 years ago. having a separate button to launch "3d game rendering mode" would be preferable to every site on the web abusing the tech behind the scenes to deliver targeted ads.
Heck, default to running code on every site is too much for me and the first thing I turn off. All the fine grained stuff is always I fight to find and remove.
Web apps also provide no degree of trust. You can't know what will be loaded in advance. Native software can allow you to inspect source code and modify it beforehand without resorting to maintaining a web server for self-hosting. Hell, Debian's working on reproducible builds and F-Droid has had it for years, while the web just figured out script verification with SHAs (entirely controlled by the vendor, which misses half the point).
> 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.
Even better: let's try to build a world where people don't have to run proprietary malware, on the web or otherwise.
> 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.
Better idea: have a PDF reader that just opens documents without any scripts or internet connection. muPDF is a good option. Also, don't use random apps (native or web); distro packages are a good start for some trust beyond the vendor.
We've reached the point at which running two web apps cuts down battery life twice as much as me running my desktop, mail client, editor, newsreader, music player, and IRC client combined. The only "native" programs that come close to this level of resource abuse are Java IDEs. Web browsers are so complex that they essentially can't be forked or created anew without hundreds of millions of dollars in annual funding. And with the increasing footprint of web apps, it's no wonder people feel the need to turn their computers into e-waste every N years.
Note also that the author explicitly mentions they are not that concerned with JavaScript performance and would instead prefer a supposed simpler and easier to understand interpreter.
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.
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).
"Can it match and indent parentheses" is pretty much a minimal viability test for any programming editor from the past 40 years.
Apparently people like to make syntax optimized for what they do most frequently. I like C programming, and not having a concise syntax to dereference, index, and access struct members would drive me nuts. Something like foo->bar.baz += quux(42); is not too rare to have to write, but feels very natural to write this way. In Lisp, that would be terrible in comparison.
Sometimes, just sometimes, I try to add some metaprogramming and imagine how nice it would be to code in Lisp, only to realize soon after that I was overthinking it. It's a rare situation that the "special" syntax that is in my preferred language causes friction for what I do. 99% of the time, it is there to support me, to help me read and write code faster.
Numeric calculations are confined to small isolated pieces of code; they do not involve reference and collaboration. In some ways, parenthesized prefix improves the readability of nested expressions by eliminating ambiguity, and n-ary operators like * and + taking multiple arguments can even reduce clutter.
But struct access; it helps that have that convenient.
This is why in TXR Lisp there is a comprehensive referencing dot notation. What's more, there is also a blueprint for how to integrate that into any Lisp.
This is the thing about Lisp; the research is not over.
Here is some example code.
This is a translation of the following function, which is from Simon Tatham's Puzzles. The code to get the font was factored out into a separate function in the above Lisp:SelectObject's return value is a HGDIOBJ whichi s just a void * in disguise. Thus oldfont is just a FFI foreign pointer (cptr). You can do nothing with it other than compare it for equality with NULL and pass it to Win32 functions.
I have simply mirrored the C more or less as-is.
tm is a local variable; again, you just have to look where it is bound:
so you know the type from the lexical scope. This corresponds to the line of C which goes It's exactly the same process. In the C code if I see tm.tmAscent, I look backwards for the declaration of tm, perhaps using the Vim # key. If I see tm.tmAscent in Lisp, I look backwards to see where tm is bound, perhaps using the Vim # key. (new TEXTMETRIC) is exactly as informative as TEXTMETRIC tm;.Any time you see a simple variable being accessed in Lisp code, it is either lexically scoped or global. If you don't see it in the lexical scope, it is the latter.
So that brings us to dstat. Another lexical which is a copy of fe.drawstatus. We can see that fe is a parameter, but what is drawstatus? No fancy IDE is needed; just Vim. Put the cursor on drawstatus, and Ctrl-] chases the tag to the definition, a line in a big struct definition:
fe is an important parameter; it is the self object of the method.I used the pattern matching notation in the above comment to remind myself the values this can hold. The front end objects in Simon Tatham's design have a mode variable which indicates whether printing or ordinary rendering is taking place. If you're printing, you have to do different things with colors and such (possibly using hatched pens on a black-and-white printer, plus scaling of coordinates and whatnot). I just used the three symbols :drawing, :printing and nil.
Popular languages like Javascript and Python have a worse version of this "what is drawstatus" problem, yet are used by legions of programmers in all sorts of successful projects, even large ones. In these languages there is no clear place where object properties are defined, and objects can even be monkey patched with new properties, which I do not allow.
Finding out what is returned by SelectObject is the same: put the cursor on SelectObject, Ctrl-], and it jumps to the FFI definition:
In reading Lisp, there is no panic if we are calling some function, and capturing its return value without that being declared. Firstly, most of the time we shouldn't have to know anyway; if the program is well designed, we shouldn't care about the implementation details. Unless we are specifically looking for a bug in that aspect of the code, we can just trust that it's okay.The trend in modern languages, including statically typed ones, is to have fewer declarations. If the original code here were C++ you could probably do:
I've never grown to like that very much. Being a little bit more verbose, in my mind, only pessimizes (keyboard) typing efficiency - when scripting at full speed, but not to the extent that it would harm when "just" being productive and in the zone.
But the explicitness comes with advantages, one I assume is compilation speed (to an extent), but then also having to fix issues when type resolution is (or becomes, after a change) ambiguous, which requires small local and sometimes not-so-local changes.
Another advantage is ease of caching in a piece of code when bumping around the codebase - which is important even if I was the original author.
Also navigation to the definition of the type is faster/easier if the type is written explicitly, when using bare-bones editors but also in IDEs.
Yes, I know that lisp programmers often structure their programs well, but there is a reason most of the good parts of lisp got incorporated into other languages and yet lisp stayed relatively niche.
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.
a Webapp browser which is full fat and heavy, like an OS with task managers and so on. (this is what Chrome is today)
and a basic web browser for reading news, banking, watching youtube or commenting on forums.
The issue is that we're all forced to always run #1, which leads to developers thinking every site should be a full fat webapp... when webapps should be reserved for actually advanced things like games or google maps.
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.
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.
There, instead of teaching me how to implement my own internet, it gave me a high level overview of networking history and design decisions.
After reading that book I can now keep those constraints in the back of my head when developing web applications.
I would love to read something like that for browsers:
Instead of teaching me how to write a browser in Python (which is cool I guess for a weekend project if one is into that), it would show me a high level history and design decision overview and explain what was difficult and how it was solved, what hacks were necessary, what is still an unsolved problem, etc.
My hope would be that from such a website I could take away key bits of information that I could leverage in daily coding, say „DOM nodes earlier in the document get rendered faster than later in the document because X“ or „display: none is much more costly than opacity 0 because X“ or „XSS attacks will never be able to be 100% solved because X“ or something like that.
I hope my feedback is useful? Good luck anyways!
You know, all the major browsers are, like, tens of millions of lines of code, bigger than (say) the Linux kernel. And unlike the kernel, there's no good overview out there on the basic architecture and the basic concepts, stuff like the layer tree or the task queue or hit testing. It's hard to discuss, say, why one DOM API is slower than another without having those concepts in mind.
So, like, DOM nodes earlier get rendered faster (if the network is real slow and if ...) because they arrive over the network earlier. "display: none" is a lot cheaper because it doesn't produce a layout object, while opacity 0 probably goes all the way to the layer tree. XSS attacks are hard because JS can be embedded into HTML without being demarcated or separated from it. But these explanations presume some understanding of browser networking and the layout tree and the JS environment. For some simple things the "folk understanding" of these things suffices, but the joy of the toy web browser isn't that it's a fun weekend project, it's that each of those concepts is something you can pull up on the screen, read, and then understand as a concrete piece of code.
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.
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.
i'm also appreciative of things like e.g. webcam support and webrtc, since it means i don't have to run proprietary always-on applications on my actual operating system, which don't have to ask permission for anything.
and some are also just weird. favicon svg support? why do you care if favicons support one additional image format? should we get rid of jpg as well? maybe only use bmp for everything, then we can simplify things further and not have to include any complicated decoders in the browser
Edit: Maybe Rust is harder to program in than C++, I'm not sure (don't know Rust really). But probably most people who find Rust hard would be writing buggy C++ programs and Rust is preventing them from making bugs that they would otherwise not be aware of.
Is demonstrably untrue:
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
Because when I see some image written in Russian alphabet having a little canvas where I can draw those cyrillics and gets recognized automatically and later translated it's a great utility. Like it or not, internet is global and various alphabets do exists.
For instance, I have often wanted to experiment with a CLI browser that had js support. If A platform existed that just allowed me to swap out the renderer with my own thing it would make that dream easier.
I'm curious how far one could get by leveraging jsdom inside of node or quickjs. Clearly the result would be compromised, but if it is even slightly usable, it may fill the needs of the OP and other experimenters.
You can usually globaly turn it off and it's way less spammy than "Download our mobile app if you want to see the rest."