Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
McGrath: Proposal for a new Fedora project
Posted Oct 1, 2010 18:48 UTC (Fri) by Kit (guest, #55925)
I can only see this /possibly/ working if you do the same thing as Chrome OS: target devices at the bottom end of the netbook range... but then again, Android is already stealing ChromeOS's niche- with the advantages of local applications!
(the Quake 2 demo was impressive... for a web browser. Remember, that's a -thirteen- year old game they got to work... and only using unreleased browsers...)
Posted Oct 1, 2010 19:35 UTC (Fri) by flammon (guest, #807)
Posted Oct 1, 2010 20:11 UTC (Fri) by oak (subscriber, #2786)
Apparently you have no clue about how much these use memory. If you have your "web-apps" as separate processes, they are way heavier RAM-wise than Gtk or Qt. For starters, normal UI toolkits don't run virtual machines or use JIT...
> The write once run anywhere promise is much closer to reality. Even I9 is stepping up and putting in an effort to follow the standard.
Hm. I'm still getting a Java Déjà vu.
Posted Oct 1, 2010 21:30 UTC (Fri) by cmccabe (guest, #60281)
By the way, when Java was still under development, one of the codenames it went by was "Oak."
Posted Oct 2, 2010 22:54 UTC (Sat) by flammon (guest, #807)
Write once run everywhere is much more real today than it ever was. HTML5 and ECMAScript are public standards that are not controlled by any individual company, unlike Java and .NET.
Posted Oct 3, 2010 19:41 UTC (Sun) by oak (subscriber, #2786)
And if they were in the same process, one can of course do the same with native code to save memory too...
> I think memory sharing and usage optimization is next and a few ideas will be borrowed from the hypervisor guys.
In that case there's same code (or data) bin all these VM instances which can be shared.
Data is mainly images I think. Except for things like site backgrounds and smaller images, images are probably page specific (I would assume browser to already share & cache images that are commonly used). In native applications images come for common widget & icon theme that is shared by all the applications using the same widget set. I don't see that happening for web apps.
And lastly you have the memory overhead that comes just from having a VM & GC. That's always going to eat memory than native non-GC code unless that has leaks (which may be easier to avoid with higher level language & GC).
> HTML5 and ECMAScript are public standards that are not controlled by any individual company, unlike Java and .NET.
I'm not so sure that the backend code for these HTML5 applications is written in ECMAScript. Java or .NET sounds more likely for that...
Posted Oct 9, 2010 21:20 UTC (Sat) by nix (subscriber, #2304)
RSS VSZ STIME TIME COMMAND
7464 9076 Sep27 02:52:33 ekeyd
That little bugger is making several hundred GCed allocations a second, incrementally GCing as it goes (using the Lua 5.1.4 collector), and has been doing that for a couple of weeks now. Memory usage attributable to GC and heap fragmentation (overhead with respect to memory usage of GCless implementation at startup), across all that time: perhaps 1-2Mb.
Posted Oct 9, 2010 21:33 UTC (Sat) by oak (subscriber, #2786)
If your example was of native code using GC and not having JIT, 1-2MB overhead sounds on the largish side for that sized program, but it of course depends completely on how dynamic your program's memory usage is.
Whether the program does lots and very differently sized allocs and how good its allocation patterns are. Heap works like stack so one should in general alloc last things you're going to free first if you want to minimize fragmentation. The allocator you use may utilize buckets for smaller alloc sizes which can affect this or not.
GC and interpreted languages of course have other advantages, but the topic was memory overhead. :-)
Posted Oct 10, 2010 0:57 UTC (Sun) by nix (subscriber, #2304)
1-2Mb overhead, well, yes, it seems excessive because it was tuned to find a good tradeoff between GC frequency/intensity and CPU consumption. (I suspect that most of that overhead is actually heap fragmentation, which even a non-GCed program is exposed to.)
(We are in luck sizewise, though: most of the allocations are the same size. Not all, but most.)
Posted Oct 3, 2010 22:17 UTC (Sun) by Wol (guest, #4433)
Posted Oct 2, 2010 1:08 UTC (Sat) by vonbrand (subscriber, #4458)
And gecko will run on what? It doesn't exist in a vacuum... neither is "let HTML replace X11" viable, whatever draws HTML has to do so on something...
Posted Oct 2, 2010 13:32 UTC (Sat) by flammon (guest, #807)
Posted Oct 2, 2010 3:55 UTC (Sat) by elanthis (guest, #6227)
That's like saying that there's a huge pool of high-school physics teacher who can now contribute to solving cold fusion.
I've worked in the web industry for years. The last freaking people you want touching code are web developers. They are -- with very few exceptions -- utterly freaking useless for anything other than building broken, slow, buggy applications that are just hodge-podges of cut-n-pasted jQuery scripts (which themselves are atrocious monstrosities of poor engineering) that function so long as you don't look at them the wrong way. The fact that there are a ton of them doesn't mean shit other than that it doesn't take much effort to go from knowing nothing to knowing enough to be considered as a web developer. there's a TON of people who breath air, but that doesn't mean they're qualified professionals when it comes to wind-powered electric-generator engineering.
The cool web apps you see springing up are not the work of web developers. They're the work of real programmers -- people with an extensive background in C, LISP, Java, or all of the aforementioned -- who decided to toy around with HTML and JS.
The really goofy thing is thinking that a browser is the best platform for application development. It isn't. You're confusing a popular application with its feature set, which are really two distinct things. You don't need a browser, you just need a development environment that has the advantages of a browser (and ideally without its disadvantages). What you're asking for are:
(a) a toolkit that focuses on content, semantics, appearance, and logic as four distinctive entities. HTML is a crappy language to work with, and SVG is only marginally better. CSS is HUGELY limiting. there are better models that exist today, and they exist without the huge legacy cruft of crap that browsers need to support those old HTML, old CSS, and old JS files that make up 99% of the Web today.
(c) easy XML and JSON processing. once again, libraries already exist for this, and are wrapped up in just as easy to use APIs for easy to use languages. even better, there are libraries for even more formats out there, for those cases when XML is too stupid (most cases) and JSON is still not condense enough (which happens way more often than your average low-bar web programmer could even begin to realize, out here in Real Programmer Land).
(e) a project focused on all these things. go start your own, you don't need Fedora to do it for you. Fedora already has a goal and a vision. instead of forcing another project to become something else entirely, just start a new project to realize your vision. if the community believes your idea has merit, they will contribute; if they don't, you'll flounder on your own with bringing an existing successful project down with you.
The browser is a nice model or prototype of what you want, but it isn't the final product you want.
Posted Oct 4, 2010 3:34 UTC (Mon) by servilio-ap (subscriber, #56287)
(a) a toolkit that focuses on content, semantics, appearance, and logic as four distinctive entities. HTML is a crappy language to work with, and SVG is only marginally better. CSS is HUGELY limiting. there are better models that exist today
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds