I understand that it may be a little confusing, so here is more information.<p>In the teaser video all visible parts are direct screen recordings of:<p>(1) existing 2D canvas or WebGL demos ported to NiDIUM engine<p>(2) shots and images from the native embedded UI Framework<p>Do not expect NiDIUM to read HTML pages or to compete with any existing browser.<p>Instead, expect a solution to build (and browse) applications, with a fast and unified look and feel.<p>So:<p>* Yes, it's a browser, in a sense that it can loads remote "apps/code" via HTTP using URLs (and somehow link them)<p>* Almost everything is integrated and highly customizable (like the integrated UI Framework)<p>* Cool APIs like plain-socket UDP/TCP (client and server), GLSL postprocessing on every canvas, layer, etc...<p>* We've made our best to be compliant with existing APIs (context2D, webgl, commonjs, etc...)<p>* It ditches HTML & CSS in favor of new things (NML and NSS, we will communicate on this later)<p>* Low Latency Audio and DSP (and yes, one of us come from the demo scene, hence the poor soundchip music ;-) )<p>We designed almost everything from scratch, but the whole thing is still at an early stage.<p>And to relate with tranding topics today about "english accent", we made this video a bit "old school" because we're not native english speaker (french) and a bit afraid of making "talkative" videos.<p>We will post updates as soon as possible!
I for one, like this. Now, the video & music are awful and definately do not support the overall presentation, but from what I understood, this seems to be pretty cool. Imagine being able to use Javascript for actual desktop application development, without having to resort to tons of html and css in the background. I do like this idea. Even better, it would allow to write applications in ClojureScript or some of the other compile-to-javascript frameworks). Of course, there're other frameworks that utilize javascript for scripting needs or for desktop development (<a href="http://www.tidesdk.org/" rel="nofollow">http://www.tidesdk.org/</a>) (<a href="https://code.google.com/p/chromiumembedded/" rel="nofollow">https://code.google.com/p/chromiumembedded/</a>) (<a href="https://github.com/appjs/appjs" rel="nofollow">https://github.com/appjs/appjs</a>) (<a href="http://www.appcelerator.com/" rel="nofollow">http://www.appcelerator.com/</a>) and of course Adobe Air, but all of them just basically open a webview, give you some html that looks a bit like native controls, and let you write html / css / javascript in there with limited access to filesystem or, god forbid, the graphics card.<p>What I understood this project is, is that it allows me to use javascript to drive my native UI elements, access my full system resources, etc. Basically full native development, only Javascript instead of C++. Maybe a bit like Qt QML (<a href="http://en.wikipedia.org/wiki/QML" rel="nofollow">http://en.wikipedia.org/wiki/QML</a>) (and I'd like to see a comparison between these two). I'm really looking forward to this, though I have to admit that the website lacks details, and the video isn't particularly good. This looks a bit too much like demo scene hacking.
File I/O alone is a good enough reason for this kind of projects to exist. I've always wanted to be able to use the power of the browser for standalone, cross-platform desktop applications.<p>I was shocked when I discovered I couldn't write a simple JS/HTML application and connect it to a local DB like SQLite without going through a server. Each browser has its own hackish way of doing something like that, but they're far from a complete solution. So far I have my eyes on node-webkit[1], which does everything I need it to do, but I welcome every option in this space.<p>[1] <a href="https://github.com/rogerwang/node-webkit" rel="nofollow">https://github.com/rogerwang/node-webkit</a>
I find it saddening that the primary response from a crowd normally considering themselves visionaries and pushers, seems to be ridiculing other peoples hard work.<p>I cannot for the life in me understand how introducing a new browser engine deserves this kind of welcoming.
So the only thing clear from the comments is that the folks behind this are going to have to work on their communication game. The video was obviously created to tease the product a bit, which is hard when nobody knows exactly what thye're looking at, but even when I went to sign up for updates I see:<p>"We will send you a maximum amount of spam as soon as possible."
I really don't get a sense of what NiDIUM actually _does_. Is it a framework? A platform? A library? Where does it run? How am I supposed to deploy it? What use case does it solve that doesn't already have existing solutions?
This does not look like a browser.
It's a gui application framework, that happens to be using javascript as the preferred programming language.<p>A lot like <a href="https://github.com/rogerwang/node-webkit" rel="nofollow">https://github.com/rogerwang/node-webkit</a>
I recommend seriously shortening the intro to the video, and showing the goods immediately.<p>Only really interested people on the web have the attention span to watch 30 seconds of uninformative intro.
I'd venture to guess from the presentation and the site that this is basically trying to be Node.js with a graphics engine attached.<p>ie. Throw away the browser DOM and provide a bunch of new apis (and maybe a few existing ones which already seem ok, like the canvas stuff).<p>I'm curious what you get as a benefit of doing this instead of just using Node itself and providing an api to work with the graphics/sound/whatever engine.<p>No HTML or CSS renderering -> A considerably more plausible project, and certainly one that won't complete with existing browsers in the short term.
Just some feedback - This video reminded me of the demo scene circa 1990. This might lead some to think that the project has been under development for 20+ years and is still in alpha...
is this any different from what mozilla are doing already with their open source engine? why separate yourself from that? is your code available? if not why not?
It's great that people are trying to innovate in this area. That said, I write a web app because I want the accessibility that anyone with a browser already downloaded can come use it easily. It seems to me like this would require downloading a thick client different browser to use web apps written for it.<p>If it could be rewritten to be started from a JS include on a web page, that would be ideal. Second best would be if it ran from Flash, a plugin that is still widespread. Next best is if it were a plugin itself, but very few users are willing to install a plugin, so that is already unusable for me. Next best is a downloadable separate app, but that's even worse in terms of the number of users who will go through the trouble to use it, so again is not something I would use at this point.<p>Good luck! I, for one, like the scene style demo vid! Although it didn't tell me if the engine would be open source or not, which is also a big thing with me. Coding for a closed source engine and being beholden to someone else to figure out and fix bugs in it when my webapp is having trouble is very painful.
Most of the visuals in the video are webgl demos:<p><a href="http://glsl.heroku.com/e#457.0" rel="nofollow">http://glsl.heroku.com/e#457.0</a> apple by iq<p><a href="http://glsl.heroku.com/e#10809.0" rel="nofollow">http://glsl.heroku.com/e#10809.0</a> by tigrou<p><a href="http://www.backtothepixel.com/demos/js/webgl/704_webgl.html" rel="nofollow">http://www.backtothepixel.com/demos/js/webgl/704_webgl.html</a> by paulo falcão<p><a href="http://threejs.org/examples/webgl_custom_attributes_particles3.html" rel="nofollow">http://threejs.org/examples/webgl_custom_attributes_particle...</a>
It sounds to me a little bit like Qt Quick (ie QML + JS + remote QML files + Canvas + SVG) with WebGL added on[1], perhaps designed a little more specifically for remote files than Qt Quick is.<p>I really like Qt Quick, so this seems interesting too.<p>[1] Qt Quick supports OpenGL ES (the entire QML rendering system is written as an OpenGL-based scene graph), but I don't think you can make direct OpenGL calls without dropping to C++... You <i>can</i> add shaders to components from within QML though.
The web is weird, it feels like HTML is meant more for documents than for actual social platforms and dynamic content... If you think about it, is the web really sane?
It's interesting, but the trend toward making everything a web application is even more disturbing to me, given the revelation of how deep the security rot goes these days. The net is pretty much unavoidable, unless you're pretty hardcore, but I, for one, am hoping for focus on pulling things back to the user end at some point.
It looks like a promising first step towards the great thing we clearly need: an alternative to web. Get rid of HTTP, CSS, and HTML (well, HTML can be useful when we deal with actual _hypertext_). It would be nice to support some languages that are friendlier than JS (i.e., almost any one) though.
And once again our community snipes, takes cheap shots and shows a complete lack of appreciation for the effort in a project such as this.<p>If you have nothing of value to add, just keep quiet. Otherwise you can come across as a bit of a dick. Thanks.
I just wanne know one thing:
Will this work with older Browser?
and with older browser i mean the browser we have right now.
How hard will it be to adapt Browser vendors? or can i run it ontop like google chrome frame ?
How about some "native" browser engine video instead of Flash? Seeing all this "native" browser stuff playing in the least native format possible is not inspiring.
Interesting. I spoke about this concept at Speakerconf Munich in 2012. I'm happy someone is working on it and at the same time surprised that someone was bold enough to try. :-)
If I were to guess this is a performance-oriented version of CEF with additional functionality exposed to the JavaScript engine, would I be anywhere in the right ballpark?
) The problem I see with the browser is that:
1) It takes up hotkeys. (mouse and keyboards)
2) It can look different for different browsers
3) You have extra UI.
All those demo's run very nice in my google chrome browser. What is nidium exactly? Sorry for having a negative tone, but its a valid question isnt it?
I'm not sure how to feel about this. In some ways, I think things like HTML5, angularjs, node, and CSS3 has made coding in the browser bareable again.
the site is clearly intended to MARKET this browser. Market. They are marketing a browser.<p>I should hope the world has learned its lesson as to why a commercial browser with that kind of branding is the worlds worst horse to bet on.
Apart from local file I/O, there's nothing in that horrible presentation that a modern browser can't do.<p>Good luck with the adoption of that thing.
So, this is basically Qt/GtK/<game engine here>, but in Javascript?<p>(Not that there's anything wrong with that, mind! Just would've been a lot simpler than claiming to be a browser, and would've been less confusing.)
What makes the web great is that anyone can author a page.<p>We pushed the problem of handling these authored pages to the browser, and as a result the web flourished as millions authored content.<p>Where will the content come from when the browser does not do HTML and CSS, and is instead a native client for OpenGL?<p>The only way I believe this will work is for the authoring tools to lower the barrier so far that anyone can create content for this.