Why browsers are bloated [Part 2]

Cudder is all talk and no action!

>>319-320
ES6 is turdware.

check my dubs

>>320
web monkeys have to write for IE-using idiots

>>321
it's not good but it still makes the language much less painful to use. kind of like Java 8 - nobody in the right mind would say that it does FP, monads or parallelism right but even such half-assed implementations make the language less cumbersome and boilerplate'y.

will uzbl ever be good?

>>278

parseh (mine)

wait a minute...
HOLY SHIT IS THAT A MOTHERFUCKING

Touhou

REFERENCE??!!?!

>>322
Java 8 also ruined what made Java good. It has all this retarded crap now.

>>325

Java 8 also ruined what made Java good.

Java was never good. It's just too verbose, and then you get into performance issues whenever you write anything more than Hello World applications.

https://hacks.mozilla.org/2017/06/network-monitor-reloaded/
Firefox is now partially webapp.

>>324
No. parseh = parse HTML.

However, this is: http://www.hnng.moe/f/Rzi

>>327

hacks

Idiotic name, or perhaps appropriate.

Parsee is an aho!

they are bloated because of the botnet inside them

Where are the updates??

Cudder has been ambushed by an unknown attacker wielding an inprovised bludgeoning weapon consisting of a brick in a sock.

>>332
hope she's fine

>>333
she's dead

>>334
Is it serious?

>>335
yes.

>>332
Inshallah I will behead Nikita and his fellow niggers

>>337
African Americans*
Tsk

>>337
^* Africa Americans

I hope cudder-sama is ok

Cudder should go back to translating Visual Novels instead of this.

Cudder should start sucking my dick instead of this.

>>342
rude

Cudder should check my dubs instead of this.

Where is the source code?

>>343
russian gals love rude bois

Will this eventually be finished and released?
I'm sick of firefucks and chromiumshit

>>347
It's not. Just use qutebrowser instead.

>>348
No uMatrix.

>>349
Neither will cudder's browser have it.

https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great-c-runtime-crt-refactoring/

FUCK YOU, Microsoft!!

You turned a single-DLL CRT that comes with Windows into a bunch of bloated ones, then exploded those into dozens of tiny files and said you made it "simpler"? What a piece of retarded bloated bullshit!!

Of course, not surprisingly that their actual reason for doing this shit is to make it harder for people to write tiny portable programs that work on every version of Windows from Win95 onward...

>>351
make your're are browser

>>351
That is how you maintain job security: by fixing something that was working perfectly for ages. Same way they pushed SystemD.

>>351
The catch is that there are many functions that you may consider standard features of C that are not included in the libc.a library itself. For example, all the math functions that are declared in math.h are defined in a library called libm.a which is not linked by default. So if your program is using math functions and including math.h, then you need to explicitly link the math library by passing the ‘-lm’ flag. The reason for this particular separation is that mathematicians are very picky about the way their math is being computed and they may want to use their own implementation of the math functions instead of the standard implementation. If the math functions were lumped into libc.a it wouldn't be possible to do that.

I'm all dubs and no action!

>>351,355
Lack of modularity is one of libc's major defects. Users shouldn't have to link in malloc just to use sprintf, but that's exactly what the most common implementations require. Inability to define custom stream sources is another big shortcoming (why can't I printf to a circular buffer? Too bad, has to be a FILE *).

You might argue that only embedded programmers care about this, but you'd be wrong. The Plan 9 C libraries recognized and fixed many of these problems. The IO library in particular is great; too bad no one will ever use it.

>>355
Sorry, I mena
>>354

>>353
Not on Windows. MSVCRT.DLL has everything. It's perfectly fine to use your own math functions, just name them differently than the standard ones, or if you must use the same names, then load them dynamically yourself.

>>356
I'm talking about dynamic linking, where it makes sense to just link to one DLL, shared in the whole system, containing all the functions.

Just lol at Microsoft DLLs. Insane that you’re unironically trying to target Windows desktop.

You’ve literally procrastinated so long that an entire era of computing has passed you by.

>>358

I'm talking about dynamic linking, where it makes sense to just link to one DLL, shared in the whole system, containing all the functions.

In general you shouldn't have to link in a single mega DLL for the same reasons you shouldn't have to link a large static library. An unnecessary dependency is an unnecessary dependency; even if dynamic linking amortizes the memory cost over many applications, the problem is still there.

That being said, MSVCRT's ABI specifically is a nightmare. It's not worth it to do as Microsoft has done without commitment to maintain the exact same partition of functions between DLLs in future releases; without that everyone will just bundle the entire set of DLLs rather than deal with breakage when the boundaries move.

Given that classic libc was never really designed to be subdivided in this way, any failure here is unsurprising. musl explicitly does not try to do this because (they claim) robust implementation of the full set of standard libc APIs is impossible without much coupling. It may be that the only practical way out is to abandon the standards.