Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're building a browser when it's supposed to be impossible

awesomekling.substack.com

Post reply on HN
Print view View original

321–330 of 349 posts

Re: We're building a browser when it's supposed to be impossible

#321

Post by favorited »

alex_lav wrote: post #296
Mavvie wrote: post #294

Earlier quoted context omitted.

I don't think that link supports your comment. It says that vertical slices (at least as described by that article) are generally unrealistic in game dev.

You're right! I skimmed the first paragraph, as I was mostly just looking for a description of vertical slices in games. The rest of the content does not in fact validate my statement.

You're right that the "vertical slice" approach has been used very successfully in games development, though. Mark Cerny[0] has been evangelizing[1] the idea that preproduction isn't over until you have a "publishable first playable" (a.k.a., a complete vertical slice) of your game.

Basically, you shouldn't switch from "preproduction" to "production" until you can show (A) here is actual gameplay, (B) it is, in fact, fun, and (C) you know how to actually implement it. Until you can demonstrate those things, how are you supposed to estimate how long it will take to build? Or that, once you're done, whatever gameplay mechanics you dreamed up are actually entertaining to a player?

[0] arcade game programmer, producer / studio exec who got Insomniac and Naughty Dog to scale beyond their founders, & eventual lead architect of the PS4 and PS5

[1] https://www.slideshare.net/holtt/cerny-method, https://www.youtube.com/watch?v=QOAW9ioWAvE

Re: We're building a browser when it's supposed to be impossible

#322

Post by still_grokking »

r3trohack3r wrote: post #275
selfhoster11 wrote: post #246

Earlier quoted context omitted.

Literally, Java. If we spent all the effort we used up on making JavaScript work on Java instead, I’d be typing this from my Moon habitat. But we instead chose a pig, buried it under layers of lipstick, and strapped a jet engine onto it. Sure, it’s airworthy, but was it the best way to allocate resources?

I wouldn't say we chose a pig and buried it under layers of lipstick. I think it's more accurate to say people realized: 1) You could deliver software via a browser with some clever hacking 2) That delivering software via a browser had some extremely attractive properties compared to other approaches Those clever hacks turned into real applications and those became real products. As people built applications on top o…

I guess you missed Java Applets and Java WebStart…

The web browser is still the most terrible "application platform" as it's at its core still a document viewer, and not an application platform at all.

The pic with a lot of lipstick analogy is pretty to the spot, imho.

You can abuse any Turing-complete environment any way you like. But this doesn't make it a good idea in the first place.

Re: We're building a browser when it's supposed to be impossible

#323

Post by still_grokking »

andrekandre wrote: post #214
Brian_K_White wrote: post #121

Earlier quoted context omitted.

"Google Docs used to be contenteditable based, but moved to a custom rendering engine." Is THAT why you can't cut & paste with the mouse in google docs like you can on every other site? Take me back to the old way then please.

yep, the use canvas to render everything now https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

I didn't know that. Very interesting!

Isn't this actually prove that creating desktop grate applications, like a graphical word processor form the late 90's & some colab backend, is still infeasible with web tech?

Doesn't it also prove that it's still easier and faster to create a proper app and GUI toolkit yourself and just render pixels to the screen (as all desktop GUI toolkits do these days) instead of fighting the browser tech idiosyncrasies, even a proper app and GUI stack isn't trivial in itself?

Re: We're building a browser when it's supposed to be impossible

#324

Post by [deleted] »

yodsanklai wrote: post #225
cubefox wrote: post #224

This post doesn't give reasons to doubt that building a new state of the art browser is basically impossible now. It might well be possible to build a new browser that kind of works on many popular websites, and that would be surprising enough. But the amount of work needed to build something comparative to the rendering engines of Chrome, Firefox, or Safari, something really usable, would probably take decades rathe…

Is all the complexity of a browser in the rendering engine? can a browser be split into several components so that they can be rewritten concurrently?

[deleted]

Re: We're building a browser when it's supposed to be impossible

#325

Post by zzo38computer »

nicoburns wrote: post #102

I've been working on CSS Layout as a library recently[0] (we have Flexbox and CSS Grid support so far). It seems to me that librifying everything (much like is already done with JS engines) could be a good approach to making building a new browser engine more accesible. Because that way any one wanting to build a new one can starting by pulling in a bunch of libraries (layout, rendering, etc), and then just customise…

> It seems to me that librifying everything (much like is already done with JS engines) could be a good approach to making building a new browser engine more accesible. ... Because that way any one wanting to build a new one can starting by pulling in a bunch of libraries (layout, rendering, etc), and then just customise the bits they need (ideally publishing them as a new iteroperable library that others can also use).

I think that you are right; this is what will be needed. However, that alone won't do because it is also needing to write them to be good, and not too slow/inefficient and not too incapable of doing many customization stuff.

And, ensure things are properly separated. (Looking at your examples, it seems like it is properly separated, to me. You can define styles independently of parsing them, which improves efficiency as well as allowing adding other steps in between such as "meta-CSS" if desirable.)

In some cases, it may be desirable to modify parts of the libraries, although then it may be necessary to maintain a fork of that library, which is not always desirable.

(For example, I may want to add proper support for non-Unicode text, and being able to customize text layout functions, including all possible text directions (vertical, horizontal, boustrophedon, etc). Adding other CSS rules might also be needed for some other purposes, too. And then, we will also need to do accessibility features.)

(I like to use C programming; looking in issues, it look like they might be added, so that can be good; unfortunately, Rust has a Unicode string type and this can be problematic even if using C, unless the Rust programming is done very carefully to avoid this problem.)

Re: We're building a browser when it's supposed to be impossible

#326

Post by r3trohack3r »

still_grokking wrote: post #322
r3trohack3r wrote: post #275

Earlier quoted context omitted.

I wouldn't say we chose a pig and buried it under layers of lipstick. I think it's more accurate to say people realized: 1) You could deliver software via a browser with some clever hacking 2) That delivering software via a browser had some extremely attractive properties compared to other approaches Those clever hacks turned into real applications and those became real products. As people built applications on top o…

I guess you missed Java Applets and Java WebStart… The web browser is still the most terrible "application platform" as it's at its core still a document viewer, and not an application platform at all. The pic with a lot of lipstick analogy is pretty to the spot, imho. You can abuse any Turing-complete environment any way you like. But this doesn't make it a good idea in the first place.

I didn't miss them - I don't have fond memories of them as either a user or a developer. But you're right, they were there. Which is interesting: Java Applets were available from close to day one right along side JavaScript, and yet...

There are two use cases for the web. There is the document web and the application web. Both are equally valid. It is absolutely an application platform, as evidence by the fact people use it to deliver applications. An ever increasing percentage of desktop software is moving to the browser, to the point where many users only need a web browser. I'd argue the only reason mobile hasn't followed suite is the non-market forces behind the app store model.

It is one of the best application platforms for both users and developers. I can write my software exactly one time and it will run on every platform, instead of separate applications for Android, iOS, Mac, Windows, FreeBSD, Linux, etc. etc.

I can assume my users have a web browser - because they do. For interpreted languages (and VMs) I either have to walk my users through setting up the interpreter or bundle it into the distributable.

Compared to everything else I've worked with, the web as an application delivery platform is great. I write my code, send someone a link, and they are running my app.

Re: We're building a browser when it's supposed to be impossible

#327

Post by andrekandre »

still_grokking wrote: post #323
andrekandre wrote: post #214

Earlier quoted context omitted.

yep, the use canvas to render everything now https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

I didn't know that. Very interesting! Isn't this actually prove that creating desktop grate applications, like a graphical word processor form the late 90's & some colab backend, is still infeasible with web tech? Doesn't it also prove that it's still easier and faster to create a proper app and GUI toolkit yourself and just render pixels to the screen (as all desktop GUI toolkits do these days) instead of fighting t…

  > Doesn't it also prove that it's still easier and faster to create a proper app and GUI toolkit yourself and just render pixels to the screen (as all desktop GUI toolkits do these days) instead of fighting the browser tech idiosyncrasies, even a proper app and GUI stack isn't trivial in itself?
jmo, but i think so as well....

tho i wonder what the performance/battery-life implications of everything doing that might be... perhaps you could have an 'libhtml' for static sites and documents, and different ones for more interactive apps etc

Re: We're building a browser when it's supposed to be impossible

#328

Post by alex_lav »

favorited wrote: post #321
alex_lav wrote: post #296

Earlier quoted context omitted.

You're right! I skimmed the first paragraph, as I was mostly just looking for a description of vertical slices in games. The rest of the content does not in fact validate my statement.

You're right that the "vertical slice" approach has been used very successfully in games development, though. Mark Cerny[0] has been evangelizing[1] the idea that preproduction isn't over until you have a "publishable first playable" (a.k.a., a complete vertical slice) of your game. Basically, you shouldn't switch from "preproduction" to "production" until you can show (A) here is actual gameplay, (B) it is, in fact,…

> You're right that the "vertical slice" approach has been used very successfully in games development, though.

Oh I know, I worked in game development for years :). Was really just trying to get a short description.

Re: We're building a browser when it's supposed to be impossible

#329

Post by silisili »

Asraelite wrote: post #317
EVa5I7bHFq9mnYK wrote: post #208

Earlier quoted context omitted.

Mozilla Windows binaries weight 226MB ... does it mean encoding rate of 2 bytes per word of specifications? Pretty good packing, I'd say.

I'm not surprised, it usually takes many words of English to describe very little code. For example, changing "greater than" to "greater than or equal to" might require only a single bit of change in the machine code.

I think the opposite. Sure, in your example that is true, but that's assuming we speak to the code line by line, in English.

But we don't, really. Example:

Write a function that keeps track of the name and weight of each person added, then prints the list, sorted by weight, lightest to heaviest.

I asked GPT this. My 140 character, unoptimized query resulted in 816 characters of c++ code.

Re: We're building a browser when it's supposed to be impossible

#330

Post by account42 »

Waterluvian wrote: post #238
yellowapple wrote: post #53

> So instead of [building the browser one feature/spec at a time], we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives. Seems similar to how Wine is developed: instead of just going down the list of API functions to implement, the…

I really like this approach because it’s a low-effort way to prioritize development. I did this with the CPU for my GameBoy emulator: I picked a game I wanted to work and just kept implementing opcodes each time it crashed with an “opcode not implemented” error.

It's also a great approach to port games - replace all platform-specific code with assert(false) until it compiles and then fix the asserts as you encounter them until everything works.
Post reply on HN