>>113
Not yet... it's not even got a UI at the moment. Maybe once it passes Acid2.
>>114
1.2MB? HTML3.2 only (NO CSS)? I don't want to be too optimistic here but I'm going to say even that is bloated compared to my revised estimates. I could take what I have now (which is HTML5 compliant) and add a dumb renderer that doesn't care about CSS at all and just uses the defaults, and it'd probably still stay below 256KB. What I'm aiming at is 1MB for HTML5 + CSS2.1 (maybe some of 3, we'll see) + ECMAScript 5.1.
>>118
Use != waste. And your process is not the only process on the system. It shares that memory along with all the others, so it makes sense to use as little as needed, otherwise you start using virtual memory, and that is when things slow down.
>>122
Look above you in the thread, there are dozens of these "browser shells" that just change the UI and nothing about the core rendering engine itself.
>>124
Why else do you think I'm aiming for HTML5 (other than the fact that its parsing algorithm is detailed in the spec)? This isn't like NetSurf or Dillo or any of the other original browsers out there - it's going to be far smaller than anything else, but at the same time more featured and compatible with more websites. It's designed to be the simplest thing that can possibly work. I don't really care about JS speed as long as it's "good enough" for most websites; besides, what's worse than all your
other apps thrashing VM because your browser decided to eat all the RAM for its JS "optimisation"? Cut out all the "abstraction layer" cruft and FUCK "portability" (we're in a Windows world, I may do X11 in the future if I move there exclusively but they will NOT be the same codebase.) Don't have libraries upon libraries piled on top of what OS provides. Make the rendering path as direct as possible. No silly enterprise design patterns soup.