Quote
chinarobin
Much clear now, thanks for explaination.
i choose v8 test, because newest test always freeze my km.
Quote
4td8s
try doing the test with Fx5 when that one comes out later this june.
Quote
Fred
The possible better speed seems for me mainly concerning faster javascript execution, caused by a faster Javascript engine.
For me personally, this is not that important, as I turn off javascript most of times. I use it only sporadically if it is absolutely necessary.
Quote
Fred
The features that make K-Meleon more interesting for me than the other browsers is the possibility to adapt it to my personal wishes using the menus and macros, and that is where scripting is important for me.
Quote
Fred
A webpage should be usable satisfactorily without any scripts.
Even Youtube seems to have learned that, as the flash files load now without javascript, which is completely unnecessary and only a source of unwanted smuggling in of malware.
Quote
Fred
The possible better speed seems for me mainly
concerning faster javascript execution, caused
by a faster Javascript engine.
For me personally, this is not that important,
as I turn off javascript most of times.
I use it only sporadically if it is absolutely
necessary.
The features that make K-Meleon more interesting
for me than the other browsers is the possibility
to adapt it to my personal wishes using the
menus and macros, and that is where scripting
is important for me.
A webpage should be usable satisfactorily without
any scripts.
Even Youtube seems to have learned that, as
the flash files load now without javascript,
which is completely unnecessary and only
a source of unwanted smuggling in of malware.
Flash works basically without javascript.
Fred
Quote
rodocop
2) JS isn't browsing speed bottleneck. They are html-parsing, css one, # of simultaneous tcp/ip-connections, computer RAM work, GUI speed (XUL or Win native) and so on but not JS handling!
Quote
JohnHell
Javascript is really a bottleneck on HTML render cause most of that HTML (and I must say XML too) is rendered only after a JS function is executed, commonly named AJAX. So, yes, javascript is a bottleneck.
Quote
JohnHell
It should be a default toolbars.cfg instead a per skin toolbars.cfg to, at least, let the skins take the default layout for each skin. Then a profile toolbars.cfg to allow personal tweaks and override, then, default ones.
In other words, standardize them.
Quote
rodocop
Quote
JohnHell
Javascript is really a bottleneck on HTML render cause most of that HTML (and I must say XML too) is rendered only after a JS function is executed, commonly named AJAX. So, yes, javascript is a bottleneck.
Maybe you're right. Maybe...
But in real life I take one of the most AJAXed web-sites - webOS (eyeOS.org) and gave KM (1.6b2) and FF (4.0.1) a try on this sample. I can't see any FF advantage in speed of working there. Otherwise, KM was sometimes notably faster.
Quote
rodocop
Per contra, old KM just refuses to load some JS-rich pages and this is real restriction that leads to mass migration on the new version. But if KM works on page (on REAL existing page!) it does this not slower than FF right now.
Possibly, there are some rare exclusions, but I didn't meet them yet :-)
Quote
rodocop
Quote
JohnHell
It should be a default toolbars.cfg instead a per skin toolbars.cfg to, at least, let the skins take the default layout for each skin. Then a profile toolbars.cfg to allow personal tweaks and override, then, default ones.
In other words, standardize them.
This is one way. And reasonable way. But regardless of standard presence my query deserves attention too: even if we get unified toolbar, we also need GUI tool for configuring it, as in FF.
Quote
JohnHell
But we are comparing there a very similar GRE version, or, at least, both have JIT (Just In Time) new JS engine.Quote
rodocop
Maybe you're right. Maybe...Quote
JohnHell
Javascript is really a bottleneck on HTML render cause most of that HTML (and I must say XML too) is rendered only after a JS function is executed, commonly named AJAX. So, yes, javascript is a bottleneck.
But in real life I take one of the most AJAXed web-sites - webOS (eyeOS.org) and gave KM (1.6b2) and FF (4.0.1) a try on this sample. I can't see any FF advantage in speed of working there. Otherwise, KM was sometimes notably faster.
Yes, that's true. (But remember that if KM refuses some JS sites is because of JIT version/implementation on that version)Quote
rodocop
Per contra, old KM just refuses to load some JS-rich pages and this is real restriction that leads to mass migration on the new version. But if KM works on page (on REAL existing page!) it does this not slower than FF right now.
Possibly, there are some rare exclusions, but I didn't meet them yet :-)
But with javascript enabled, we could say something like:
KM1.6b2 against FF4.0: very similar
KM1.6b2 against FF7.0: notable differences
KM1.1.x-1.5.x against FF4.0: notable differences
KM1.1.x-1.5.x against FF7.0: maybe no words to describe
KM1.1.x-1.5.x against KM1.6-1.7: huge difference.
Without javascript enabled, not very important differences (beyond display layout because of HTML version implementation).
That could be an interesting suggestion: some kind of a toolbar wysiwyg GUI editor/customizerQuote
rodocop
This is one way. And reasonable way. But regardless of standard presence my query deserves attention too: even if we get unified toolbar, we also need GUI tool for configuring it, as in FF.Quote
JohnHell
It should be a default toolbars.cfg instead a per skin toolbars.cfg to, at least, let the skins take the default layout for each skin. Then a profile toolbars.cfg to allow personal tweaks and override, then, default ones.
In other words, standardize them.