I've been working on and off on a library - actually a collection of libraries - for some time now. Longer than I really should have but the original idea grew arms and legs. It got to a releasable level at the end of last year, and then it took me about 6 weekends to write all the documentation for it.

And after that I was so fed up of looking at it that I tried to forget about it. But then I told myself that unless people hear about it, no-one's going to use it, which would mean that all the work was for nothing.

It's called SuperScript.

It's quite difficult to explain what it does, but I have to try: As succinctly as I can put it, SuperScript offers a means of moving an entity from server-side code or development environment to the browser; it offers a pipeline through which you can pass declarations. Exactly what these declarations contain is up to you but simple examples might be a JavaScript variable (whose value is server-side code-dependent) or an HTML template which you keep in a sever-side file.

At its simplest, a declaration contains a server-side entity which you wish to have transformed into a client-side entity.

I've tried to make it as easy as possible to add declarations from wherever is most convenient for that declaration: from the config file, code-behind, MVC controllers, Razor views, WebForms...

The figure above shows that wherever declarations are made, they are all added to the same collection.

Emitters

This pipeline then transforms these declarations. And exactly how it transforms them is determined by the modifiers which you have declared for that pipeline. Said pipeline then emits these transformed declarations, which is why the pipelines are actually called emitters.

So just to be clear, you pass it declarations which are then run through a process (a process which is determined by you), with the output being written to the webpage.

And one last technical point: emitters consist of stages, with a transform occurring at each stage.

The above diagram demonstrates the stages inside the emitting process, and how the result from the previous stage is fed directly into the subsequent stage. Each stage offers an opportunity for a slightly different transformation.

That probably sounds vague so I'll give you a more pragmatic explanation: JavaScript. SuperScript allows you to declare JavaScript variables, function calls, enums, etc. from your code, and have them emitted in an optimal location of your choosing. This means that you can have JavaScript declarations all over your application - they can even reference each other and be dependent upon each other - and have them all emitted together. There are two more detailed points I'll add here:

  • You can have as many emitters as you need, each with a customised outcome, a different transformation upon the declarations. So for example, you might want one standard JavaScript emitter which emits content as is, and then another JavaScript emitter which emits all its declarations in a jQuery whenReady closure. You can then either emit the contents of these emitters one after the other, or you could use an EmitterBundle and have both emitters outputted together.
  • I've tried to offer as many different means as possible of making declarations - in code, in the config file, and on Razor and WebForms views. Each of these permits the developer to specify which emitter should be used for that declaration.

Outputting

I've then taken the outputting of these emitters a stage further: you have options over how and to where the emitters write their contents. You can simply write them out to the webpage inside a <script> tag, but I've also built a way (itself with further options) to write the contents into an external file. This then allows you to implement that HTML5 security attribute which states that there will be no on-page JavaScript.

So to put it all together, in your code you can declare a JavaScript variable containing, say, a username or user ID and have this optionally minified and written to an external file which is then referenced wherever you like on the webpage. If you have function calls which use this variable then you can write them on a Razor view, referencing that SuperScript object (in case its client-side name changes) and have them moved into that same minified file.

The infrastructure is built in a way which permits you to pass any sort of declaration through the emitter. I've also built modifiers which work with some HTML templating engines.

Documentation

I won't go into more detail at this point. There's tons more documentation here. It took a lot of time to write so I'd be pleased if someone read it.

I actually built a kind of mini-CMS for the documentation.

All the libraries are on GitHub, and each of the libraries has a NuGet package.

There are currently 14 SuperScript-related projects (a core project and essentially 13 add-ins) on GitHub.

Ok, it's not going to set the world of web development alight, but it offers a convenient way of doing something which I've definitely found myself doing a lot - moving JavaScript declarations from code-behind into the browser. And it's extensible so you can use it for more than just JavaScript or HTML templates, and you can do whatever you like while outputting the declarations.

And before you point it out to me, I'm aware that all the configuration stuff will have to be updated for ASP.NET 5. I've got a couple of other little projects I want to do before I add the log icfor parsing the .NET 5 config files. And just getting my head around ASP.NET 5 will be a project in itself.