OSDev.org

So recently apps can be written with JavaScript or languages which target JavaScript: https://github.com/jashkenas/coffee-scr ... pile-to-JS.

So as apps are written for online use, see this image edition app for example: http://www.picozu.com/editor.
Doesn't it make sense to dive again in OSdev to get a kernel + TCP/IP stack + browser + some hardware support and use your own system for nearly every task you want?

Do you think that HTML5 will bring us into osdev golden era?

No, because the bindings HTML5 requires (and that are provided by javascript) and not enough by themselves to use a system. Obviously you would still need a Full Network stack (not just TCP/IP, as if that was really a lot less work), Printer Support, full 3D support for the webgl stuff, full 2d acceleration for flash and html5 video support, for audio support for flash and html5 audio support, etc, etc, etc.

- Monk

The idea of a basic OS with only a web browser is already in use by the Chromium OS project

I would expect this to be more of a boon for server-side or high-performance OS development that doesn't care about UI but needs some form of one. Why bother with the hell that is hardware-accelerated graphics when you have WebGL and canvas elements? Slapping a web interface on top of some fancy system you've made is an easy way to get people to use it.

What are you trying to accomplish? Do you actually want to embed HTML5 (complete with forms, controls, CSS, Javascript, video codecs, etc..) or just Javascript by itself?

Javascript is a great applications programming language, but not very great for systems programming. If you just want an OS that supports Javascript applications, then it's extremely simple to embed something along the lines of Google V8 or Mozilla SpiderMonkey - even in your kernel if you so wish.

I am making an Emacs-inspired text editor, but I'm using Javascript instead of using Emacs Lisp.

It has a small C++ 'base' that has 2 jobs:
- Manages 'framing' (splitting frames so you can see multiple views on the screen at once, resizing frames, etc)
- Executes JavaScript and wraps relevant APIs (Cairo for graphics, Win API for input and file IO etc.)

In the final form, the C++ base will consist of 1% of the logic, so I would consider it a "Javascript text editor". In the same way, you can write a very minimal C++ kernel around hardware and a Javascript engine, implement all applications in Javascript, and call it a Javascript OS.

Now, I use Javascript for a reason. My reason is that I enjoy the flexibility to have most of the code accessible and modifiable without recompiling or restarting the application. Am I editing the code and need a new function? I can modify the code while it runs.

Do you have one, or do you just want to use Javascript for the sake of it? Embedding V8 or SpiderMonkey is a lot of work just for the sake of it.

Where is the facepalm picture when you need it?

Perhaps instead you would like an OS which runs in a browser?

One that you can open on any HTML5 device, full screen the canvas, and away you go? http://www.skylightproject.com/

This would be significantly easier, but.. what problem are you trying to solve that could not be solved by simply making your own Javascript library in that case?

MessiahAndrw
I just threw an idea.
My goal isn't to make a javascript based OS (by embedding of course), I'm not a web 2.0 fanboy zealot.
My OS will be at least terminal-based, with TCP/IP stack, I will also port some security related softwares (nmap, netcat, hydra,...).
But for example, right now I haven't much experience in image edition, so by supporting HTML5 technologies I can have access to such applications without tedious porting.

I agree with you about speeding up the edit-compile-test cycle, this is why I will use Forth for most part of my OS, by the way I encourage you to try it since it's both low and high-level language, one may like it or hate it.
It's also very tiny, it may take 25kb. More or less, it depends on how many words (functions) it includes.

But for example, right now I haven't much experience in image edition, so by supporting HTML5 technologies I can have access to such applications without tedious porting.

Web browsers are really complex programs. At the end of the day, once you have the infrastructure in place to port a web browser, porting an image editor is trivial.

you still need to implement all the function to edit image in order to have the canvas interface embeded in the browser, javascript is not a self reliant kind of programming, most of the advanced function of javasript use browser plugins, and it require a system similar to either XPCOM for ff/chrome and COM for ie style, when you consider what is actually needed to get web 2.0 ready browser runnign, and the whole stack of software behind, to have some rendering application that quickly load up 1Go of ram in the browser to have rendering that is barely as fast as on an amiga, it's not really the easiest road to go to have a software framework to make image edition program, even if you can quickly benefit from all the web application already made that support the current web standard, and web and standard is quite of an oxymoron , but it's the point of the thing to be plateform independant, but a whole lot of framework are still needed behind in order to run advanced web 2.0 javascript i think you'd get quicker result by porting something like sdl if you want to be able to access an already made application base, javascript could be simpler to implement if it was only to script html dom objects, but with web2.0 javascript can also be use with non html object which make up the whole web2.0 thing, and you still need to provide the whole framework of image manipulation through the canvas interface for it to work properly