The web browser I'm dreaming of
dustri.org
dustri.org
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.
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.
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.
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)
> 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.
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.
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.
There are so many important and even crucial documents, that would become unavailable. E.g., if you are interested in computer history, you know what I mean. About every document that isn't just copy-and-paste content is behind a http-only browser warning and written in a standard that dosen't comply with html5. The premise that everybody would be able to republish the content is somewhat mistaken. What's the way around this? A common effort to preserve these documents, maybe by an automatic translation layer? Well, this is quirks mode…
PS: Now one could suggest to have special browsers for legacy content. But, how would this work out with any links? You were to break the principal premise of the Web by introducing a fundamental schism. Now there are two kind of webs, and you'd probably need two kind of links.
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.
Doubly so when one wish is written in a language I know.
Triply so when he doesn't want so many features. It doesn't take "millions" to write a browser that doesn't have all that functionality. Look at the SerenityOS project for just one example.
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.
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
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.
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.
(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)))
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;
fe->fonts = sresize(fe->fonts, fe->fontsize, struct font);
}
fe->nfonts++;
fe->fonts[i].type = fonttype;
fe->fonts[i].size = fontsize;
memset (&lf, 0, sizeof(LOGFONT));
lf.lfHeight = -fontsize;
lf.lfWeight = (fe->drawstatus == PRINTING ? 0 : FW_BOLD);
lf.lfCharSet = DEFAULT_CHARSET;
lf.lfOutPrecision = OUT_DEFAULT_PRECIS;
lf.lfClipPrecision = CLIP_DEFAULT_PRECIS;
lf.lfQuality = DEFAULT_QUALITY;
lf.lfPitchAndFamily = (fonttype == FONT_FIXED ?
FIXED_PITCH | FF_DONTCARE :
VARIABLE_PITCH | FF_SWISS);
fe->fonts[i].font = CreateFontIndirect(&lf);
}
/*
* Position and draw the text.
*/
{
HFONT oldfont;
TEXTMETRIC tm;
SIZE size;
WCHAR wText[256];
MultiByteToWideChar (CP_UTF8, 0, text, -1, wText, 256);
oldfont = SelectObject(fe->hdc, fe->fonts[i].font);
if (GetTextMetrics(fe->hdc, &tm)) {
if (align & ALIGN_VCENTRE)
xy.y -= (tm.tmAscent+tm.tmDescent)/2;
else
xy.y -= tm.tmAscent;
}
if (GetTextExtentPoint32W(fe->hdc, wText, wcslen(wText), &size))
{
if (align & ALIGN_HCENTRE)
xy.x -= size.cx / 2;
else if (align & ALIGN_HRIGHT)
xy.x -= size.cx;
}
SetBkMode(fe->hdc, TRANSPARENT);
win_text_colour(fe, colour);
ExtTextOutW(fe->hdc, xy.x, xy.y, 0, NULL, wText, wcslen(wText), NULL);
SelectObject(fe->hdc, oldfont);
}
}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))
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:
(defstruct win-frontend win-drawing
// ...
drawstatus ;; @(or :drawing :printing nil)
// ...
)
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:
(deffi SelectObject "SelectObject" HGDIOBJ (HDC HGDIOBJ))
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:
auto oldfont = SelectObject(...);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.
Like some things I can disable in FF in about:config, but others I can not. Otherwise, I have to modify and compile FF and hope I don't break any extensions I use.
A similar thing would also be nice for HTML elements.
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.
It's not intended as a language to use directly, but rather as a compiler target - allowing for the use of modern languages in a tightly sandboxed environment.
It has huge potential - it's not unreasonable to imagine a future where pages of media content incorporate their own codecs for any image, audio and video formats.
One thing that's an issue in that regard is trust, but there's an issue for that: https://github.com/WebAssembly/design/issues/1413.
I have strongly mixed feelings about that, FWIW.
The modern hardware also masks the performance issues of the typical mountain of Javascript webapp. The fact that most webapps require an "evergreen" browser just makes this worse.
I'd like to see a scaled back browser, perhaps implementing the 90-95% use-case of apis actually in popular use.
In-browser screenshot tool is useful since it allows you to take a screenshot when scrolling, that is when a part bigger than the displayed page is required. Also it can screenshot a specific element. Not sure what tool the author is using but none I've tried allowed to do this.
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.
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=...
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.
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."
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.