Why browsers are bloated

https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/Scrollbar.cpp
https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/win/ScrollbarThemeWin.cpp
Let's reinvent the fucking scrollbar, which every goddamn platform with a UI already has, and make it behave subtly different from the native one!

Right-click a native scrollbar in some other app:
- Scroll Here
- Top
- Bottom
- Page Up
- Page Down
- Scroll Up
- Scroll Down

Right-click a scrollbar in Chrome:
- Back
- Forward
- Reload
- Save As...
...

Right-click a scrollbar in Firefox and Opera:
Absolutely fucking nothing happens!

What the fuck!? How did these terminally retarded idiots get involved in creating one of the most important pieces of software to the average user?

This state diagram is becoming rather hairy... but it looks like all that's really needed are identifiers, numbers, strings, and operators. That brings it more in line with the complexity of a C tokeniser, which isn't so bad, but looking at the spec you wouldn't think that.

>>600
This. >>599, if you'd only read the rest of the thread you'd realise that this is not about reinventing every bloody thing, but figuring out how to more efficiently make use of existing infrastructure. Systems don't exist in a void. No one will care about a new Web that almost no one can access.

ｄｅｌ

>>601
We would still be making programs for Windows Me in Sepples if everyone had this retarded mentality of yours.

No one will care about a new Web that almost no one can access.

No one will care about a browser that almost no one uses.

>>603
It's still greater than the number of people that would use a browser for some newly made up protocol no one uses.

>>604
Yes, 1 is greater than 0.

>>603
Use my anus.

http://mxr.mozilla.org/firefox/search?string=kungfudeathgrip

>>603
And what's wrong with that? You're the retard here.

>>607
Reference counting is almost always just another way to say "I'm too stupid/busy/wasted to figure out when something should be freed"...

Honestly, I'd use Cudder's browser. But waiting for it is like waiting for Jesus to return.

+1

>>609
exactly

ｄｅｌ

Honestly, I'd use Cudder's anus. But waiting for it is like waiting for Anonix to be written.

>>613
use my anus

This thread is too old. You can't reply anymore!

>>614
stalking, bullying, seemingly innocent microaggression...
how does it feel being such a shitlord?
srsly how do we fix the internet¿

>>616

srsly how do we fix the internet¿

By implementing net neutrality.

ｄｅｌ

>>599

You fuckers should stop wasting so much energy on ``improving'' the HTML/CSS shit and create something half-reasonable instead.

Something reasonable would be gopher.
But you can't use it to access the web as we know it, so it's useless.

We should instead at least have a reasonable implementation of the shitty standard so we can access services that use it with secure software.

Unless Google starts marketing and pushing gopher as the new thing, we are lost with HTML/CSS/etc. And I would like to have a proper browser to access the world wide web: Cudder's browser.

Too bad it's all a wet dream, since we know Cudder won't deliver.

sage

ｄｅｌ

You can whine all you want but I haven't seen anyone else in this thread claim to have written any significant parts of a browser either, nor thrown out some ideas... I already have most of an HTML parser done, and moved onto a CSS tokeniser now.

After that it will be CSS matching and the renderer, and then more UI stuff (settings, etc.) Then it may be ready to release.

It's a fun thing to see that when using Asm, you're not forced into the dogma that a program must be composed of functions (or objects). You can jump anywhere, and manipulate the stack to "call" or "return" to the appropriate place. With this the CSS parser becomes so much simpler, much like the HTML one did. The main state machine doesn't even need to check for and handle EOF explicitly - it's getchar() which does, and on EOF it jumps to the right handler based on the return address.

Fuck Dijkstra. He got it all wrong. gotos are the way to go.

>>622
Cuddler

Browsers that treat locally-added CA certs equivalent to builtin ones are complicit in malicious AV and firewall products' attacks on users.

What will be this browser's policy on HTTP referers?
It's an absurd that websites know which website you were browsing before going to their page.

>>624
If they were treated differently it would take control away from the user. Those who give up freedom for security deserve neither.

>>625
On, domain-exact (e.g. example.com->example.com will send, example.com->foo.example.com won't, and neither will foo.example.com->example.com), deeper-or-same (allows example.com->foo.example.com but not the other way around), off. Configurable globally and for each domain.

>>625
Always copy paste the link. Never click on it.

Webkit has many tools to deal with fingerprinting.
https://trac.webkit.org/wiki/Fingerprinting

How will your browser engine deal with this?
Also, what's left until you make the current progress public?

ｄｅｌ

>>628
The majority of that page has to do with JS, which means it is completely irrelevant to my browser at the moment: it doesn't have JS yet, and I don't plan to think about the details of it anytime soon. JS features will likely be configurable on a per-site basis.

CSS media queries - this is CSS3, so it is basically ignored.
CSS fonts - needs JavaScript to work, so irrelevant.
CSS visited - user-configurable per-site, and I'm probably going to indicate visited/not-visited some other way through the UI anyway (e.g. status bar indication) so it's no big loss.
Plugins - user-configurable per-site.

User-Agent: your choice. Set it to whatever you want, or don't send one at all.
ETag tracking: not supported at all because there is currently no plans to do any caching.
"Do not track" header: useless bureaucracy bullshit. You draw more attention using it than not.

TLS/SSL Session IDs: irrelevant network layer concern, and depends what is doing SSL/TLS. The proxy I currently run everything through does not support session resumption at all.

Also, if I'm not posting any updates, then assume nothing has happened.

>>630

Also, if I'm not posting any updates, then assume nothing has happened.

Okay, that's reasonable.
But what is the mile-stone you want to reach before releasing it in the public domain? Why not release what you have so far right now, so we can start playing with it early on?

>>631

But what is the mile-stone you want to reach before releasing it in the public domain?

Acid2 pass. I've mentioned this before, read the threads - especially the one on dis.4chan which was where this whole thing started. ("Low resource web browser")

Currently none of the lightweight browsers, i.e. Dillo, NetSurf, etc. have been known to pass Acid2. Thus, there is no point in releasing something that can't even match existing lightweight browsers in terms of rendering support. I'm not aiming at the links/w3m crowd with a text-based one. It has to be at least NetSurf/Dillo level, maybe even better than IE6, for it to be interesting.

Why not release what you have so far right now, so we can start playing with it early on?

There is nothing much to play with. At the moment, it is only an HTML parser and a very incomplete CSS parser. The only thing it has in terms of UI is a crude DOM viewer you can see in http://bbs.progrider.org/prog/read/1406427616/123 .

http://bbs.progrider.org/prog/read/1434199339/13

I'm still bloody busy so don't expect anything to happen for the next 2-3 weeks...

>>1

webkit is not so bad, i was trying to load a very big HTML file recently, google chrome used 40 megs of RAM, firefox about 150 MB, and internet explorer about 200 megs.

anyway, what are you expecting, the web is a fucking clusterfuck and it doesnt help that browsers are written in sepples.

>>633
Define "very big". It can't have been over 1MB and I assume your RAM usage is the expansion and not the base because Chrome definitely takes more than 40MB just showing a blank page.

I don't know man, call me a dreamer, but something inside me tells me one day Cudder will surprise us.

>>634
big enough that it hurts when I walk the day after

>>632
Whom are you quoting?

Best associative data structure for element attributes and CSS properties? There's only a few hundred of the standard ones in total, but they'll be retrieved very often, especially the CSS ones.

Hash tables and fixed arrays are the fastest but most memory-bloating, trees are sort of in the middle, and resizeable arrays and linked lists are O(n) (probably n < 10 for elements and < 100 for CSS most of the time) but smallest.

More disturbingly: Why doesn't there seem to be any information on the time complexities of various operations like attribute lookup in existing browsers!?

>>638
Nobody cares to take the time to measure it. So what's stopping you from downloading the source and running your own measurements?

>>638
Because it's a document scripting language not something to write an OS in. If it's too bloated, crash the browser and no one will care.