OSDev.org

Anyway, a kernel cannot be pure-javascript, as it does not fill in the minimal requirements :
- have the possibility to include inline asm (This breaks the spirit of JavaScript, and is hard to do)
- Allow to directly manipulate addresses
...

So the only thing you can have is a minimal kernel which interfaces to a JavaScript driver

You mean a box dedicated solely to Tim Berners-Lee's horrible design decisions? The "web" as it is popularized is so limiting to the user. It's hardly something computers were designed for... it's more like a telephone, as in, almost nothing happens on the device but communication with a server and the visual rendering associated with received content.

The principles of Tim Berners-Lee's designs are definitely NOT aligned with Douglas Engelbart's vision, which I perceive as a lost relic. The deal is not merely about teleporting pretty books. Personal computing should stop being associated with this fancy form of communication. I know its absurd, but it really seems like when people say "computer," they're actually thinking towards the term "Internet," which really means the "World Wide Web" to them; not the technology behind it.

I really hate these centralized models. I guess it's good to a certain extent, but completely discarding locality is insanely stupid. It's incredibly in-robust, and your computer becomes more like an access point.

I know that it is not the most efficient solution, but that is what the OP wanted (I think).

And what you refer to as "horrible design decisions" is anyway one of the most used technology in the world !
And the "centralized model" you're talking about is the Cloud, and that is the direction all systems are going towards. Even Windows !

And what you refer to as "horrible design decisions" is anyway one of the most used technology in the world !

That doesn't make them less horrible, though.

Hi,

Griwes wrote:

And what you refer to as "horrible design decisions" is anyway one of the most used technology in the world !

That doesn't make them less horrible, though.

A tool designed for one purpose (e.g. a hammer for pounding nails) can't be extended to be useful for another purpose (e.g. cutting a cake) without completely destroying design elegance. It's always better to have different tools designed specifically for different purposes - e.g. a hammer for pounding nails and a knife for cutting cake.

A tool designed for one purpose (e.g. HTML 1 for mostly static documents) can't be extended to be useful for another purpose (e.g. "web apps") without completely destroying design elegance. It's always better to have different tools designed specifically for different purposes - e.g. HTML 1 for static documents, and maybe something like X or RDP (but not X or RDP) for "web apps".

It's just sad that web developers and W3C are morons who are more interested in polishing a turd than they are in designing something suitable for web apps.


Cheers,

Brendan

Brendan wrote:A tool designed for one purpose (e.g. HTML 1 for mostly static documents) can't be extended to be useful for another purpose (e.g. "web apps") without completely destroying design elegance. It's always better to have different tools designed specifically for different purposes - e.g. HTML 1 for static documents, and maybe something like X or RDP (but not X or RDP) for "web apps".

A tool designed for one purpose may be hard to extend to another purpose directly, but you can always make a tool to extend that tool. The web is built on layers of reflection and preprocessing. You may think this is inefficient and messy, but then think about this: isn't machine code a poor tool for writing programs? Do you consider assemblers and compilers to be hacks?

Hi,

NickJohnson wrote:A tool designed for one purpose may be hard to extend to another purpose directly, but you can always make a tool to extend that tool. The web is built on layers of reflection and preprocessing. You may think this is inefficient and messy, but then think about this: isn't machine code a poor tool for writing programs? Do you consider assemblers and compilers to be hacks?

Machine code is designed to tell CPUs what to do. Assembly/disassembly is a human readable translation of machine code. High level languages are a way for humans to tell the computer what they want done. That's 3 completely different things for 3 completely different purposes; each designed to be "good" for their specific purpose.

Nobody would be stupid enough to try to extend machine code and use it as assembly or as a high level language, or as anything else (e.g. as a query language like SQL). It was never designed for that, and it'd suck if you tried.

Nobody would be stupid enough to try to use assembly as a machine code (e.g. a CPU that executes ASCII) because that would suck. Nobody would use assembly as a portable high level language either, or as a query language or as a graphics file format or anything else.

Nobody would be stupid enough to extend a language like C or Pascal and use it as a machine language, or an assembly language, or a query language, or a sound file format or anything else.

HTTP and HTML were originally designed for "static documents with hyper-links", and they're reasonably good for this purpose. They were never designed for file transfers (e.g. like FTP) or remote applications (like X) or as a print publishing format (like PDF) or as a programming language (like C) or for anything else. HTML would suck badly for all of the things it wasn't designed for, including "remote/web apps". In theory, you might be able to hide the idiocy of "web apps" under layers of bloat, but that doesn't change the fact that it was (and still is) a stupid idea to begin with.

I'd also suggest that if you can't design something better for web apps than "http + html/xhtml + client side scripting + server side scripting", then you should stop pretending to be a software developer and maybe consider a career as a janitor or something. The problem isn't designing something better - the problem is getting it adopted and supported by everyone.


Cheers,

Brendan

Brendan wrote:Machine code is designed to tell CPUs what to do. Assembly/disassembly is a human readable translation of machine code. High level languages are a way for humans to tell the computer what they want done. That's 3 completely different things for 3 completely different purposes; each designed to be "good" for their specific purpose.

Exactly my point: high level languages hide the ugliness of the layers below, which exist for practical reasons. In the case of machine language, those practical reasons involve the easiest way to construct a processor; in the case of HTML and JS, they involve the historical need to standardize formats. Web frameworks exist because HTTP and HTML are annoying to interface with directly, and work better if you can instead say what you want done and have the server generate the content for you. It's the same idea as high level compiled languages, which took the systems world quite a while to develop and make widespread.

Brendan wrote:I'd also suggest that if you can't design something better for web apps than "http + html/xhtml + client side scripting + server side scripting", then you should stop pretending to be a software developer and maybe consider a career as a janitor or something. The problem isn't designing something better - the problem is getting it adopted and supported by everyone.

But "http + html/xhtml + client side scripting + server side scripting" is just a particular implementation of some way of transporting data, some way to describe an interface, and ways to describe what sort of processing should be done by the client and what sort should be done by the server. Any sort of client/server system where the application is served in its entirety is going to have to have these components. Even if you don't agree with the exact formats (although IMO HTTP is not that heavyweight and HTML is not that inefficient as a description language; both can be as ugly as they want and still work) the basic architecture seems pretty sound.

Hi,

NickJohnson wrote:

Brendan wrote:I'd also suggest that if you can't design something better for web apps than "http + html/xhtml + client side scripting + server side scripting", then you should stop pretending to be a software developer and maybe consider a career as a janitor or something. The problem isn't designing something better - the problem is getting it adopted and supported by everyone.

But "http + html/xhtml + client side scripting + server side scripting" is just a particular implementation of some way of transporting data, some way to describe an interface, and ways to describe what sort of processing should be done by the client and what sort should be done by the server. Any sort of client/server system where the application is served in its entirety is going to have to have these components. Even if you don't agree with the exact formats (although IMO HTTP is not that heavyweight and HTML is not that inefficient as a description language; both can be as ugly as they want and still work) the basic architecture seems pretty sound.

For "web apps"; as a transport protocol HTTP/HTML is bad for client-side caching, bad for maintaining state and bad for sending data from the client. For describing what the interface should look like, HTML and CSS is just bad in general (overly complex, too inefficient, too inflexible); and for describing how users interact with the interface it's pure puke - they had to slap an entire language (javascript) and a new document model (DOM) on top of it just to make up for how limited HTML alone is.

If you don't understand what I'm saying; try implementing Xeyes with nothing more than HTTP, HTML, CSS, Javascript, DOM and any server side scripting you like. For something incredibly simple like this; most sane people would give up before they start (and use Flash or a Java applet or something instead).


Cheers,

Brendan

Brendan wrote:If you don't understand what I'm saying; try implementing Xeyes with nothing more than HTTP, HTML, CSS, Javascript, DOM and any server side scripting you like. For something incredibly simple like this; most sane people would give up before they start (and use Flash or a Java applet or something instead).

You can draw the eyes using a HTML5 canvas element, and capture mouse postition the same way. Of course, it will only work within the browser window, but from a security/stability standpoint, it makes sense not to allow the page to capture/control the mouse from outside of the browser window. I'm not a JavaScript expert by any means, but I don't think that's any harder than using Java or Flash. I'd say 200-300 lines max.

Edit: also, this was a link on the very Wikipedia page you pointed me to: http://wsabstract.com/script/script2/xeye.shtml. This code appears to have been written in 2001, and doesn't even use a canvas, but still works in about 100 lines of JS.

Hi,

NickJohnson wrote:

Brendan wrote:If you don't understand what I'm saying; try implementing Xeyes with nothing more than HTTP, HTML, CSS, Javascript, DOM and any server side scripting you like. For something incredibly simple like this; most sane people would give up before they start (and use Flash or a Java applet or something instead).

You can draw the eyes using a HTML5 canvas element, and capture mouse postition the same way. Of course, it will only work within the browser window, but from a security/stability standpoint, it makes sense not to allow the page to capture/control the mouse from outside of the browser window. I'm not a JavaScript expert by any means, but I don't think that's any harder than using Java or Flash. I'd say 200-300 lines max.

Edit: also, this was a link on the very Wikipedia page you pointed me to: http://wsabstract.com/script/script2/xeye.shtml. This code appears to have been written in 2001, and doesn't even use a canvas, but still works in about 100 lines of JS.

Assume the server needs to know where the mouse pointer is pointing...

Note: Mostly what I'm looking for is something like the X model, where the user's machine tells the (remote) application what the user did, and the (remote) application responds. It's not much fun using "client/server" without the server being involved beyond the initial file download.


Cheers,

Brendan

You realize that it's possible to send data back after the page has loaded, right? That's what AJAX is: asynchronous HTTP requests sent and received by the loaded page. It would be totally possible to do all the processing on the serverside for an app like that, although it would be kind of silly to waste server resources on simple calculations. That is, unless the eyes were actually used to spy on you...

The web model is different from the X model in the sense that most/all of the graphics processing is done on the client side, but otherwise it's just as capable. The assumption is that client processing time is cheap (but not secure) and that network bandwidth is the premium.

Hi,

NickJohnson wrote:You realize that it's possible to send data back after the page has loaded, right? That's what AJAX is: asynchronous HTTP requests sent and received by the loaded page. It would be totally possible to do all the processing on the serverside for an app like that, although it would be kind of silly to waste server resources on simple calculations. That is, unless the eyes were actually used to spy on you...

The web model is different from the X model in the sense that most/all of the graphics processing is done on the client side, but otherwise it's just as capable. The assumption is that client processing time is cheap (but not secure) and that network bandwidth is the premium.

So now you've got a HTML page that contains javascript that requests another page and injects it into the original page's DOM? Yo dawg, I herd you like hacks so I put a hack in your hack so you can hack while you hack...

Which part of this makes you think of the words "design elegance"?


Cheers,

Brendan

That's what AJAX is: asynchronous HTTP requests sent and received by the loaded page. It would be totally possible to do all the processing on the serverside for an app like that, although it would be kind of silly to waste server resources on simple calculations.

The problem with AJAX is that it uses HTTP. The problems with HTTP are:
1) It's text-based, takes very much space to just get xy coordinates (following above example) sent.
2) It's connection-less, so you need a hack (= session, another later add-in) to get it working in connection-like mode.

Like Brendan said: Yo dawg...

If AJAX is too slow, you could use an HTTP CONNECT to transfer binary data (I believe there is a library called Comet that does this.) This just opens a plain old TCP connection to the server.

You can send plain binary data over HTTP, at least as a reply from the server. Also, "text-based" (i.e. stuff that can be safely transferred as HTTP POST parameters) formats are not that inefficient. If you used a base64 encoding of binary numerical data, you wouldn't get very much overhead at all.

I barely do any web stuff, and I'm really just defending it because nobody else is, but you guys seriously need to do some homework before saying everything involving the web is stupid/slow/etc.