Why browsers are bloated [Part 2]

Cudder is all talk and no action!

*burp*

>>361
broke: *burp*
woke: *brap*

>>250
Oh better still is https://dis.4ct.org/prog/ which has no shitposts on there threads.

bumping this thread so it doesn't get locked

>>364
Cudder is all talk and no action!

I am all dubs

I have been ridiculously busy with so many other projects I didn't realise it was another year already...

but I haven't forgotten this one --- just haven't had the time to do anything with it. What's left is mainly CSS processing and rendering.

>>367
what about javashit interpreter? no browser would be really complete without it

>>368
wrong

Why browsers are "bloated and sluggish by design", is a myth, and just plain wrong. I just wanted to give you this example, especially because this topic has been discussed quite a bit on this board.
The only reason I mention it is because if you look closely, most of the things that are said about modern browsers are actually true. As a consequence, I am not entirely surprised to see people on the forums complaining about this in terms of performance issues but I think it would be easier if we focused less (or even just less) on browser performance than on other aspects such as compatibility, security and usability.

We have a few reasons to use a web browser but I would argue that browser performance and compatibility are both far more important than just speed. As it is, most of the browsers out there have performance problems, some of them far deeper than others. However, browsers are always improving and when we see an improvement in browser performance we tend to applaud it as being significant.
WebGL is becoming a serious contender for high-performance video, and it doesn't get any faster that using direct hardware calls.
With that said, let's look at some of the major browsers and see what they are doing to improve performance and performance scalability (or in my case I mean performance of all their parts in comparison to each other).


Firefox : Firefox has an awesome WebGL implementation , allowing us to render any scene using WebGL with the ease of an app in modern browsers and it seems to go a bit faster overall, with less rendering overhead than Chrome. However, performance is still not perfect, and I think I'll stick to Firefox as my default browser for future web video work since it's a bit more mature.

Chrome : Chrome has a ton of WebGL support and it is very easy to see what the performance is about on various devices and the WebGL implementation works really well with some of these devices (a tablet works fine on me). It's not even as good as Firefox for video work yet - but I think that will change.

Safari : As a browser with some nice WebGL support, Safari has a very decent performance on a modern phone, laptop or web browser, but performance is not great when working with 4k at a higher resolution. The good news is that WebGL support is quite open.

Edge: Edge is the most basic WebGL browser and the reason for this is that Chrome and Safari both have their own open WebGL driver, Open GL, built in. There is also a newer version of Edge with support for WebGL but even so, it's still far behind Firefox.

>>370
Nobody cares about webgl.
Also, another new API makes browser more bloated, not less.

>>371
WebGL is the most powerful platform for online gaming since it is the most widely available and most scalable, enabling gamers to enjoy stunning gaming experiences on virtually every device available directly through the web.

While legacy platforms such as Windows or MacOS may provide a basic infrastructure, games may require further modifications at runtime to enable the full power of the OS.
To support this, a full-featured cross-platform game engine is required.

Game engines may be written for either hardware or software platforms, with the latter having great advantage due to the ease of portability that allows developers to leverage over legacy platforms in order to achieve faster performance, smoother frame rates, support for advanced video modes and new features.

On a larger scale, the cost advantage of using a cross-platform engine is that developers no longer need to rely so heavily on the CPU for their game development cycle and can afford to use a low-end hardware to get a playable game in under the cost of a high-end machine.

An obvious advantage for the developer is that they still be able to target a younger audience with a higher quality experience, especially from a financial perspective.

>>367
Remember, Acid2 pass --- no JS required.

>>370,372
Spoken like a true shill manageretard. Fuck off with that bullshit.

WebGL leverages the powerful DOM-based canvas to provide simple interactions between elements in a web context (like a web page or screen), allowing for powerful ersatz applications with minimal effort.
WebGL is especially well suited for game development since a huge majority of users today (especially the mobile market) don't know the difference between a canvas and a native renderer in their browsers or games.

>>373
I thought the point of the browser was to browse the internet, no to pass outdated tests

>>375
It's literally the same thing if you been browsing with lynx

This weekend I'll unironically change my sight to be compliant with the cudder browser.
I've just read http://harmful.cat-v.org/software/xml/s-exp_vs_XML lol.

I really enjoy webgl and webcl because mining bitcoins is what I use my browser for.

>>377
After making the changes I realized that nobody will ever give a shit.
I'm wasting my life on something irrelevant.

At least I got this insight.

bump

>>5

fork of libcurl

Why

-why browsers are bloated
-browsers are overengineered, and standardly so, as a means of monopolizing, by setting the cost of reimplementation too high

I had a little more time to work on this recently. Mostly doing some UI stuff so it is starting to look a lot like a browser.

Adding NPAPI support is actually easier than I thought - you just create a plugin instance, give it a window to draw into and feed it data, it will take care of itself. I'll do that so you can use any plugins including Flash. Installing and enabling them on the pages you trust is your responsibility. I give you freedom. Fuckings to the authoritarian "security" dipshits who are ruining the Internet.

bump

>>383

Why implement the plugin API? It's dead, mostly replaced by better standards.

Is this a minimal browser project, or just some weird boner for 2000s web technology with all its flaws intact?

>>385
Why not? It's simple and allows viewing content that would otherwise be inaccessible from a more "modern" browser. Who gets to decide what's "better"?

The browser will be minimal but extensible.

Currently working on cleaning up/shrinking the HTML parser and fitting it into the rest of the "shell" of a UI that I have already, which only displays text and images so far. The HTML parser had its own GUI before, now it will actually go into something that looks more like a browser, althoug I really want to keep the DOM inspector. I may take the crude renderer with it too, just for lulz.

Also, 386GET! I do actually have a 386DX-33 with Win95 and a Tolkien Ring NIC to try it on once I'm done...

How do you handle TLS?

>>386
Why not Activex?

>>388
Why not MentifeX?

>>389

Why not MentifeX?

https://groups.google.com/d/msg/comp.lang.forth/XQTvkclN0L0/yYHXzR0IX1oJ

https://groups.google.com/d/msg/comp.lang.forth/XSH1PWcQZUo/0bf8XPNzjhIJ

https://groups.google.com/d/msg/comp.lang.forth/MvTk_2odVok/BM2byt2YViEJ

https://groups.google.com/d/msg/comp.lang.forth/UVvDS0zZVdk/csTKfrKiI1YJ

>>387
By using the OS's libraries.

>>388
I actually considered that, but ActiveX is COM-based bloatshit while NPAPI is much simpler.

Forget it, writing a web browser is a million man-year job.

>>392
see >>382

Did most of >>386 and the binary doubled in size from 24K to 48K... most of it is the HTML parser that's still in unoptimised C and far too close to being literal to the incredibly bloaty spec (https://html.spec.whatwg.org/multipage/parsing.html) --- but nonetheless far ahead of previous "lightweight" browsers like NetSurf.

Since fitting a CSS parser and DOM renderer in 16K is probably going to be impossible, I still need to shrink the parsee a bit.

>>394
Use Rust

>>395
DO NOT WANT

https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html

Something is seriously retarded when Hello World with the defaults is bigger than the whole distribution of MS-DOS 2.0, and only with an insane amount of work can it be gotten down to slightly below 5KB --- when this is what can be done in only 4KB: https://www.youtube.com/watch?v=9l8a4M4afLk

>>396
mados2 is even more ancient that the DO NOT WANT meme. What is your point?

>>396

I'm not even a Rust programmer but this was hardly any work at all to set up. You basically add the libc crate and implement a

panic_handler

since you're not using the Rust runtime. The binary is 6128 bytes

$ cargo build --release && strip target/release/print
Finished release [optimized] target(s) in 0.06s
$ ll target/release/print
-rwxrwxrwx 2 anus anus 6128 May 2 21:53 target/release/print*

Meanwhile, let's see how C is doing. Oh, too bad

$ gcc -Os hello.c -o hello && strip hello
$ ll ./hello
-rwxrwxrwx 1 anus anus 6312 May 2 22:02 ./hello*


Something is seriously retarded when gcc's Hello World optimized for size is bigger than the whole distribution of MS-DOS 0.02, etc etc.

(setcdr status '(fuqin told))

>>398
C:\Documents and Settings\konata\Desktop\test>clx hello.c
C:\Documents and Settings\konata\Desktop\test>dir hello.exe
Volume in drive C is FS390-105
Volume Serial Number is DEAD-BEEF

Directory of C:\Documents and Settings\konata\Desktop\test

2020-05-03 09:03 1,536 hello.exe
1 File(s) 1,536 bytes
0 Dir(s) 61,918,518,249,984 bytes free