The future is written in Javascript

Posted on by • 9 comments

There are a lot of programming languages, but there is only one that runs in your web browser, and that’s Javascript. Ruby, Java, C#, Python, PHP and dozens more are used to write software for the web but in the end they all produce HTML and Javascript, and HTML is not a programming language. That means that there’s only one programming language for the web, and that’s Javascript.

If you’re writing software for the web, you’re programming in Javascript, it’s just a matter of how many layers of “comfort zone” there is between you and your application.

But what about the servers?!?
Fine, great, the future of user interface might be written in Javscript, but what about the server code?

If you’re a web developer you have of course heard of Node.js (if you haven’t, you can get the scoop here). The short of it is that you can now write your server code in Javascript as well as your client-side code, and Node.js has been around long enough to have proven that it has the necissary ingredients (performance, scalability and security) to function in a production environment.

That being the case, why would you spread your focus accross multiple languages to write a web application? Some will argue that Javascript isn’t appropriate for writing server-side code, that there is something in the nature of the language or the runtime that just isn’t right. I argue that this is patently incorrect, and the only way to arrive at such a conclusion is to have an inaccurate or incomplete understanding of the Javascript language.

Javascript has been designed from the beginning to work in the event-driven environment of the browser and excels at asyncronous processing. There was a time where this was not a useful feature for server-side web software, but since the proliferation of AJAX techniques the old “page at a time” method of server-side processing has gone by the wayside.

Beyond the technical or implementation-level featurs that make Javascript suitable for these tasks is the philosophy of the language and its constructs that lead the developer into an event-driven way of thinking. Once embraced, this mode of thought changes the way a developer designs applications and opens them up to new ways of providing better, more responsive and more engaging experiences to users.

But the future isn’t all on the web right? What about mobile?
The future of mobile is Javascript as well.

This isn’t a radical idea, in fact Apple knew this when the first iPhone was introduced back in 2007. Until 2008, the only way to write software for the iPhone (unless you were an internal Apple developer) was to write it in Javascript in the form of “Web Apps“. Early on, there was no indication that Apple would ever open up the iPhone to allow third-party developers to write “native” applications for the iPhone, and the fact that Apple provided Javascript API’s to access device features in these early versions of iOS is evidence that they saw the potential of delivering fully-functional Javascript-based applications to mobile devices (why did Apple change directions? That’s another story).

Since then, the number of device features that have been made accessible via Javascript API’s has grown, and technologies like Websockets and WebRTC make writing Web Apps that rival native applications even easier, and that’s just the tip of the iceberg. With the introduction of FirefoxOS (also known as “Boot to Gecko” or B2G), there is now a platform where Javascript and native code applications are on equal footing (a predecessor with a similar philosophy is WebOS), and by equal I mean feature parity, however Javascript has several distinct advantages.

Developers, Developers, Developers
There is no other language with more developers using it than Javascript (remember the first few paragraphs where we talked about how all web developers are writing Javascript?). This means that, all else being equal, the potential of Javascript applications is orders of magnitude higher than “native” applications based on the sheer number of developers with decades of experience behind them. What’s more is that these same developers have been on the cutting-edge of creating compelling user experiences (much of the original use of Javscript was to provide realtime feedback and event-driven user interface elements). These developers have been sidelined on mobile platforms by restricted subsets of device features or second-class integration into the user experience. With B2G, a whole new army of developers will be able to build great applications for mobile, and as the iPhone has proven, great user experiences drive the platform.

Developer productivity and other excuses
There is a case to be made that other languages, frameworks, etc. are more than up-to-the-task of creating compelling experiences on the web (and beyond), and that these tools and platforms lend themselves to increased developer productivity. I could dispute these points as well but instead I’ll agree, that any language can be used to generate HTML and Javascript and return it to a browser for processing, and that frameworks and toolkits and the like can make creating applications more convinient for programmers unfamiliar with raw Javascript and it proper use. I’ll even go so far to say that anything you can find on the web today could probably be created using any of these toolsets, and if you have those tools (or those trained in those tools) at your disposal then you can probably get more done faster by using what you know.

However, this essay is about the future, and if there’s anything certain about the future it is that you can’t build it within the restrictions of models from the past. If you’re using a toolset it is a fact that creating something that wasn’t considered when the toolset was designed will be difficult if not impossible, and in either case will doing so will compromise your vision.

Javascript is the most complete programmatic interface avaliable to web-based applications. Instead of mastering analogies and metaphores that insulate the developer from the platform (and often mask its most exciting features), time spent embracing this single language allows a developer to not only create what is known, but to invent future applications and techniques that have not yet been imagined by the authors and architects of today’s convinience frameworks.

This, coupled with the ever expanding list of exciting new technology that is programmable using javascript is what I mean by “the future is written in Javascript”.

Easier said that done (or, “how do we get there from here?”)
Understanding and even accepting this philosophy is one thing, but how to transition from an existing application, or from previous experience, to Javascript-based development? The path will varry for every developer and each application, but what I can do is share the path that I have personally embraced.

Learn the code
Most web developers have used Javascript code directly, and many have even written it, but few have taken the time to learn Javascript as a language unto itself. Read a good book and learn Javascript as if from scratch. Take care to learn the good parts, and learn how to avoid the bad parts.

Write Javascript programs in an environment where you won’t get hung-up on dealing with the browser and its DOM or third-party Javascript libraries (Node.js is a great environment for this).

Draw a line in the sand
Javascript fits more naturally on the front-end than on the back end, and the proliferation of REST and JSON-based API’s makes implementing user interfaces in Javascript much easier than it was in the past. Begin here by building directly against these interfaces using client-side Javascript code, and resist the urge to leverage frameworks and libraries whenever possible.

Partition your existing applications by implementing a Hypermedia API. Use this as a “firewall” to push existing code behind a clean surface to attach a Javascript client to. Refactor the code behind the API over time and eventually replace it with service calls built on Node.js.

Learn a new platform
Start developing for FirefoxOS, or develop Web Apps for other platforms. iOS provides decent support for making Web Apps behave like native apps (including launcher icons and full-screen modes that hide browser chrome). Android provides a rich set of Javascript-accessible device API’s as well, but for the full experience FirefoxOS is really the way to go (in fact all of the built-in software is written this way).

There are as many paths over the mountain as there are developers, but the first step is to look at Javascript not as an inconvinience or a compromise, but as an elegant solution to a complex problem. A language which is encumbered with demons from its past, but which are only harmful to those who know not how to avoid them.

Any of the steps above can be the beginning of this understanding, and all of them can lead to building the applications of the future, with Javascript.

Category: Crystal Ball, Software | Tags: , , , , , , ,

Home Dashboard

Posted on by • 1 comment

This morning I was just noodling on an idea to put some of the idle hardware we have around the house to use.

Old computers, tablets and even new things like TV’s, etc. have network capabilities and embedded web browsers. I’d like to create a simple household “dashboard”, that would display information useful around the house (temperature (inside), weather (outside), status updates from occupants, etc.). It would be implemented in html/javascript so that it could be displayed on anything capable of running a reasonable web browser.

Architectually, I’m thinking a static html/javascript page that gets its data by polling other services via ajax calls. These services can be local computers, remote servers or even devices capable of emmiting status data (or consuming control requests) over the local network. To this end, it might be interesting to use uPNP or zeroconf to discover these devices.

I don’t know of a way to do either of those things from javascript however, so it might be necissary to create a program or script that runs on a “proper” computer to generate the dashboard page. This could be as simple as a python script that polls the local network for avaliable services and then creates a menu of these devices and other pre-defined sources of information (weather service, calendar service, etc.) that can be selected and then spit out an html page that can be loaded on the various screens and devices that display the dashboard.

I imagine there are things like this out there already, but most of the dashboard implementations I’m aware of are focused on business-oriented things that are not really what I have in mind here, or they require configuration and infrastructure that is overly complex, especially for this application.

That said, if you’re aware of something like this I’d love to hear about it, and if I get around to building it, I’ll be sure to post some updates.

Category: Ideas, Software | Tags: , ,

Pullstarter – Crowd-sourced funding for ideas

Posted on by • 4 comments

You’re probably familiar with Kickstarter (if not, click over there and we’ll be here when you get back).  Kickstarter is a prime example of a Crowdfunding site used to raise money for projects without the overhead of traditional investment.

This is a good thing, and many cool projects have received funding through Kickstarter campaigns, and it’s been great for people who want to make something and just need the funding to see it through.  But what if you just have an idea?

Conversely, what if you just love to build stuff but don’t know what you should build, how to find an audience or how to value one idea over another?

I’ve had a number of people come to me with these same questions, and after conversations with trusted advisors the idea behind Pullstarter was born.

How Pullstarter works:

  1. You list and idea for something, and how much you’d be willing to pay for it
  2. Other users who are interested in the same idea bid on it as well
  3. When the bids get high enough, a Maker takes on the project
  4. When the project is delivered, the Maker is paid and the bidders get what they wanted

 

An example:

I want a flying bicycle, and I’d be willing to pay $500.00 for one.  So I create a new idea on Pullstarter and provide some details about what I want.

Who doesn't need a flying bicycle?

Who doesn’t need a flying bicycle?

My idea gets added to the list of ideas displayed on the site:

Screen Shot 2013-04-05 at 4.58.41 PM

Let the bidding commence!

Then Bob logs in and sees my idea.  He likes it too, but it’s only worth $300.00 to him.  He bids on the bicycle idea and now it’s worth $800.00 to whoever can complete it.

Screen Shot 2013-04-05 at 5.01.00 PM

Other users may join in the bidding, some may just “follow” the project to see what happens, and a summary of ideas, following and bidding is displayed while they are logged into the site.

Eventually, the value of the project reaches $1M which gets the attention of Julia, who just happens to want to build a flying bicycle but never thought anyone else would want one.  She looks at the number of bids (586) and divides this by the value of the idea and decides that yes, she could produce 586 flying bicycles with $1M.

Now, placing a bid is a legal commitment, so Julia knows if she can deliver the bikes she will receive the funds so she takes on the risk of securing the necessary credit, etc. to product the product and fill the orders.

Julia develops the bikes and delivers the first one to me (since it was my idea).  I love it and consider her product acceptable, Julia delivers the remaining bicycles and the funds are released to her account.

This is of course a rather dramatic example, and clever makers will take on ideas that they can carry out without having to beg or borrow too much to put together the product.  But I used big numbers because they are more exciting.

If you think this is an interesting idea, leave a comment and we can discuss.  Awhile back I spent a couple hours and threw together a prototype for the system which you can check out on Github:

https://github.com/jjg/pullstarter

I’d love to hear what you think about it.

 

Category: Ideas, Software | Tags: , , , ,

Rosie – A first step toward shrinking the world through telepresence and robotics

Posted on by • 0 comment

About two years ago I put together a proposal for a solution to the array of problems facing the domestic robot.  You know the kind, the robotic maid that was part of “Tomorrowland” in the 1960′s (hence the project name “Rosie“) and “just around the corner” in the 1980′s but instead the best we could manage what the Roomba.

There’s a number of reasons we never got our robot butlers.  Over time some of these have been addressed by dramatic improvements in technology and the reduced cost of components.  In other areas however there has been little applicable progress; machine vision, artificial intelligence and dynamic feedback control systems (responding to changing conditions, etc.), all of these areas have improved since the 1980′s but not enough to make building a domestic robot practical, and even with an unlimited budget, such a machine would have limitations that would disappoint.

What has improved dramatically since the 80′s though is communication networks, and in many ways these networks have made it possible for people to work together around the world, regardless of physical location and to some degree, without the encumbrances of social-political borders or economic limitations.  These networks allow work to be distributed globally, from programmers to telemarketers to drive-through attendants.

However for the most part taking advantage of the ability to work globally has been limited to work that can be transmitted electronically (there are a few exceptions).  Wouldn’t it be cool if people who work in the physical world could enjoy the same power and convenience that telecommuters have enjoyed for decades?

This is where Rosie comes in.  Initially replacing the role of the household cleaning service, Rosie is a telepresence robot that combines the mechanical and electrical advances in robotics with the availability of high-speed communications networks to provide the safety and convenience of a domestic robot with the control and intellect currently only available via a human operator.

By abstracting physical presence from the housekeeping work, Rosie provides increased value to the housekeeper in the form of reduced cost, scalability, increased safety and tangental educational benefits as well.

For the housekeeping customer, Rosie increases convenience, reduces cost-per-utility and allows for greater control and management of the service with lower personal overhead.

Additionally, Rosie provides housekeeping professionals with training and experience beyond the work at hand, creating a growing number of experienced professional operators who’s skills could be transitioned to maintaining and operating robots for more diverse applications.

The nature of housekeeping work strikes a nice balance between providing a challenging engineering task for the design of the robot while at the same time remaining simple and focused enough that designing and implementing such a machine is within the means of current technology and within reach of a small team with a relatively short development timeline (1-2 years).

The up-front and operational cost of such a robot is such that it could employ a mobile-phone-style pricing structure, baking the unit price into a fixed contract resulting in a monthly cost that is equivalent to a traditional housekeeping service but with the potential to provide better service.

A side-effect of this pricing structure is that off-contract robots become the property of the housekeeping customer, allowing them to be sold off-contract and potentially applied to additional uses, which leads to “phase two” of this project.

By underwriting the development of a basic but functional telepresence chassis, the Rosie product funds the development of more sophisticated machines that can then be dispatched for more challenging tasks.  Evolution of the design is part of this proposal, and within a year or two of rolling out the housekeeping models, new models designed for other jobs will become available.  It’s not hard to imagine other areas of work that would benefit from decoupling the work from a human operator, allowing for more flexible scheduling (since workers could be available from other parts of the world), reductions in safety-related costs (specialized machines can accommodate work that is unsafe or uncomfortable for on-location humans).

It’s also worth pointing out that manual-labor is not the only application for such robots, that any profession which  currently requires (or benefits from) physical presence could be improved by specialized telepresence robots or by the availability of general-purpose robots that could be dispatched around the world quickly and conveniently (it’s not hard to imagine offices or factories maintaining a collection of such machines the way that they currently maintain other office equipment, allowing instant on-site visits from employees from other locations).

Rosie (and descendants) can operate anywhere that can be reached by the control network, and without the life-support requirements of living workers, this includes extra-terrestrial operations.

In the years since I first proposed Rosie, interest in telepresence has been on the rise.  Several companies have introduced telepresence products at increasingly accessible price-points, evidence that a market is emerging for these machines.  However, the machines currently available seem to be an evolution of telecommunication devices and lack the ability to interact with their environment beyond sight and sound.  For these reasons I believe that Rosie is now a viable product and that investment in such an effort now will lead a generation of such robots, laying the foundation for future machines with more automatic, autonomous capabilities, and I would be happy to lend my experience to such a project.

Category: AI, Crystal Ball, Ideas, Research | Tags: , ,

Tinkercad and Unhosted-style distributed processing

Posted on by • 2 comments

Troubleshooting the shutdown of Tinkercad got me thinking about high-performance computing and distributed architectures again (specifically in researching alternatives to the Gen6 kernel at the heart of Tinkercad’s objection to going open-source). While reading the Tinkercad developer docs to gain an understanding of the interface or API of the Gen6 kernel (with the intention of sourcing or implementing a replacement for these server components of Tinkercad) it occurred to me that with the introduction of Webworkers and WebRTC, as well as the commonplace nature of moderately powerful GPU’s in many computers, perhaps a truly distributed processing architecture could take the place of the Gen6 kernel in an open version of Tinkercad?

But why stop there?

Using something like the Javascript/JSON job control structures used by Tinkercad, why not allow any processing job so defined be submitted to a browser-based processing grid? Designed correctly, a compute-bound application could emit its work as chunks of code+data as Javascript functions and JSON to this grid and tap into extra clock cycles of underutilized systems (perhaps simply interleaving requests within the single application’s domain, or across a more global subset).

This seems like it could be a nice complement to the Unhosted-style decoupled identity and data concepts, adding high-performance processing capabilities to Unhosted applications.

Participation in such a distributed architecture needn’t be limited to general-purpose machines either. Specialized processing nodes based on GPU or custom FPGA devices could be pooled in this fashion, or even spare cycles on specialized devices such as network hardware or consumer electronics; but starting at the browser seems like the lowest point-of-entry.

Category: 3d printing, Crystal Ball, Ideas, Research, Software | Tags: , ,
Older Entries →