I understand that it may be a little confusing, so here is more information.
In the teaser video all visible parts are direct screen recordings of:
(1) existing 2D canvas or WebGL demos ported to NiDIUM engine
(2) shots and images from the native embedded UI Framework
Do not expect NiDIUM to read HTML pages or to compete with any existing browser.
Instead, expect a solution to build (and browse) applications, with a fast and unified look and feel.
So:
* Yes, it's a browser, in a sense that it can loads remote "apps/code" via HTTP using URLs (and somehow link them)
* Almost everything is integrated and highly customizable (like the integrated UI Framework)
* Cool APIs like plain-socket UDP/TCP (client and server), GLSL postprocessing on every canvas, layer, etc...
* We've made our best to be compliant with existing APIs (context2D, webgl, commonjs, etc...)
* It ditches HTML & CSS in favor of new things (NML and NSS, we will communicate on this later)
* Low Latency Audio and DSP (and yes, one of us come from the demo scene, hence the poor soundchip music ;-) )
We designed almost everything from scratch, but the whole thing is still at an early stage.
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.
Thanks for this update ! Looks like an interesting project, although i think this kind of information should really be on your website, and not lost in some HN comment, rather sooner than later if you want to create a bit of interest around your project.
Catchy videos are good, but in the case of projects such as yours, an associated architectural overview would be much appreciated !
>Can you mention a couple of key things that make your product diferent and desirable, instead of Flash?
It being built on standard web technologies, instead of in a proprietary engine, with a proprietary authoring environment, horrible security, subpar performance and CPU utilization and crappy or no GUI support (so you have to built everything on your own).
Built on standard Web technologies except for HTML and CSS, you mean; these are replaced by proprietary "equivalents." Which rather throws the "built on standard Web technologies" thing into some rather severe doubt.
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 (http://www.tidesdk.org/) (https://code.google.com/p/chromiumembedded/) (https://github.com/appjs/appjs) (http://www.appcelerator.com/) 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.
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 (http://en.wikipedia.org/wiki/QML) (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.
I was about to ask the same - the idea of node-webkit is awesome.
It would also be nice weekend project to create a website where the user just uploads a zip file with HTML/CSS/JS and download three executables for Linux, OSX and Windows afterwards.
Trying to imitate the drawing of native components and emulate their behavior is not impossible, but is excessively burdensome (platforms x versions x options quickly becomes large). See Java.
Having an ability to use platform-specific native components is a definite win.
If you want buttons and sliders, HTML and CSS are perfect for that. They are way easier than Qt or any other framework. Let alone whatever that new browser has in place.
Yeah, for 2D interfaces I think that HTML/CSS basically solved the problem, finally, forever. Was soooo happy to switch to web development from doing Java Swing or native toolkits and APIs.
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.
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.
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.
You can access a database locally, at least as of the past couple years. It's called IndexedDB. People quibble about the API, the features, the browser support (Firefox, Chrome and IE10 only), etc... but it is a real database you can use locally.
> Does the File API give you full access to the file system?
The File API gives you access to the files the user has selected for your access. No website-accessible API will ever give full access to anything for rather good reasons.
The File API wasn't designed with that in mind. It's built for a web browser. They wanted security for end-users. I'm not going to blame my phone for not being able to make phone calls through my TV.
Who is talking about building "websites"? Argument I think is- it should be possible to have regular file system access from a browser-like engine. That would greatly simplify building desktop applications.
Imagine you chose to build an IDE using Webkit and it lets you access everything via JS api that you could access using Cocoa or GTK+.
> wanted to be able to use the power of the browser for standalone, cross-platform desktop applications.
considering the power of the browsers is to run web applications, it makes sense that the standard and cross-platform APIs they expose are web APIs.
> Imagine you chose to build an IDE using Webkit and it lets you access everything via JS api that you could access using Cocoa or GTK+.
You've got XUL, you've got webviews, you've got node bindings for Qt, wx or opengl. If you want to write desktop applications in javascript there's no dearth of ways to do it.
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.
I cannot for the life in me understand how introducing a new browser engine deserves this kind of welcoming.
There's no evidence of hard work in this page. It's a marketing video.
I can make the same claims as them. Worse, projects with catchy colors and no substance are submitted to HN all the time.
Maybe they actually worked hard and developed a good product. But I'll believe it when I see it. HN is a playground for every marketing guy hoping to raise developer hype about his doubtful product. Why should I give anyone the benefit of doubt ?
(And even then, hard work doesn't automatically mean what you do is good or noteworthy.)
I think that people here are mostly confused. There is not really a clear explanation of what this does or anything. We are just presented with a video of things that are not exactly revolutionary and said that this is the future. This leave most of the community puzzled I would say.
It is ok to create hype for a product that is not out yet but still we would have to know what we should get hyped on.
I thought the up votes were meant to serve a way to filter out the good for the bad. If something got to the front thats outright bad then it should be flagged.
I think that people are interested, but still not sure what this is about so they upvote in hope to have answers. (or vote rigging, but I prefer to have faith in people)
I don't ridicule the work that's gone into this - I just don't get what it is... A browser engine which doesn't use HTML/CSS and which isn't in competition with Chrome/Firefox/IE...? We would just like a better explaination :)
(Edited to remove JS from the "doesn't use" list - my bad)
I cannot for the life in me understand how introducing a new browser engine deserves this kind of welcoming.
I think it's because it claims to be a browser engine yet doesn't seem to actually be one. Browsers do HTML - that's in the very definition. The project may turn out to be cool, but calling it a browser seems like calling it an OS, misleading at best.
Not to diminish any possible achievements of the Nidium team, I must mention that hard work has negative utility. Hard work is a cost, and a cost is never a desirable thing.
What counts is the result: a good result far outweighs the pains of hard work.
Currently no results can be seen. But the prospects the authors paint are rather interesting.
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:
"We will send you a maximum amount of spam as soon as possible."
The product description indeed is a bit vague, though you get the gist of what they are trying to accomplish. You might want to ask more specific questions instead of just ridiculing them. Some of us are not good at PR and those of us who are good should help others.
indeed - the video is flashy, but i only watched less than 1 minute of it, because after 1 minute, i still have no idea what they are going on about, and my time is more precious than that. Pressed stop.
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?
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.
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).
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.
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.
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.
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.
There's already a couple of these: awesomium (proprietary) and berkelium (open) that basically render Chromium to OpenGL and pass it the HID events you send.
That said, they seem to specifically say it's not an actual browser engine..
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.
I really like Qt Quick, so this seems interesting too.
[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 can 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?
Nothing is sane, just more or less functional and workable. The web seems to be ticking on just fine. There are problems, but also a lot of development.
HTML is designed for more or less static content, but the DOM itself seems well adapted for dynamic content. Since it comes out of a tradition of streaming over slow connections, it's made to be dynamically rendered. The content layout is flexible and somewhat intuitive.
Compared to something like Swing or Cocoa, the only drawback seems to be the paucity of widgets -- we basically just have basic inputs and scroll bars, the rest is app-specific. But that also brings a certain flexibility. I think an update to the table element would be great, perhaps with support for streaming data and more flexible layout.
But if you want a program you can install one, why access programs through bloated obscure web browsers? The web is a great place for sharing text of information. But why not learn from the mobile phones which provides native consistent programs for what many people have to access through some web 2.0 crap?
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.
I think the rush to make everything 'web' is primarily because we finally are building an open, free, accessible, write-once-run-everywhere platform. That's the most exciting part of the web, and privacy is a bug we still have to fix.
EDIT: When I say 'privacy is a bug', I mean the ability to provide privacy is still immature, and susceptible of exploits.
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 shot and shows complete lack of understanding for comments expressing confusion over a cryptic, unclear and fluff-filled page.
If you have nothing of value to add, just keep quiet. Otherwise you can come across a bit of a dick. Thanks.
I'm not talking about the comments from genuinely confused people, I'm talking about the nastier snipes which seem to have conveniently disappeared after myself and others called them out on it. Here's one that's still floating around: "there's nothing in that horrible presentation that a modern browser can't do".
And you're calling me a dick for calling out comments like that? Come on, please. I realise that my original comment AND this comment aren't adding any value to the conversation either, I'm just saying we aren't doing much in creating an environment where people are confident in sharing their work without fear of hours of work being instantly dismissed by snarky commenters. I'm sure you wouldn't like it.
There's little cleverness in reminding you of the plank you've got in your eye when you're looking at the dust in your brother's, but thanks nonetheless.
> Here's one that's still floating around: "there's nothing in that horrible presentation that a modern browser can't do".
The presentation is bad, and aside from this value judgement the comment expresses confusion over the improvements of the project over existing browsers.
> And you're calling me a dick for calling out comments like that?
I don't know, were you calling people dicks? So your comment was not just advising, it was passive-aggressively insulting third parties?
> I realise that my original comment AND this comment aren't adding any value to the conversation either
Indeed, have you considered practicing what you preach and leading by example?
> I'm just saying we aren't doing much in creating an environment where people are confident in sharing their work without fear of hours of work being instantly dismissed
There's little evidence of such a thing here, there's a marketroid video with a fluffy and empty title.
Meanwhile a few links below on the front page (at this time) you've got https://news.ycombinator.com/item?id=6314730 which shows an actual project with a number of interested comments, none of them negative as far as I can see.
Even https://news.ycombinator.com/item?id=6314310 which looks nothing special at first glance garners mostly positive comments (or more neutral ones talking about the space/ecosystem, wondering about it v alternatives, etc...) with a downvoted negative comment whose author readily agreed being wrong when his mistake was pointed out.
> I'm sure you wouldn't like it.
I don't mind marketing copy and email harvesting schemes getting slammed. Especially when advertised as a "show HN" with no show and little tell.
I find it amusing that you're happily sniping away while trying to appear all holier than thou. There's not much point in us discussing what isn't there anymore, it's just making my original point look irrelevant which you keep alluding to. But again, you weren't there when the original sniping was going on and promptly removed.
So save your "practice what you preach" and other cliches for someone else because this pointless conversation is becoming a parody of itself.
And don't bother replying because you clearly have more time for this than I have. You're just itching for an argument where there isn't one to be had, and it's clearly killing you because you keep coming back.
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?
The memory is obviously not shared (handling memory barrier / mutex in JS would be too annoying). However, it uses inter-thread communication using structured clone (https://developer.mozilla.org/en-US/docs/Web/Guide/DOM/The_s...) or object stealing where you send an object to a thread with a zero-copy advantage but lose its content/ability to use it from the "sending thread"
In the teaser video all visible parts are direct screen recordings of:
(1) existing 2D canvas or WebGL demos ported to NiDIUM engine
(2) shots and images from the native embedded UI Framework
Do not expect NiDIUM to read HTML pages or to compete with any existing browser.
Instead, expect a solution to build (and browse) applications, with a fast and unified look and feel.
So:
* Yes, it's a browser, in a sense that it can loads remote "apps/code" via HTTP using URLs (and somehow link them)
* Almost everything is integrated and highly customizable (like the integrated UI Framework)
* Cool APIs like plain-socket UDP/TCP (client and server), GLSL postprocessing on every canvas, layer, etc...
* We've made our best to be compliant with existing APIs (context2D, webgl, commonjs, etc...)
* It ditches HTML & CSS in favor of new things (NML and NSS, we will communicate on this later)
* Low Latency Audio and DSP (and yes, one of us come from the demo scene, hence the poor soundchip music ;-) )
We designed almost everything from scratch, but the whole thing is still at an early stage.
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.
We will post updates as soon as possible!