Scripting News

<%blogHomeDescription%>

Everyone has a strugggle

Everyone you meet is fighting a battle you know nothing about.

Everyone you meet is fighting a battle you know nothing about. Be kind. Always.

Be kind. Always.

See also: The guy at the gas station.

 10/10/13; 4:27:42 PM.

My server JavaScript dream

I'd like a super-simple way to write JavaScript code that runs on a server.

Let's say I want to write a simple web service that takes a chunk of text and returns a Markdown-formatted version of that text.

This is just an example.

I'd like a little editor, preferably an outliner, that has a simple File menu.

When I create a new script, I give it a name. Say markdowner.

It gets its parameters as a single JSON structure.

Suppose the service is deployed at hello.org. I would call the handler this way:

["http://hello.org/"].markdowner (s)

It would return in its body the markdown-processed version of the single string parameter.

When I make a change to the edited script, it changes the functionality of the handler. The whole thing is live.

I can include other bits of code by calling a loader routine, like this.

Courier 15px 0

function markdowner (s) {

var md = system.load ("http://static.hello.org/pagedown.js");

return (md (s))

}

The loader keeps a cache, obviously.

The server-side runtime library is very important. It should be simple, even minimal. But please support all the basic string, time and math routines supported by JS in the browser.

It would be great if I had persistent globals that were around every time my code was invoked. Not limited to strings as with localStorage. Big JSON structures. Let me plug in a nice editor for those structures, so I can browse around at runtime.

Must have a good debugger, like the one running in the browser.

There must be something like this? I hope so.

Why the JS server editor has to be node.js

I've got dozens of little utilities that run in Frontier that longterm aren't going to be easy to maintain. Many of them are generic, like a redirect manager, for dealing with lots of domains and being able to easily move them around. These are mature, and really useful. No one is going to run them in Frontier.

So if I'm going to move them off what effectively is a one-off system, it should be to a platform with major consensus. It's why I like developing in JavaScript in the browser. It's where people expect software to be these days (or in native IOS or Android apps, but this gets me more places with a manageable amount of work).

I need to have a way of writing those little server apps that will deploy easily for a long time. PHP would be a good choice, but I've already learned how to program in JavaScript. And it's most like UserTalk, and I've already got the mapping worked out in my head. Another mapping? Oy that makes me tired. I'm not looking to explore new frontiers like that at this point in my career. Maybe to play around with, but not to deploy.

This was originally an email to my friend Chuck Shotton, but I decided to make it a blog post. I made this a section under the original post. I'd like to try that idea out. It won't be a separate item in my feed but I will push a pointer to Twitter.

October 12, 2013 at 5:21PM

A simple S3 text editor

You know what else we need? A simple S3 text editor.

Enter your credentials, a path, and the text of the file appears below.

Big Save button.

I might do that for OPML files with a Concord thingie.

Also seems Amazon might support OAuth.

 10/10/13; 3:33:42 PM.


It's even worse than it appears. © 1997-2013 Scripting News, Inc.