I have recently tagged v0.1.0 of my open-source project, Picket. Alongside it, I have also launched a site, containing documentation at picketjs.com.
With new JavaScript tools coming along seemingly every day, I feel the right thing to do is to justify it; that is, to explain what it is, why it came in to existance and why I believe it is powerful.
Firstly, it isn't a library and it isn't a framework. Out of the box, it doesn't do anything. It isn't a competitor to Angular, Backbone, React, jQuery, Node or any of the other fine code-bases currently powering the web. So...
Picket is for defining classes and interfaces. It brings in powerful features from other languages that allow you to develop in a more mature way. It may help to think of it as another language written in JavaScript.
The reason I say it does nothing out of the box is because it is not a collection of classes, but rather a more advanced way to create your own classes. You may use it as a way to write your models for an application powered by a pre-existing framework or you may use it to write your own framework. Picket doesn't mind what it is used for, the key is that it is entirely un-opinionated. If you are writing classes in JavaScript, you can consider writing them as Picket classes. The code that you will write is entirely valid JavaScript and runs in the browser with no more setup than including a picket.js script. It does not need to be compiled in order to run.
I won't go into these much here as this is isn't intended to be a sales pitch but the current list of language features includes the following:
You can see the details of each on the website.
I learned to code writing PHP and JavaScript. As someone who always likes to work to the highest standards that I can, I voraciously read up on best practises and design patterns from the beginning. Because of this, I found myself trying to write code that was object-orientated and unit-tested at all times. In fact, I am a big advocate of the SOLID principles of object-orientated programming which meant I was attempting dependency injection and injecting mocks as part of my tests as well as programming to interfaces instead of concretions.
A lot of these practises can be achieved in PHP as it has interfaces, private/protected/public properties and some type hinting. However I have always struggled when it comes to applying the same principles in JavaScript. JavaScript (or more specifically ECMAScript, the underlying language) has always gone down a route of loose-typing, functions and prototypal-inheritance which may be great for some (it offers a very low barrier to entry) but it has never quite worked for me.
It is, however, the language of choice if you want to do client-side coding for the web. In fact, in reality, it is the only choice.
On my travels, I found tools like Backbone which seemed to have a slightly different way of declaring classes and their properties and methods. What I found frustrating though, was that these were only useful if you wanted to buy into the whole ecosystem of the tool meaning that you couldn't just write classes this way; you could extend Views, Models and the like. I wanted something that just let me write classes. Tools like Backbone did, though, make me wonder if what I wanted could be made. At this point, I never expected anything to come of it but I did start experimenting if for no other reason than to really develop my knowledge of JavaScript. I found over time that I could indeed do pretty much everything I wanted and plenty more. This experiment has grown into what is now Picket v0.1.0.
In hindsight, a solution to my problem did exist and it is called TypeScript. I imagine if I had found it earlier, I would have been delighted and simply got on with learning it inside-out. However I discovered it when I had a much better understanding of the problem at hand and I am confident that there are significant differences between our two approaches.
For those that don't know, TypeScript is a language of its own that is compiled into JavaScript in order to be run in the browser (or elsewhere). When you develop in TypeScript, you run a script which constantly analyses your code to check for rules like type-safety. Then when you compile, all of these checks are removed, leaving pure, simple JavaScript.
As an example, if you were to specify a method as only accepting a string then TypeScript will ensure nothing but strings are ever passed to the method, erroring if this is not the case. When you compile, the method simply assumes it has recieved a string each time because you have demonstrated that this is true.
This is in contrast to Picket where type safety rules are present throughout; at no point are they compiled out. This means that Picket always checks if the provided value is a string.
There are a few consequences that come from this difference in approach. Please note that I have not written a great deal of TypeScript so I there may be things I have misunderstood below. Feel free to let me know. Firstly, I am personally more comfortable knowing the type checking applies when the code is run in the browser. JavaScript programs can be complex and they often respond to user input so I think it is hard to predict fully all possible ways that the program may run. There are scenarios where a change in user input could affect what values are passed to some method somewhere that may not be caught. In this case you are likely to recieve an error that is hard to understand - it won't simply be an invalid argument error but maybe an error from trying to convert an array to uppercase.
Secondly, the TypeScript approach somewhat relies on the whole ecosystem being TypeScript. In Picket, you can write a class library and make it available to the public. Someone else can then consume those classes and all your rules will apply to them as they did to you when you wrote it. With TypeScript, the distributed JavaScript does not contain language rules and as such is possibly useless to them. You could distribute the TypeScript source but this means they must run a TypeScript environment to consume it.
Thirdly, as class meta data is retained in Picket, the reflection API is
made possible allowing you to use code to understand details about your
code. As an example, imagine that you are identifying a controller (as in
Model-View-Controller) based on the current URL. When the URL changes, you
load a controller class (e.g. /home maps to the class
MyNamespace.Controller.Home). Now, using the reflection API
you can check whether the loaded class implements your controller interface,
MyNamespace.IController. This would not be possible in something
like TypeScript because the idea of interfaces has already been removed by
the time the code starts running.
Of course, not everything is better with the Picket approach. Due to the fact that all this meta-information is retained and used for testing when the code runs, there is a performance hit. At the moment, I am yet to do performance testing in anger, mainly because I know there are places in the current implementation where significant gains could be made; anything I measured now would be irrelevant soon. I do expect the performance to suffer enough that Picket developers would need to consider some architecture decisions based on it. Specifically, anywhere where you are doing serious number-crunching which would take a long time in native JavaScript, you will want to avoid retrieving class properties and calling class methods but rather bury the logic entirely within a single method. I do not expect the performance to be an issue when running your average complex application.
However there is a key point to be made here. TypeScript removes meta-information for performance reasons and there is no reason that Picket couldn't be distilled down to native JavaScript for production environments in the same way. However, I believe this should be done as late into the development process as possible. Going back to my second comparison with TypeScript in the previous section, imagine I wrote a class in TypeScript and published the raw JavaScript online. If you then downloaded and consumed it in your project, you would not have type-hinting and the like but the code would run quickly. Alternatively, if I wrote the class in Picket and you consumed it, you would have type-hinting on that class but it wouldn't run as fast as possible. Significantly though, when you finish developing your entire app, you could compile the Picket code to JavaScript! Then you have all of Picket's features available throughout development and could still have maximum performance. Please note though, that this isn't available with Picket yet.
The other significant issue with Picket is the limitations on some of the
syntax. As all Picket is valid JavaScript, there are points where quotes,
commas, nulls and undefineds are required simply
to not break when run. Also, when getting and setting a class property, the
syntax is not ideal; a method named for the property is called instead of
directly accessing a variable. This is so that Picket can intercept the call
and do its work.
For me personally, these quirks have faded into the background very quickly but I can understand that they may be annoying. As an answer to this criticism, I imagine a format which mirrors Picket syntax very closely but without the extra details. This could be compiled down to Picket to be run in the browser and all features would be completely intact. The following two examples would be considered identical in functionality.
require My.OtherClass
require My.ThirdClass
class My.Class
{
abstract public doSomething (string) -> number
public doSomethingElse (Date inputDate) -> string
{
// ...
}
}define(
'require My.OtherClass',
'require My.ThirdClass',
'class My.Class',
{
'abstract public doSomething (string) -> number': null,
'public doSomethingElse (Date) -> string': function(inputDate)
{
// ...
}
});Simply put, I made Picket for myself and I am delighted with the way it lets me build applications. I intend to do as much work on it as possible going forward because I simply don't know of any tools I would rather write JavaScript in. I am making it available because I know if it helps me, it may help you too.
I would also like to note that it is not my intention to contribute to fragmentation of the web. In fact I believe that Picket can play nicely with other tools, although this has not been a priority of mine until now. Going forward, I intend to work on running Picket in Node as well as experimenting with pre-existing dependency loading systems, rather than using my own.
If you want to be involved in the project, get in touch via pete@peteonline.co.uk.