Why browsers are bloated [Part 2]

Cudder is all talk and no action!

My cousin met Cudder at a party in London last year. They ended up fucking. He said it was totally sub-par. She got shit all over his dick, and violently queefed at the end.

Is the roadmap the same since last time?
http://bbs.progrider.org/prog/read/1406427616/740

JACKSON 5 GET

Why browsers are bloated
740 Name: Cudder !cXCudderUE : 2016-02-09 03:39
>>739
Done:
- int main(int, char**)
- fork of libcurl
- email alerts whenever someone posts /Cudder/gi

In progress:
- HTML tokeniser
- HTML parser
- DOM tree
- CSS tokeniser
- CSS parser
- CSS box generation
- layout

Planned:
- Network
- Rendering UI/any graphics at all
- Configurator

The original thread wasn't started by, nor about, Cudder at all. He hijacked it.

WTF, 1000 post limit? This is a programming board. 1023 or 1024 would make more sense.

>>7
Not even 1000, but 1001.
Off-by-one error?

i have come to take away your meme's

check 'em

THEY'RE AFTER ME MEMES

>>11
Nice dubz bro! xD

I have come to take your lucky dubs. Give them up at once.

the problem is random snippets of Python sometimes don't work because where they were pasted didn't preserve the whitespace correctly – MkV Oct 31 '10 at 15:38

The main issue is java/ecma script on the "www DOM" (Document Object Model):
Between noscript www browser code requirements and script-able www browser code
requirements, there is an abyss in size and complexity.

Additionnaly, the "modern" www tends to force the user to have a script-able
www browser, even though many www sites could provide their services with a
noscript www browser through a cleverly crafted main www portal or a dedicated
noscript www portal on the side of the main (with all bells and whistles) www
portal.
----------------------------------------------------------------------------
^
|
That's where the real fight is

For instance, youtube could provide a noscript www portal with <video> and/or
<audio> html elements. EZ and reasonable to implement even for inexperienced
coders around the globe. But no. You _must_ have a script-able www browser to
enjoy youtube (the terms of use even forbid users to employ anything else in
order to watch/listen to a video/audio stream). I have to admit, html needs a
little extension to <video>/<audio> in order to support split video/audio
streams. Basically, we would need a simple html-ed "DASH" manifest. But
vp[98]/opus high/med/low qualities video/audio combined streams should be
enough in most cases. (remainging cases would be handled with the standard
"download then view" way).

Another example: online banking. http, xhtml1.1 and css2.1 with basic forms are
hell enough to provide banking services to www users. But no. You _must_ have a
script-able www browser. And lately, it does apply to "verified by visa" and
online payments...

Sometimes, it does not work. For instance, soundcloud. Soundcloud needs a rich
GUI to provide its services. But they could provide a simple http API to let
people have their own GUI components. Many www sites have their www APIs, but
need a redirection on a script-able www browser on the side for authentication...
Ooops!

----

You have only 2.5 modern open source engines which "can run the www":
- webkit (massive and c++ is brain damaged)
- blink (webkit google's fork, see above)
- gecko (firefox, massive and c++ is brain damaged)

BTW, I wonder if there is a http/mime way for a www browser to tell a http server:
"noscript please".

----

There is a team working on a C implemented www browser: netsurf. I got a little
chat with one of its devs: "www DOM dynamicity through script is insane".

CSS matching: the best way to do this might be a two-dimensional regex-like state machine, which simplifies to an array and a queue of bits. One dimension for matching descendant and child combinators, and then another dimension for general sibling and previous-sibling. As far as I know, this is not something any other browser engine has discovered, although there's some mention of it elsewhere:

http://stackoverflow.com/questions/4656975/use-css-selectors-to-collect-html-elements-from-a-streaming-parser-e-g-sax-str/4752067

If there's 32 (64 for the 64-bit version) or fewer width/height combinators, which is very likely, we can store the state array entirely in a register and get even more efficient... but even the basic implementation should beat the backtracking (:facepalm:) that contemporary implementations do.

https://swtch.com/~rsc/regexp/regexp1.html

There is a team working on a C implemented www browser: netsurf.

It works and is "lightweight" compared to the big ones but, could be much better... https://bbs.progrider.org/prog/read/1406427616/549-556

>>13
You wouldn't know what to do with a dubs even if it was right in your face.

>>16
I find it really disappointing that something like NetSurf, which is both unusable and insecure, but also relatively well-written and infinitely far from "bloated," could get this kind of nitpicking, dismissive review.

The real problems with NetSurf:
1. It has no sandbox <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810491>
2. It's broken on most real web sites

The fact that it is not written in assembly is not the real problem.

https://medium.com/@jitbit/target-blank-the-most-underestimated-vulnerability-ever-96e328301f4c#.cr1dysvnj

>>19

medium.com

No thank you!

>>20
Sorry.
https://mathiasbynens.github.io/rel-noopener/
https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/

>>21
Check 'em

Found another HTML parser/tokeniser, and it's no better than any of the existing ones I've seen:

https://github.com/google/gumbo-parser/blob/master/src/tokenizer.c

Nearly 3k lines of disgustingly verbose, redundant C. Look at the functions handle_doctype_system_id_double_quoted_state and handle_doctype_system_id_single_quoted_state, or handle_attr_value_double_quoted_state and handle_attr_value_single_quoted_state for good examples of this utter idiocy. I refuse to believe that a programmer with a functioning brain could generate such filth. Did the thought "this state looks almost exactly like that state exact for this one thing, I should probably merge them" ever cross that retard's mind? Probably not, because there was no mind for the thought to cross!

The most valuable part of that file is contained within these 4 lines:
// Initial size chosen by statistical analysis of a corpus of 60k webpages.
// 99.5% of elements have 0 attributes, 93% of the remainder have 1. These
// numbers are a bit higher for more modern websites (eg. ~45% = 0, ~40% = 1
// for the HTML5 Spec), but still have basically 99% of nodes with <= 2 attrs.

Ironically, the description here...

https://github.com/google/gumbo-parser

... says it's "relatively lightweight". No, it's not - far from it. You just haven't seen what real "lightweight" is.

>>23
ENTERPRISE

>>23
You are disliking that code for all the wrong reasons. You're butthurt that it's not C-ish enough. I don't even know where to begin with how fucked up your mentality is.

>>25
Check 'em

Instead of writing a browser in C which has already been done perhaps thousands of times, why not write it in something more advanced like Scheme, CL, clojure, or even elisp? You would be able to get done faster as well, since most of the parsing can be macros.

>>27
Cudder is making an efficient asm browser.
You want an inefficient lisp one? Then do it yourself, bitch.

>>23
How far are you from passing acid2?

>>27
It would be a miracle if Cudder produces something at all.

Cudder is all talk and no action

>>27
Because she isn't your bitch. She can do whatever she wants with her time.

Check em!

Damn, I missed.

No, wait, NOW check'em!

FUCK!!!!!!!!!!

>>32
>>33
>>34
>>35

lol u suck at getting dubs kiddo

>>36
lol u suck at optimizing quotes kiddo

>>36
SO DO YOU!

I enjoyed >>32-35

/cudder/