Tag: JavaScript

Scripting iOS

Last week Apple acquired automation workflow application Workflow. Of course there was a nice buzz around it and it was a big topic of conversation on various podcasts and websites.

This, of course, got me thinking about automation. I’ve always been a fan of open API’s and the ability to automate applications. We’ve also seen recently that Omni Group is opening up OmniGraffle to automation via JavaScript.

Back in 2010 x-callback-url was created as a way to allow applications to call into each other and return results so you could chain together calls to build custom workflows. Apps like Launch Center Pro and Workflow took advantage of x-callback-url to let you build those workflows and execute them. Now we have a bonafide standard, without a standard. The app ecosystem found a way to support automation without Apple’s help.

I’ve used Launch Center Pro but until recently I’d never used Workflow, and it’s pretty amazing. The Workflow guys did an amazing job creating a drag and drop UI for building what amounts to a program. Well worth a look.

So, this brings me to what I’ve been thinking about over the past few days. Given x-callback-url and App URL schemes in general it would be extremely cool to use those to create object hierarchies using JavaScript. Why JavaScript? Well, it’s native to iOS and applications can use the runtime. Given the advances made by the Workflow team why not take it one step further?

Allow applications to specify a  Scripting Dictionary or Type Library as part of the application bundle, this should allow runtime creation of objects. I know this isn’t rocket science and it’s been done many times over.

Short of adding support to the OS it would be pretty sweet if an App like Workflow, Launch Center Pro, or Pythonista would standardize on a way to parse a URL Scheme into an Object Hierarchy.

I’m going to use Evernote, Bear, Overcast, and Arrgly as examples.

What do you mean by Object Hierarchy?

That’s a good question. Here’s what I’m thinking. Since the Apps mentioned above all support URL Schemes we can derive an Object Hierarchy from them. Basically the beginning of a URI begins with a scheme. The scheme is the name. In the case of Evernote it’s evernote. Pretty simple, right?

Given the scheme name we follow that with a path. In the case of x-callback-url based URL schemes we will skip over that part and move to the second item in the path. This will be the action, or function, or the object we’re going to execute.

evernote://x-callback-url/new-note?type=text&title=EC%203

The above URL will tell Evernote to create a new note of type text with a title of “EC 3”. If we had a way to parse that in a runtime application we could present the user with an Object that has methods that take arguments, like this.

evernote.new-note(type, title)

Let’s do a couple for Bear. First the URL Scheme.

bear://x-callback-url/create?title=My%20Note%20Title&text=First%20line&tags=home,groceries

Now translated into code

bear.create(title, text, tags)

Overcast URL Scheme.

overcast://x-callback-url/add?url=

Code

overcast.add(url)

And finally, my favorite, Arrgly URL Scheme.

arrgly://shorten?url=

Arrgly Code

arrgly.shorten(url)

Pretty simple to turn all of those into objects. When I say you can create a hierarchy it means you could, by convention, lump groups of actions into objects, or like the above examples have a set of actions that all live on a single object.

Here’s what a object might look like as a URL Scheme.

thing://x-callback-url/document/add?title=
thing://x-callback-url/document/delete?id=

That would result in using it like this

thing.document.add(title)
thing.document.delete(id)

Of course this need more fleshing out and it would require app developers to decide on a well known convention to make it work as expected, but it could be done with a bit time and effort. It could be these become an extension of the x-callback-url specification?

Web.Next

Dave Winer: “But all that has changed with the ability to access cloud storage from apps written in JavaScript that run in the browser. Software that used to require a central server, and was easy to attack, and had to scale for all sizes of use-cases, now can run in the browser, with little if any loss of power.”

Dave is excited he can host a JavaScript on a server and pull it to the browser to execute because it affords him the ability to do simple applications without the need of web services. I can understand his excitement. It’s less expensive than running a GIGANTOR set of servers to host your services and answer requests thrown at them from the client. Point taken. It’s a step in the right direction, but I still think services are necessary for all but the smallest of apps because browsers still don’t make great hosts for applications.

Bringing in the Harvest
I think designing services first is the more appropriate thing to do. Don’t think about the UI first. UI’s are a dime a dozen and should be lowest common denominator (browser), up to native, high performance, best of breed (platform specific; iOS, Android, etc.) Because mobile is so important today you can’t leave that out of any discussion about web based services. Most web apps I’ve run on my phone are pretty horrible performance wise, but I can run them. If I have a choice to get a native mobile client I always opt for it because of that.

Dave accused me of calling him stupid.

Far from it, Dave. I know you’re not stupid, I just have a different idea than you, that’s all. A differing of opinion, and that’s ok. I think you’ll be very happy with your new model and out of that we’ll see some great browser apps.

I’ve talked about it before. I’d like to see the browser evolve way beyond what it is today if this is the new “OS” for the web based world. It must if we expect to create beautiful, highly usable, fully functional applications like we did on the desktop before the invention of the browser.

When the browser can evolve to a faceless shell that is language agnostic and allows us to control it like a native application controls the desktop environment, man, then we’ll have something special, until that time it will provide the lowest common denominator gateway to the web.

Web Next

Can you imagine the explosion of high quality code and components that would flow out of a world where we’re not limited to the confines of the browser and JavaScript? It would be industry changing.

I’d love to see the browser community embrace the idea of a full CLI implementation and create a way to hit and endpoint URL that pulls a fully built application to the desktop that’s hosted by an “invisible” browser. [UPDATE: This part, about pulling a full app plays nicely with what Dave is talking about.] The browser should serve as the new OS giving the developer full access to a virtualized machine.

We’ll get there, some day.

Eating the World

Duct Tape, fixer of all things!Slashdot: “But love it or hate it, the one thing a modern developer cannot do is ignore JavaScript. It is slowly but surely eating your world.”

Truer words were never spoken.

JavaScript: Embrace teh suck

Duct Tape, fixer of all things!Deputy Joseph: “So if you were one of those who got turned away by the old JavaScript, I urge you to give the new boy a chance. Try doing some server programming in NodeJS or some database operations in MongoDB. Perhaps you may not get smitten, but I trust that it would trigger an epiphany nonetheless.”

Even though JavaScript is an ugly, nasty, hack, it’s probably the most widely used scripting language in the world. Browser support is now ubiquitous and it’s the only way to script the browser as far as I’m aware? I think it’s fair to say JavaScript is the duct tape of the Internet. It’s not pretty, but it’ll do in a pinch.

I’d be interested to see how NodeJS scales on a web scale project, you know, something like Twitter, Facebook, or Instagram. Is it good enough for that? It’s interpreted so I don’t see why it couldn’t be used for that. Folks love PHP, Python, and Ruby for web back ends and they’re interpreted.

I’ve had my eye of CoffeeScript for a while. It removes some of the JavaScript suck and the folks behind it are serious about its continued quality and success. The only downside? In the end it has to emit JavaScript. The only reason that’s bad is it could emit something incorrect, but hey, compilers have to emit code and we trust them, right?

People believe JavaScript is the future of development. I hope not. I hope it motivates people to make something better.

In the meantime we have to embrace the suck.

Flavor of the Day

AHHHHHH!Real Free Market: “Clueless people get obsessed with languages and frameworks. No matter what language and framework you use, you have to write your application code. If you use a fancy framework, then you have to write framework-compliant code in addition to your program’s code. With node.js, you’re fiddling around with callback functions and manually managing timing, instead of letting Apache and the OS do it for you.”

It looks like node.js is good, for simple apps. If you want to get serious, find a bigger hammer.

Hey, don’t expect much from JavaScript. It’s an ugly hack. But ugly hacks become standards, if you don’t pay attention.

JavaScript, not for everything

Ecstortive: “I find it pretty amusing when people are doing benchmarks of some solid technology stack to NodeJS, and declaring NodeJS to be the fastest thing on earth (just Google NodeJS vs *anything that comes to your mind* and you’ll find results like this, this, and what not). Beyond any doubt NodeJS model is worth attention, but will I use it in my production environment? I doubt that. I’ve worked on NodeJS on real serious basis; and experience was pretty bad.”

Your mileage my vary, and I’m not a fan of JavaScript, so take this sort of post with a grain of salt. Native, compiled code, tends to be faster.

Scripting languages have their place, and JavaScript is definitely baked into the fabric of the web, but maybe it’s best suited for the browser?

© 2017 Rob Fahrni

Theme by Anders NorenUp ↑