Yes, indeed. I much doubt anyone hopes to have 'perfect' browsing on N900. But slow might be tolerable, depending on individual use/needs

One side note is that "zram" might help a little: https://www.kernel.org/doc/Documenta...ckdev/zram.txt

Might get us to 400-500MB:

There is little point creating a zram of greater than twice the size of memory
since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the
size of the disk when not in use so a huge zram is wasteful.

Firefox wise, they have dropped GTK2 so without maintaining a fork of browser related code (Firefox/embedlite and gtkmozembed)) a Microb inspired browser is out.

But isn't there gtk3 mozembed and qt5 mozembed?

Ok, perhaps a very stupid question (?): Why can we not replace the ram with a sufficient big swap partition?

Why can we not use WebKit?

For your first question (honest questions are never stupid!):

Ram is built into devices for a reason, it has advantages over normal storage:
(Near) infinite reads and writes
Very fast reads and writes (orders of magnitude!)
But it looses its data when turned of.
So you use it to

1. store data which will be written to disk
2. data you only need to operate your running programs
3. data which you read so often you want to save time by storing it in RAM, where reads are much faster.

If you add swap, you tell the system to handle a bit of normal storage like ram. Obviously its fully useless for 1 and 3, because your swap is already a slow as the disk. This leaves us with usage 2. But your software expects RAM to be fast, so it changes its contents all the time. Every time something changes in your software your RAM content changes. And many things change, when, for example, your scroll a webpage.

The operation system now tries to work around this.
See that tab he has in background for 5 minutes? We can probably move it to swap, it won't change soon and the user can wait a few sec, when he activates it again. If he does, we move it to RAM and seek another inactive tab to move to swap.

This works somewhat well, till you are at a point where the fast changing contents alone use all your RAM. As modern browsers expect much RAM (and need it to render many of todays huge websites) They have big areas of RAM where contents change often.

Now these will spread to swap and things get really slow. Your firefox expects that RAM read and write to be done in 1 ms, but now its writing to swap on disk and takes 1s instead. It will still work, but the user will grow a beard till the webpage is rendered.

Personally, I prefer Gecko. But I am biased, because I like how XUL-based interface allows extensions to directly change web browser's look and behaviour.

WebKit has big corporations such as Google (Chrome) [granted, Google has since switched to Blink instead of WebKit], Apple (Safari), Microsoft (Entourage), Blackberry (Browser since 6.0) and Opera (uses Blink aka Google's derivative of WebKit) interested in the engine, its development, and monopolisation of market share.

Granted, there is a very fascinating project about porting WebKit to Gtk+ https://webkitgtk.org/ and an existing BSD-licensed mobile web browser based on WebKit https://en.wikipedia.org/wiki/Nokia_Browser_for_Symbian . Midori is fascinating as well.

In my personal opinion, applications running on Maemo operating system should depend only on Hildon widget toolkit, not on raw Gtk+ (just look at Navit, tiny menus are difficult to navigate), or Qt (even though it tries very hard to look like Hildon), if only for the sake of consistent behaviour (and lower memory usage - no need to have libraries for many widget toolkits around).

At the same time, web browser should have front end (GUI) entirely separate from backend (rendering engine) which means that switching between Gecko, WebKit, NetSurf, or Blink may be possible. And make porting to different desktop environments less painful.

And I would go far enough to say that apps should be interconnected to the point that web browser, instead of trying to open a Youtube page just like any other page, would allow the video to be opened by Media Player (with Youtube plug-in), thus entirely disregarding advertisements, Javascripts and other problems associated with trying to open Youtube in a web browser. But that's only possible if a third party writes suitable extension for web browser.

Whichever way you go, do take into account that there is a variety of open-source engines available, and my criteria for choosing the best one would be: 1) light weight by itself; 2) capable of dealing with heavy weight websites when RAM is tiny, memory is limited, network is slow, and CPU isn't fast either; 3) capable of rendering HTML 5 and passing ACID tests.

Thank you. Best regards.
~~~~~~~~~~~~~~~~~
Per aspera ad astra...