Current state of GUI stuff?
Jann Horn
I'm thinking about how to design some apllication, and I really want
to write as much code as possible in node. However, a nice user
interface is very important for it, too. Also, it needs to be runnable
on all major operating systems. I'm thinking about whether it's going
to be feasible to do the GUI stuff (a bunch of windows, I need to be
able to spawn new windows, it'd be nice to have a notification bar
icon, ...) in node. If not, I might use Java for that and do a
connection over localhost, but I really want to avoid that. So, what
can I use?
- node-webkit looks nice, but I think it might be slow and is ugly
because it uses DOM. Also, it currently requires me to manually patch
webkit code for installing and I think it doesn't run on Windows yet
- there's a bunch of attempts to do GTK bindings, but most of them
seem to be pretty old and unmaintained - however, node-gui looks
promising to me, and according to the README, it also works on Windows
What's your opinion? Anything important I didn't consider? Are there
any bigger examples of GUI code written in node I could look at?
Jann
Tim Caswell
front-end is written in the same language as your backend and
debugging is often much easier. You just need to get some good
front-end devs who know how to make it pretty.
I too want native apps in node that work cross-platform. node-webkit
has promise, but it's a long ways off. GTK is a mess and I don't
think any of the bindings are complete or up to date.
One easy solution is to just use chrome with the -app flag or
mozilla's chromeless for the gui. Sure it's a browser, but it looks
more native.
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
Brandon Benvie
Jann Horn
> Don't underestimate the value of HTML and dom based guis. Your
> front-end is written in the same language as your backend and
> debugging is often much easier. You just need to get some good
> front-end devs who know how to make it pretty.
Huh? What does using the same language have to do with that? As long
as I can use the different kinds of frontends from node, it should be
no problem, right?
> I too want native apps in node that work cross-platform. node-webkit
> has promise, but it's a long ways off. GTK is a mess and I don't
> think any of the bindings are complete or up to date.
Mmmhm... probably true.
> One easy solution is to just use chrome with the -app flag or
> mozilla's chromeless for the gui. Sure it's a browser, but it looks
> more native.
Yes, that's probably a relatively good meantime solution - however,
I'll probably have to write something ugly to access the DOM from
node...
Axel Kittenberger
> I'll probably have to write something ugly to access the DOM from
> node...
Without knowing your App in detail you don't need to. The tendancy is
to write the server-end in node only caring for the things you need
the server for, and the frontend in Browser Javascript which does all
the markup. Then have both communicate with each other via JSON. You
should not need to access some DOM specifics from node. Of course you
can easily do your JSON-based call to do that, but it would be far
more elegant to have the communication on a more abstract level.
Instead of for example server saying "write headline, make it bold,
and red, and write warning", you just send "{cmd: warning}" and have
the browser client do the markup.
Jann Horn
Hmm, looks interesting, too. Please post about whether it worked. :)
Michael Anderson
I wish I had the javascript experience to write this right now!
One of my favorite scripting languages is Tcl/Tk, so I thought about using Tk to do the GUI stuff.
But then using Tk would NOT work very well in a Web environment, so I've considered writing some Tcl socket logic to drive the Web browser from the server.
Then I tripped over a Google Talks session with Ryan Dahl, about Node, maybe two months ago. So I'm behind you guys here in more than one way.
With the concept of Node, and the latest additions to HTML5 and CSS3 this GUI complexity can be done away with.
The current state of GUI development is chaotic at best.
What Ryan did on the Server Side, needs to be done to the GUI now.
In large enterprise applications a large percentage of programming effort goes into the GUI, it is ridiculous.
I've learned that GUI development in many environments, is overly complicated.
The reason is because GUI's are just hard to get right, and their are too many opinions of how to do it,
too many various libraries for GUI stuff, many of them reinvented to try to do it better.
Like, hey lets solve all the worlds GUI problems, and thats is the main problem.
It Is Complicated! However, over the last decade or so, we've been watching the Browser evolution,
and the browser guys have the most experience with GUI failures, and you don't want to relive all their agony.
Therefore it is the browser guys that you should follow and using the browser to present your GUI is the path of least resistance.
The browser guys have done all the heavy lifting for you already.
Believe me, you don't want to reinvent all of that GUI stuff that they have done, failed and redone, many times over again and again, for many years.
It will take you years to get where they are today!
Jann,
I think you are on to something when you say you want to do as much as possible in Node.
But all that ugly DOM stuff you mentioned, that must stay in the DOM, don't put any of that in Node on the server.
Do something that is absolutely awesome, try to imagine this:
Keep in mind that this is all theory, and not proven, but I believe it is doable.
It will basically turn the current GUI concept on its head, where it should be, kind of like it was many years ago.
Instead of having the DOM control the server, have the server drive the DOM.
Simply by sending/receiving JSON with Asynchronous, bidirectional, Web-socket I/O, much like what Alex said.
This can work as long as the JSON data contains only meta-data, no actual DOM syntax, very small,
and the communication is Asynchronous, bidirectional, Web-socket I/O.
To break it down a little more, here the term "you" refers to Node on the server.
So, from Node (on the server) you tell the DOM (browser) what to do, using only meta-data (no DOM syntax) in a JSON data format.
Like Initialize the DOM/GUI, update the data buffer (Text inputs), change an element, Callbacks to Wait for a DOM event,
sending and receiving, to/from the DOM nothing but JSON data to describe exactly what you are asking the DOM to do,
or ask the DOM to tell you about events, get data enter by the user edit and send it back to the DOM. So it will be Node on the server telling the DOM what to do,
and Node on the server asking the DOM for specific information or data. Because you tell the DOM what events you want to know about, and elements you want to manage.
Application developers can get out of the fashion business,
fashion being colors, fonts and graphics, the team that is working on the DOM can do whatever they want with css and html, as long as they support your Send/Receive requests.
I think the cool thing about something like Node is you can use this same Webapp theory to build a Desktop apps or maybe even a mobile apps.
Using the XULRunner or Chromeless concept your desktop app can be written in %100 javascript, using HTML and css initially.
If Chromeless doesn't work, fork a copy of an make it work, chromeless its probably closest to the mark, as XULrunner requires more than pure HTML.
The an application starts up, during initialization it can start it's own Node http server, underneath, on the same box, laptop, desktop, or whatever.
So you end up with a %100 web based, desktop app. Then when ever you want, you can move the Node http server, and application part off the desktop and
on to a server, from desktop to instant multiuser (Client/Server) Web style application.
If this doesn't make sense, they try to forget everything you know about application programming, and read it again.
For example: to break it down even more:
For meta-data storage use something like Sqlite or Mongo or whatever, just some storage with a small foot print, kept anywhere as long as (Node) has access to it.
Then I envision several mainstream functions will be written using Node on the Server.
Then similar or complimenting functions are to be written for the DOM side for all of this to work.
Examples of the Server side could be something like the following:
DomInit:
This will create a new JSON object containing the meta-data for elements on a page, and the ID's or name's of all DOM events the server whats to know about.
So you can have many events occur on the DOM side that don't concern the Server side at all.
When a "DomInit" JSON object is sent to the DOM, then javascript on the DOM should remove any/all existing elements from a previous DomInit, before creating new elements found in the JSON object.
DomShutdown:
Send JSON to DOM instructions to Shutdown, note:In this case the end user may only see a parting message,
like "later dude, come back soon" or "Session ended, Connect CPU=3, Elapsed time=2,375 seconds"
DomHide:
Send JSON to DOM, instructions to Hide everything, all DOM elements including the Dom itself.
DomUnhide:
Send JSON to DOM, instructions to Unhide everything.
DomGetnextPage:
Send/Receives nothing, Gets a new meta-data from storage, based on an ID or Name.
DomOpen:
Send/Receives nothing, Opens database or object that contains all your DOM meta-data.
DomReadElements:
What you would receive from the DOM (browser) would be JSON data describing the DOM,
all elements that have a data property and each elements data value, the ID or name of the last DOM event that occurred,
like element.clicked or window.closed, and so on.
DomWriteElements:
Send JSON to DOM, the data and property values of all DOM elements that have a data property.
For example: same stuff received from DomReadElements, only on the server you've modified some properties, added or removed some elements.
So DomWriteElements sends this back to the DOM where the DOM javascript processes it, applying the changes.
Instead of the last event as in DomReadElements, here we want to send the ID's or name's of all DOM events the server whats to be informed of.
So you can have many events occur on the DOM side that don't concern the Server side at all.
DomOpenWindow:
Send JSON to DOM, instructions to open a new window.
DomCloseWindow:
Send JSON to DOM, instructions to close a new window.
Their are many more functions, but you get the basic idea,
so you could imagine many others to do more specific things to the DOM.
Keep in mind the only data going through the sockets is JSON, no actual DOM syntax.
Another issue is simplicity, it must simple and easy to understand.
A minimal set of functions to put you GUI on the browser, for example:
Two functions needed at start:
DomOpen("some_database_name");
DomOpenWindow(passing Some Window geometry, returning some Window ID);
Three functions to put your GUI on the browser:
DomGetnextPage(somePageName); // returns a JSON-DOM object as meta-data is found in the database.
DomInit(JSON-DOM); // Send {DomInit: "JSON-DOM"} to the DOM, specifying the Window-ID.
DomReadElements(returning an event) // based on the list of events in the JSON-DOM sent by DomInit.
Depending on what event occured:
DomGetdata(somebuffer);
I could write the manual on this, layout the database structure, but I would need help with the javascript.
Also this could be done using Tcl on the server, but I think node would be cleaner, and better in the long run.
I like to collaborate with anyone on the same page,
--
Mike.
blake
> Tk to do the GUI stuff.
> But then using Tk would NOT work very well in a Web environment, so I've
> considered writing some Tcl socket logic to drive the Web browser from the
> server.
There's been a Tcl/Tk web plugin for over a decade. (I don't think
it's been updated for years, OTOH.)
Michael Anderson
> There's been a Tcl/Tk web plugin for over a decade. (I don't think
> it's been updated for years, OTOH.)
>
Yeah, I should have been more specific, it works, but not in all cases.
--
Mike
Axel Kittenberger
This is all micromanaging the client from the server. It will work I
wont deny that, but it comes with a few drawbacks. Bandwidth Load,
Sending every single DOM setting and change from server to client
causes more bandwidth, response time, anything you change needs a
client<->server communcation, leaving the user a worse responseviness
feeling, development encapsulasion, having client/server be more
seperate things where the former cares about the updates is better in
seperating the tasks for development. Its like doing an online game,
and instead of the server sending the client proper changes of the
virtual world for it to render properly, it would instead in analogy
to setting each and every DOM paramter from server provide a 2D movie.
If you need to keep at this strict server controlled design, just
generate webpages all over, like in the old pre-ajax web, instead of
making micro calls to the DOM.
Angel Java Lopez
Michael Anderson
I'm not very good at explaining things, many have told me this.
But you really miss understood me.
On Sun, 2012-02-12 at 10:33 +0100, Axel Kittenberger wrote:
> > Examples of the Server side could be something like the following:
> > [....]
>
> This is all micromanaging the client from the server. It will work I
> wont deny that, but it comes with a few drawbacks. Bandwidth Load,
> Sending every single DOM setting and change from server to client
> causes more bandwidth, response time, anything you change needs a
> client<->server communcation, leaving the user a worse responseviness
> feeling, development encapsulasion, having client/server be more
Bandwidth, load, responsiveness, communication, are all derived from one
drawback, "performance" And I must disagree with you on this. I'm
talking about less than 2k per each send/recv, in most cases less then
100 bytes. Hardly a nanogram compared to something like a game or a
movie. I'm talking about Enterprise business applications, where the
data buffers are usually less than 2k. Additionally, I've done some
testing, in an intra-net environment doing straight socket I/O it is
extremely fast. Over an Internet connection it does very well. I
estimate about 30 to 50 round-trip updates between the client and the
server per second. Now thats not using Node, thats all ANSI C (not c++)
and socket calls. My understand is that after the initial http handshake
Node can do standard socket calls outside of the http protocol, so it
shouldn't be much slower at all.
> seperate things where the former cares about the updates is better in
> seperating the tasks for development. Its like doing an online game,
> and instead of the server sending the client proper changes of the
> virtual world for it to render properly, it would instead in analogy
> to setting each and every DOM paramter from server provide a 2D movie.
I think you're saying that separating the GUI development from the
application development is a bad thing. The way you ran all those
mis-spelled words together, its not real clear what you're saying. But,
if this separation is a bad thing too you, then again I strongly
disagree! I think you totally misunderstood my point. But I have an
analogy also, Data Base Management Systems.
Lets roll the clock back about 40-50 years. Application developers at
that time didn't have allot of Database systems to choose from. They
simply rolled their own databases, handling their own indexes, wrote
their own hash tables, and so on. Starting in the 1960's IBM developed
the first Navigational database, then hierarchical databases, and
network databases. It was almost 1980 when we saw the first SQL
database. Still there were application programmers who continued to roll
their own, because it was faster, maybe. More so because people don't
like to make a change when what they have is working just fine. People
generally don't get it, like whats the advantage, or thats not what I
was taught. Today the average programmer reads/writes data from a
database without much concern about how it all works, that is someone
else's job. The programmer simply uses a small amount of information
about the data (meta-data), and requests the data.
Similar scenario can be said about data communications or Network
programming. Node.js definitely proves that!
If you don't understand what the database problem was back then, and you
don't understand why they fixed it, then I am wasting my time. So the
industry fixed the database issues, and fixed the Networking issues. The
UI back then was simple, literally is was read and write, but today it
is a problem, its chaotic, it not standardized, its allot of roll your
own. Somehow this too must get fixed!
Wouldn't it be nice if a programmer could converse with a GUI by simply
writing something like:
Select * on Inventory-Screen;
If sort-by-partnum was clicked then do the sort logic.
Or if Enter was clicked then do the logic to process the data buffer.
Now Axel, come on. In your opinion it would be faster to rebuild the
entire GUI or page? What I'm saying is, only send whats changed, in this
case it is the data buffer, and no doubt less than 1k bytes. Why send
and rebuild the entire GUI or page? Sending the entire thing is what I
want to avoid. Also, on the server, I'd like to avoid creating and tare
down a processes every time the user clicks on a button.
If I had the server side Node functions working as I explained (or tried
to explain) in my earlier post, then I could develop the glue between
the app and Node so the App would only need that one line to interact
with a full blow GUI in a Web environment.
Developing GUI Business applications would be drastically less
expensive, or maybe programmers could make more money in less time.
> If you need to keep at this strict server controlled design, just
> generate webpages all over, like in the old pre-ajax web, instead of
> making micro calls to the DOM.
>
You really miss understood me!
Mark Hahn
Jann Horn
> +1 for server (node) micro-managing through websockets. I'm using that and
> the UI is very responsive, more so that the old ajax days. The client is
> less loaded and the response is on the order of msecs.
Is there some open-source code for that?
Axel Kittenberger
> drawback, "performance"
Thats throwing vastly different things into one bucket deliberately
blurring up instead of precising things. Responsiveness, (server) load
and bandwidth are completey different bottlenecks.
> I think you're saying that separating the GUI development from the
> application development is a bad thing. The way you ran all those
> mis-spelled words together, its not real clear what you're saying. But,
> if this separation is a bad thing too you, then again I strongly
> disagree! I think you totally misunderstood my point. But I have an
> analogy also, Data Base Management Systems.
I wonder how you come to this reading. You really misunderstood, doing
this very much words complaining being misunderstood when you
misunderstand. Reading your post again, yes I did partially
midunderstand, all you interface has nothing to do with DOM. You seem
to mix up data and DOM. I said, having GUI development and server
development separated is often better in sense of encapsulating. And
the database analogy is very faulty. When you could compare it to some
of the Oracle PSQL variants, where GUI development and database
development was essentially thrown into being one thing. I consider
this unfortunate. IMHO database design and GUI design should be two
different things. Having specific calls to get what data is fine.
However, I consider it better design, when the client has the final
say on the markup instead of server managing everything.
PS: I know its the internet where kindness is optional, but you should
work on your attitude.
Mark Hahn
Liam
terminal & host, users will notice the response delay, so this
approach is only suited to LAN or PAN contexts.
Jann Horn
> On a public Internet link with a 40ms round trip time (common) between
> terminal & host, users will notice the response delay, so this
> approach is only suited to LAN or PAN contexts.
True, but in the context of this thread (GUIs for node apps running on
localhost), that shouldn't be a problem.
Matt Patenaude
Unfortunately, the code is a bit old and never was quite right on Windows (this was pre-0.5 Node, the only Windows support was through Cygwin), and is way too messy/encumbered in project-specific code to be released, but it's certainly a feasible and not even all that challenging option!
-Matt
Jann Horn
> Of course, running localhost you can do even a little bit better than WebSockets. I once threw together a small app in Qt that wrapped WebKit, with a JavaScript API for message passing. Node could launch the app, or the app could launch Node, but either way, the two could then communicate with each other over stdin/stdout. It worked quite well, really!
>
> Unfortunately, the code is a bit old and never was quite right on Windows (this was pre-0.5 Node, the only Windows support was through Cygwin), and is way too messy/encumbered in project-specific code to be released, but it's certainly a feasible and not even all that challenging option!
Did you see node-webkit? It's a newer project, and it gives you node
bindings inside of the browser. Unfortunately, no windows support yet,
and you have to apply a bunch of webkit patches manually.