Why browsers are bloated [Part 2]

Cudder is all talk and no action!

>>80
NO ACTION

>>80
It's called refactoring done right. I expect it'll get even smaller when I fully analyse and rewrite the HTML parser in Asm, because it currently is a pretty dumb direct translation of the standard and there's still plenty of redundancy to remove.

Goal was 256K originally but a long time ago I moved to 64K, maybe I didn't announce it in that thread but I think I did say so somewhere...

As work starts up I'll be busy again so don't expect the progress to accelerate.

>>82
so this is 64K for the whole thing or just for parsing and rendering HTML, without a JS interpreter?

>>82
Can you give us an updated roadmap?
When does your work start again?
I'd be hoping for the first release (passes Acid2) soon... Not gonna happen?

>>83
64k for Acid2 pass, so no JS required in that.

>>85
It's the same as it has always been. When I have time to work on it, I do.

>>87
Work on checking these dubs

>>87
hi cudder
will your asm rewrite run on my 68k? no mmu/floating point or anything just classic 68k

>>89
Are you seriously implying that Intel ASM is equivalent to 68k ASM?

>>90
no im asking in case he's doing 68k also

Cudder is all talk and no action.

He will keep teasing you forever.
Even after claiming to have implemented everything, he will invent something new he has to do before releasing the source. Optimization... Clean-up... Size-reduction...
The years will go by and you fools will keep waiting for a release.

>>69
why are you using wine? is your browser natively windows-only? if so, why? I guess the point is to avoid linking external GUI libraries

are dubs bloat?

>>99
check my bloats

>>100
bloats after bloats, that's a gift that keeps on bloating

>>101
le pedophile sage

>>92
This is the way of the premature optimizer. Apparently bloat is more important than something that works ASAP so therefore, their pie in the sky perfection of no bloat will be delivered 10 times slower than every one else.

>>103
Premature optimization is better than premature bloat.

>>103

devilery times

https://news.ycombinator.com/

>>96
Why not? Win32 API is far more common and less annoying to deal with than the mess of bloated *nix "you are in a maze of GUI libraries, all almost alike".

The *nix CLI is awesome, but the GUI situation is horrible. Windows is pretty much the opposite. WINE helps get the best of both worlds.

>>103
No optimisation is premature when you're competing with huge existing implementations that have probably spent person-centuries on optimisation (and adding bloat...) I could probably get some huge libraries and release Yet Another WebKit Browser in a halfternoon, but that's not really useful.

>>107
you don't need a bloated GUI lib for a minimalist browser, just call the most basic X functions. granted, X is itself pretty bloated but so is windows. but maybe I'm just saying it because I'd rather have a browser run natively on linux or openbsd than go through a compatibility layer.

as for windows GUI API, I dunno. when I worked with it, it felt like they tried to force a C++-shaped peg into a C-shaped hole. you have many types (devices, device contexts, windows, window handles and a fuckton of stuff I don't remember) and functions to put one type in another type which would make sense if done under the hood in a sepples-style language but feels like a lot of boilerplate and busy work. but keep in mind that I have a different perspective because my work with windows GUI stuff was about reverse engineering it, so maybe it's possible to write it in a more concise way but the programmer who did the original work was a dumbass.

>>107
You have inherently different goals to everyone else. The cost of "perfect no bloat" optimization is programmer time which translates to a bigger per hour bill at the end. Another issue with what you aim for is that you're happy to target only one specific platform. The cost of these goals are fine when the commissioner of the project is willing to pay for it. In your case, nobody's paying you for a low so these issues don't matter.

In the real world, the normal goals of software development are the speed of software delivery, cross platform execution, easily maintainable, reusable modules and architecture, and the accountability of development concerns. Programmer time is generally much more expensive than computer time so most software commissioners aim for these goals. The big "bloated" libraries exist because it's normally more cost effective for programmers to piece together libraries of flexible and general logic blocks rather than your approach of perpetually reinventing the wheel.

>>107
Why not just use plain Xlib?
It's the equivalent of Win32 API for *nix.
Every *nix has X11 and Xlib available.
You don't need toolkits.

People who argue from a business standpoint are spooked to the max.

This isn't ENTERPRISERIDER. Nobody gives a fuck about ``the real world"

Guys, stop asking Cudder for support for more platforms and other crap.
The way it is now, it's possible we won't see the first release of the browser in 10 years. If you keep pushing other stuff, we will never see it.

>>111
Most users care about seeing releases earlier rather than later. Solve the immediate problem first then afterwards, you can improve the performance in the subsequent releases.

>>108
You may have RE'd something written with MFC, AFX, ATL, or whatever bloated library MS put on top of Win32, or the developers just had "class envy".

>>110
Xlib is only window management and basic graphics. It's like gdi32. Win32 has user32, comctl32, comdlg32, etc. which contain the UI widget implementations.

Non-ASCII pages appear to work too:

http://i66.tinypic.com/adou3b.png

Where is activex support Cudder?