At typLAB, we primarily use two programming languages: Javascript and Haskell. Haskell has a compiler, strong static typing, and is pure (no state or side-effects) by default. Javascript, on the other hand, is interpreted, dynamically typed, and, when using objects, uses lots of state (since objects are an encapsulation of state). This makes testing Javascript more important: otherwise, a typo in a variable name might go undetected until someone uses our product.
Continue reading…
In this post we will explore some boundaries of functional programming in Javascript and show how easy it is to implement a set of combinators that can express functions similar to queries in XPath and similar to transformations in XSLT. We call the result a combinator library because we implement a few primitive queries and transformations and allow combining these into bigger ones using some basic composition functions. As we will show, all functions will follow more or less the same structure.
Continue reading…
In a previous post, Sebas explained that we use so-called XML picklers to convert Haskell data types to XML. Since these picklers have a regular structure, we don’t write them by hand, but derive them automatically using generic programming techniques. In this post, I’ll explain how our generic XML pickler works. The code shown here has been made available on hackage.
Continue reading…
Why we don’t support Internet Explorer
We’ve already talked about some of the technology choices we’re making as a company. And while our choices on the back-end can hardly be labeled as mainstream, the most difficult choice we actually had to make was related to the client-side as it directly affects our users. Obviously, Javascript on the client is a given, and we love it. However, as most web developers know, the differences between browsers are enormous and developing for all of them is almost impossible. Still, current conventional wisdom dictates that you should support recents versions of Internet Explorer, Firefox and the WebKit based browsers (basically, Safari and Google Chrome). We, however, have decided to drop Internet Explorer support entirely.
Continue reading…
Since typLAB is all about exploring new ways of creating and consuming online content we figured our software might want to keep track of what’s happening inside a document.
All modern browsers have support for W3C’s mutation events. Safari, Chrome, FireFox and Opera all do them. But not all do all of them.
Notably WebKit fails to fire DOMAttrModified events when an attribute is changed. It does however fire the DOMSubtreeModified event after an attribute is modified. So at least that gives us something to work with until the good folks at WebKit squash the bug.
Continue reading…
Here at typLAB it wasn’t evident from the beginning what would be the best choice for a storage back-end. We knew that we were about to build a web based editor and would be dealing with a lot of HTML5 documents with lots of meta data. After some careful consideration we decided to go for an XML database. More specifically, the Berkeley XML Database, lovingly called DBXML by its authors.
We figured that using DBXML would give us some important advantages:
- Collections of HTML5 documents will form the basis of data model. Only one trivial conversion from HTML5 to syntactically valid XML is needed to get our documents into the XML database. Once stored we can perform some interesting queries over our data.
- XML databases allow for the storage of complex data layouts without having a strict schema. Without a schema it will be easier to adjust our data model over time without instantly breaking our software.
- XQuery is a very expressive (almost-purely functional) querying language which is at least as powerful as SQL and far more flexible in the structure of the data to target.
- XML can be used to both encode strictly defined datatypes and store free-form documents in the same document collection. This will enable us to put both our meta data and our documents in the same database.
- A quick look on Hackage revealed there is an out-of-the-box easy-to-use Haskell binding available for the Berkeley XML database. No need to create custom bindings ourselves.
- We are in the advantage (or disadvantage) of having Haskell as our language of choice for our server software. Because of the hierarchical nature of both XML and Haskell algebraic datatypes, an XML database feels like a perfect fit.
Once we decided to go for an DBXML back-end we had to figure out how to easily get values form our Haskell program in and out of the database. The rest of this post will be dealing with the last point of our enumeration: how to get a nice mapping from Haskell’s algebraic datatypes to our DBXML back-end.
Continue reading…
As a newly started company, we have a lot of technical decisions to make. One of the important ones is the choice of a programming language. Since we’re building a web application, this goes for both the client (i.e. the web browser) and the server.
On the client, there wasn’t much discussion. Javascript is the only viable choice, unless you want to use Flash or similar plugin-based models. But on the server, we had more freedom. Popular choices for web applications are dynamically typed languages like Ruby, Python and PHP, and statically typed languages like Java and C#.
However, there was another option. Two of us (me and Sebas) are enrolled in the Software Technology master program at Utrecht University, where we often use the programming language Haskell. Haskell is a functional programming language, which means that a program is composed of expressions instead of statements, as is the case in an imperative programming language.
As you might have guessed from the title of this post, we decided to use Haskell for our server side programming. What are the features that made us choose Haskell?
Continue reading…
This is our lablog, where we will write about the proceedings of typLAB.
‘What’s typLAB then?’, you might ask.
typLAB is our initiative to investigate and develop new ways of creating and consuming web-based content. We aim to explore the boundaries of what’s possible using contemporary internet technologies. The result of our endeavors should enable you to read and write rich, dynamic and smart articles like you’ve never read nor written them before.
Next question. ‘Who are those “we” you keep referring to?’
We are Erik Hesselink, Sebastiaan Visser, Salar al Khafaji and Lon Boonen. That’s the team; small, smart, focused and eager to learn and share. Most of us share a history at Xopus, the web based XML editor.
One more question? ‘What about lablog, what can we expect from it?’
Through lablog we want to inform you of our ponderings and wonderings. Our steps forward, backward and sideways. We’ll write about our progress, our discoveries and the things that make us tick.
You can expect articles on HTML5, CSS3, web development in general, Haskell, XQuery, usability, semantics, JavaScript and all stuff that makes a nerd’s heart jump a beat. Or two.
And we’d love to hear from you. Through the comments, Twitter or plain old e-mail.