Re: [nodejs] My desk is URDESK (a very good client for node)
But it have "Powered By Google" and a Chrome logo, what could possible go wrong? -- Att, Alan Hoffmeister 2014-02-10 18:30 GMT-02:00 Mark Hahn : > It is tl;dr for me and there is no way I'm going to a web page and clicking > on a button called "install me" with no indication of what is being > installed. > > > On Mon, Feb 10, 2014 at 12:18 PM, Dennis Kane wrote: >> >> (If this is tl;dr, just go to http://urdesk.net right now) >> >> What does it mean for something to be "a good node client"? >> >> When I think of a client for node.js, I think of a dynamic user experience >> that doesn't really require any page refreshes, and that stirs up a whole >> bunch of good feelings as regards what is possible on the web. >> >> I started thinking about web programming in the mid-2011 time frame. I >> wanted to see how far I could push the concept of a dynamic user experience. >> Fast forward to February 10, 2014 (today), and I think that my original >> vision has finally come to fruition. Starting in September 2012, I began >> working on the current incarnation. My idea was to go "all in" by way of >> seeing if I could duplicate the OS X end user experience inside of a web >> browser... all courtesy of Google's V8 JS engine running inside of standard >> Chrome. Since that time, I've put in about a full year's worth of 8-12 >> hour coding days. Here is the basic setup: >> >> There is a core desktop module that performs all of the essential system >> level operations: window, icon, context menu, menubar, and toolbar GUI >> operations, as well as all of the interactions with Local Storage and the >> filesystem API. >> >> There are several self-contained modules of which the core has no >> knowledge that plug into the system through a basic interface. The most >> important of these modules are the Unix-style text editor (called Nanim) and >> the command-line interface. There are other, graphical modules that I've >> spent relatively small amounts of time developing, such as a media player >> and a prototype-phase word processor. >> >> There are several ways of thinking about the system. Most obviously, I >> think that it pushes the envelope in terms of how we understand the notion >> of an operating system. Such a thing has traditionally been written in >> native code, and has required a fairly sizeable cost to download, install, >> replace, etc. (What I mainly mean by "cost" is NOT the purchase price, but >> rather the potential for catastrophe if the installation procedures are not >> followed precisely. So by this definition, we can judge the commercial OSes >> to be much cheaper that all of the Linux distributions that require one to >> do things such as partition hard drives and install custom boot loaders to >> try them out.) >> >> We can call the OS that I've developed a trivially loadable/bootable OS. >> The only investment that it currently requires comes in the form of >> accepting the browser's "this site wants to permanently store data on your >> computer" prompt, and then waiting the minute or so for all of the resources >> to download. After that, everything is served locally, meaning that a >> network connection is not necessary for it to load. Furthermore, given that >> all of the locally stored data is essentially namespaced by the domain name, >> one can have many OS environments running alongside each other in different >> tabs of the same browser, with the caveat that each tab is must use a >> different subdomain (this just means that all of the resources owned by >> www.urdesk.net essentially live in a sandboxe, safely hidden away from, eg. >> dev.urdesk.net... or any other subdomain of urdesk.net). >> >> In this way, there is essentially zero cost involved when it comes to >> experimenting with a new OS, and trying out all of the different >> applications contained within it. Application developers will be able to >> write their logic without having to worry about distribution problems, given >> that it will be guaranteed to run on any Chrome browser, thereby eliminating >> all issues related to downloading (and the related issue of viruses), >> plugin-installing, flag-enabling, etc. >> >> The next level of thinking about the system is that the applications are >> not traditional "applications" in the sense that they run as different >> native processes, and thereby keep their data structures in mutually >> exclusive address spaces. In this system, there are precisely zero issues of >> interprocess communication (IPC). All "applications" are actually just >> JavaScript function objects that collectively inhabit a single browser tab >> address space. All complications traditionally related to IPC now become >> null and void. Given this fact, the possibilities in terms of the >> development of a holistic kind of user experience increase profoundly. (As a >> trivial example of this, imagine your calendar app being aware of what you >> are typing into your word processor and adjusting itself a
Re: [nodejs] My desk is URDESK (a very good client for node)
It is tl;dr for me and there is no way I'm going to a web page and clicking on a button called "install me" with no indication of what is being installed. On Mon, Feb 10, 2014 at 12:18 PM, Dennis Kane wrote: > (If this is tl;dr, just go to http://urdesk.net right now) > > What does it mean for something to be "a good node client"? > > When I think of a client for node.js, I think of a dynamic user experience > that doesn't really require any page refreshes, and that stirs up a whole > bunch of good feelings as regards what is possible on the web. > > I started thinking about web programming in the mid-2011 time frame. I > wanted to see how far I could push the concept of a dynamic user > experience. Fast forward to February 10, 2014 (today), and I think that my > original vision has finally come to fruition. Starting in September 2012, I > began working on the current incarnation. My idea was to go "all in" by way > of seeing if I could duplicate the OS X end user experience inside of a web > browser... all courtesy of Google's V8 JS engine running inside of standard > Chrome. Since that time, I've put in about a full year's worth of 8-12 > hour coding days. Here is the basic setup: > > There is a core desktop module that performs all of the essential system > level operations: window, icon, context menu, menubar, and toolbar GUI > operations, as well as all of the interactions with Local Storage and the > filesystem API. > > There are several self-contained modules of which the core has no > knowledge that plug into the system through a basic interface. The most > important of these modules are the Unix-style text editor (called Nanim) > and the command-line interface. There are other, graphical modules that > I've spent relatively small amounts of time developing, such as a media > player and a prototype-phase word processor. > > There are several ways of thinking about the system. Most obviously, I > think that it pushes the envelope in terms of how we understand the notion > of an operating system. Such a thing has traditionally been written in > native code, and has required a fairly sizeable cost to download, install, > replace, etc. (What I mainly mean by "cost" is NOT the purchase price, but > rather the potential for catastrophe if the installation procedures are not > followed precisely. So by this definition, we can judge the commercial > OSes to be much cheaper that all of the Linux distributions that require > one to do things such as partition hard drives and install custom boot > loaders to try them out.) > > We can call the OS that I've developed a trivially loadable/bootable OS. > The only investment that it currently requires comes in the form of > accepting the browser's "this site wants to permanently store data on your > computer" prompt, and then waiting the minute or so for all of the > resources to download. After that, everything is served locally, meaning > that a network connection is not necessary for it to load. Furthermore, > given that all of the locally stored data is essentially namespaced by the > domain name, one can have many OS environments running alongside each other > in different tabs of the same browser, with the caveat that each tab is > must use a different subdomain (this just means that all of the resources > owned by www.urdesk.net essentially live in a sandboxe, safely hidden > away from, eg. dev.urdesk.net... or any other subdomain of urdesk.net). > > In this way, there is essentially zero cost involved when it comes to > experimenting with a new OS, and trying out all of the different > applications contained within it. Application developers will be able to > write their logic without having to worry about distribution problems, > given that it will be guaranteed to run on any Chrome browser, thereby > eliminating all issues related to downloading (and the related issue of > viruses), plugin-installing, flag-enabling, etc. > > The next level of thinking about the system is that the applications are > not traditional "applications" in the sense that they run as different > native processes, and thereby keep their data structures in mutually > exclusive address spaces. In this system, there are precisely zero issues > of interprocess communication (IPC). All "applications" are actually just > JavaScript function objects that collectively inhabit a single browser tab > address space. All complications traditionally related to IPC now become > null and void. Given this fact, the possibilities in terms of the > development of a holistic kind of user experience increase profoundly. (As > a trivial example of this, imagine your calendar app being aware of what > you are typing into your word processor and adjusting itself according.) > > And finally, this system allows for the emergence of a fundamentally new > paradigm in terms of how we relate to our computers. I have actually had a > much longer history developing AI-type command-and-response syst
[nodejs] My desk is URDESK (a very good client for node)
(If this is tl;dr, just go to http://urdesk.net right now) What does it mean for something to be "a good node client"? When I think of a client for node.js, I think of a dynamic user experience that doesn't really require any page refreshes, and that stirs up a whole bunch of good feelings as regards what is possible on the web. I started thinking about web programming in the mid-2011 time frame. I wanted to see how far I could push the concept of a dynamic user experience. Fast forward to February 10, 2014 (today), and I think that my original vision has finally come to fruition. Starting in September 2012, I began working on the current incarnation. My idea was to go "all in" by way of seeing if I could duplicate the OS X end user experience inside of a web browser... all courtesy of Google's V8 JS engine running inside of standard Chrome. Since that time, I've put in about a full year's worth of 8-12 hour coding days. Here is the basic setup: There is a core desktop module that performs all of the essential system level operations: window, icon, context menu, menubar, and toolbar GUI operations, as well as all of the interactions with Local Storage and the filesystem API. There are several self-contained modules of which the core has no knowledge that plug into the system through a basic interface. The most important of these modules are the Unix-style text editor (called Nanim) and the command-line interface. There are other, graphical modules that I've spent relatively small amounts of time developing, such as a media player and a prototype-phase word processor. There are several ways of thinking about the system. Most obviously, I think that it pushes the envelope in terms of how we understand the notion of an operating system. Such a thing has traditionally been written in native code, and has required a fairly sizeable cost to download, install, replace, etc. (What I mainly mean by "cost" is NOT the purchase price, but rather the potential for catastrophe if the installation procedures are not followed precisely. So by this definition, we can judge the commercial OSes to be much cheaper that all of the Linux distributions that require one to do things such as partition hard drives and install custom boot loaders to try them out.) We can call the OS that I've developed a trivially loadable/bootable OS. The only investment that it currently requires comes in the form of accepting the browser's "this site wants to permanently store data on your computer" prompt, and then waiting the minute or so for all of the resources to download. After that, everything is served locally, meaning that a network connection is not necessary for it to load. Furthermore, given that all of the locally stored data is essentially namespaced by the domain name, one can have many OS environments running alongside each other in different tabs of the same browser, with the caveat that each tab is must use a different subdomain (this just means that all of the resources owned by www.urdesk.net essentially live in a sandboxe, safely hidden away from, eg. dev.urdesk.net... or any other subdomain of urdesk.net). In this way, there is essentially zero cost involved when it comes to experimenting with a new OS, and trying out all of the different applications contained within it. Application developers will be able to write their logic without having to worry about distribution problems, given that it will be guaranteed to run on any Chrome browser, thereby eliminating all issues related to downloading (and the related issue of viruses), plugin-installing, flag-enabling, etc. The next level of thinking about the system is that the applications are not traditional "applications" in the sense that they run as different native processes, and thereby keep their data structures in mutually exclusive address spaces. In this system, there are precisely zero issues of interprocess communication (IPC). All "applications" are actually just JavaScript function objects that collectively inhabit a single browser tab address space. All complications traditionally related to IPC now become null and void. Given this fact, the possibilities in terms of the development of a holistic kind of user experience increase profoundly. (As a trivial example of this, imagine your calendar app being aware of what you are typing into your word processor and adjusting itself according.) And finally, this system allows for the emergence of a fundamentally new paradigm in terms of how we relate to our computers. I have actually had a much longer history developing AI-type command-and-response systems than I have had developing user interfaces. Within the command-line interface, there is a working prototype of a natural language REPL (read/eval/print loop) that accepts the kind of syntax that the most naive of end users would not find intimidating in the least. You must understa
