Showing posts from 2015

Shuffle it

Coming from the muddy world of javascript, I've always desired cleaner code, not only from myself, but from the community as well. I tried to achieve that by creating a small language that parses to javascript, as so many others have done before me. It's based on Joy, developed by Manfred von Thun over a decade ago, although it seems to have been abandoned. A similar language, Forth, was already developed back in the sixties, and is still actively used in embedded computer systems. Like other "purely functional" languages the core mechanic is the mathematical function. Mathematical functions perform operations on a number of values, and return a new value, not touching anything else in the program. Unlike other functional languages, the functions – or rather, "words" – in Joy (and Forth) have no formal parameters. Consider the following function in javascript: function add(a,b) {     return a + b; } add(2,2); Parameters 'a' and 'b' are

A web developer's unrest #2

This is a small series of blog posts where I try to find out how to best build UI components for the web. I build on Dojo, but for its upcoming 2.0 release, a decision is yet to be made on the successor of its widget system, Dijit. In this series I compare Dijit with some newer techniques now available for creating UI components, with the ultimate goal to be able to decide upon a long-term strategy myself. Part 2: State State is a bit of a neglected fire hazard in UI tools. The danger is that there are so many changes going on in your components that you tend to loose track. This is especially true when you have a single-page application. Dijit doesn't force you to create single-page applications, but when you run many components it makes sense to work that way, especially once you start handling navigation. That may seem like a bad idea, but it does give you full control of the program, its data flow and persistence, DOM rendering, transitions/animations, even styling, but c

A web developer's unrest

Being a long time Dojo Toolkit zealot, I was eager to see what would become of its upcoming 2.0 release. I can't say I'm disappointed, not at this point at least, but I do experience some unrest. This is not only because of the general direction Dojo is headed (TypeScript), but also because of the obvious difficulty the team has in deciding on a UI component solution. To my knowledge it is generally agreed that the current widget facility in Dojo (Dijit) is no longer deemed viable. I expect that the core Dojo contributors have already made some sort of overview of their options, but I have not. For my own insight I'll attempt to sketch out the current developments in UI techniques, clearly with the ultimate goal to be able to decide upon a long-term strategy myself. Since this will all become very TL;DR I will divide the post into topics. I also promise to make a chart at the end of the series, to show all considerations at a glance. Today I'll start with code reuse,

JQuery critique (dis)continued

Some time ago I posted a not so nice attack on jQuery, which I removed. Before that I posted a critique of jQuery that I myself find constructive and informative, but was nonetheless a bit random and incomplete. Moreover, it was also a shameless plug for a new technique I created myself: a stack-based, concatenative language that parses to Javascript in the browser. However, I have stopped working on it, as I think that stack-based languages are hard because of the mental bookkeeping you have to do on the stack. Sure, that is a perfect brain trainer, and there are ways to make the exercise less cumbersome, but I don't expect a mere fraction of jQuery users will ever warm up to such a niche technique. To cut it short, this introduction serves as an apology to both the reader and the user of jQuery, for whom it has created huge opportunities. But now to end my critique of the bling chain once and for all. First of all, I'm no user of jQuery and never have been. The reason for