About this talk

In this talk Dan Stocker introduces the GiantJS framework – a collection of 18 isomorphic modules with the purpose of giving developers a single, coherent set of tools that serve as a solid foundation to a wide variety of apps – from real time collaboration to games.

Transcript

[00:00:06] I’m coming from a C++ background, so I very much appreciate Eyal’s presentation. In the past five or so years I’ve been mostly heading up the frontend efforts at various start-up companies. In the process of which, well, with the help of my teams. We developed a framework slowly, which is now named “Giant JS” and it being true to its name is vast but there’s a good side. There’s a lot of ground to cover. Instead of giving you the dry technical details, just sit back and watch. I’m going to do a demo first. This demo is an unusual one because the framework is mostly used for things like collaboration platforms and asset management applications and so on but this is an isometric game map Adir, which is purely written in Giant JS, not even using its full potential. What this can do is you can basically draw a map, an isometric map to be used by a game or for whatever purpose. You can select tiles and place them. Is the magnification okay? Everyone can see it? You can also manipulate the tiles themselves. This one is now rotating counter-clockwise and you can do clockwise and also you can elevate the tiles, so you can draw hills and stuff.
[00:02:33] In the URL, what we can see is a zipped version of the matrix that makes up this map. It’s not very visible because the URL is quite long but as I change stuff in the map, you’re supposed to see the URL changing. Another proof of that is if I reload the page, then it routes back to the exact same state. That illustrates two things: that there is routing built into the framework and that the routing information recreates the state that we want to recreate. Okay. Good. One more time. We’ll get there. Okay. Right. What we have here is we can see that the map is built in the DOM, built with DOM elements and what we can see at each DOM element representing a single tile is that it has an ID, which is an auto generated ID, it has a number of classes; some of which are the class names of the classes that make up or implement one tile. Some other series of classes, like there’s a name assigned which is just to make sure that rendering is happening in the right order. That’s what we can see in the DOM. Let’s look at something else. What I’m going to do here is modify the DOM a little bit. What it does is reels keys, data keys on each tile. Actually, each and every data bound element or component in the entire application. What I can see here, there is this board/main, so it’s probably not very visible there. It says board/main/tile/647. That’s the thing that identifies a single tile in the model layer of the application.
[00:05:52] What I can do with that is, yes, let’s find one tile that you can see and now actually it would be a good idea to zoom in. Okay. Let’s see which one this is, this green one. Okay. That’s 530. Right. Okay. This here, this board/main/tile/530 is a key that identifies this tile. Say I want to elevate this tile. Right. What I need to do is I need to create an item entity from this key. Actually, what happens is that I’m locating this tile entity in a central data store, which stores the whole state of the application and then use the API that is implemented by a specific tile class, which happens to be a sub-class of an item, which is a collection item. I’ll tell you more about the data structure a bit later. Let’s see how elevation works. Set elevation one, okay. We elevated it by one or elevated it to one or to two. What this is supposed to demonstrate is that you have access to the entire data model right from the console, which is not what you’re used to if you’re used to working with Angular, for instance. It’s only for the model layer, you can also access widgets. These tiles are actually instances of widget classes, which you can also access by their IDs. You can do something like there is this W10662 widget, which gives me an object, which happens to be an instance of a widget class. Then I can do stuff with it; I can remove it from the parent. This is a nice way to make sure that you have complete control over the application.
[00:09:07] Okay. Going forward, another thing that this illustrates is a few modules from the framework. Mainly the widget module, the entity module for the item manipulation and then routing for making the state restoration possible. As you see, there are a bunch more modules. Giant comes together as a collection of independent but interoperable libraries. It’s trying to get the best of both worlds together because like and not like monolithic frameworks because we like them because they’re convenient but we don’t like them because you can’t really take it apart and decide to swap out something with something else. Also, for stacks built based completely independent libraries that you get together from NPM is, again, good because they’re independent, so you have more control over which parts you want to use and which not. At the same time, those libraries were very likely used very, very different concepts and you have to put your mind or put yourself into a different mind-set when you go from one layer of the application to the other. Giant is merging these two concepts in a way that the modules are still independent. You can actually swap out the widget module with React or you can swap out the model layer with some Flux implementation, for instance. These things have been done in the past. What it gives you is a very coherent set of libraries, where patterns and practices repeat over the entire framework.
[00:11:45] Very briefly. There are three layers to this onion. The inner most is a bunch of libraries that are very essential to building anything. It’s covers stuff like assertions, object oriented programming, data structures, different data structures from collections and sets and trees and index stables, also immutable; functional programming utilities. Then there’s a very pervasive event mechanism that is applicable to a lot of different areas in the application from routing to the data model, all the way to widgets and API access and so on. Also, stuff like templating, general utilities, AJAX and so on. Then there’s a next layer that is implementing basic framework functionalities such as: routing, such as the model layer, also API access and have I already said routing? Session management, internationalisation and a group of pre-fabricated widgets that are pretty much ready for you, so you can use them in your own application. Then there’s another layer which is more like a utilities and external things to make your life easier while you’re developing an application. Things that you can use in the build process and so on.
[00:13:35] As you can see, some of these circles are dotted and faded out, which means that not everything here is finished. It’s like the second death star, it’s not finished but it’s fully operational. To demonstrate that – that’s a later slide – I’m going to talk some more about the features or feature completeness. Giant addresses to cover most aspects of a modern web application, at the same time it’s modular. You can pick and choose what parts you need and what parts you don’t. It’s also extendable, so you have full control over the entire framework. If you want to extend something, you want to change something, you can. The coherent practices that ripple throughout the framework as well as the application, if you choose to do it that way. Also, all of this facilitates or makes scaling possible, actually fast scaling and I have a nice chart later on to illustrate that. On the technical side, so these were the top down view, and then on the technical side, you have isometric. Each of these modules run in the browser as well as node. You can generate mark-up and pre-render stuff if you want to have your website or application load fast. It’s completely data driven so that the state is centralised. We can think of similar things out there. It’s event driven so basically the entire application is made of independent components, which communicate with each other through events and can occasionally access each other with limitations through their class APIs, which brings me to OOP. It has also a very strong object orientated foundation to all of this.
[00:16:18] One other thing about the structure of the framework and the application. All of this modular structure encourages to build your application the same way. Picture the whole framework as a stack of libraries, as a vertical stack of libraries. Then you implement your application as a set of libraries on top of this stack and then sometimes depending on how much you change the framework functionality or how much you augment or swap things out, it’s even hard to say where the framework ends and the application begins. It’s kind of fluid. The whole point of it is that the same, again, practices and patterns to repeat throughout the application as well as the framework. Some apps that have been developed using Giant JS or one of its predecessors. There’s this demo that I showed you; there’s another demo. I probably won’t be able to show you all of this. There’s a collaboration platform for movie pre-production, there’s a platform for maths games for grade school students and there’s a very visual immersive design media outlet, basically, and social network as well. One of these I can show you a little bit of. By the way, what you see now, these walkthrough images have been generated with framework on the Node side and then captured actually with Node WebKit, which previously we’ve heard. For instance, the position of the button can be known to this canvas implementation that zooms onto it. Anyway, I just cycle through it and show you one thing. Okay. Along the many modules of the framework, you’ve seen one that was internationalisation.
[00:19:04] How easy that is to use here. This is English. The current language of the application is English. I want to use Portuguese, Brazilian. I create a local instance based on this local string and I’m calling a set as current local and then let me zoom in, then any string that is not coming from the backend, for instance, this comparing is coming from the backend. Any string that has a representation of the current language on the frontend will be used. Obviously, there’s a nuance mechanism behind all of this, which I don’t have time to walk you through but the general idea is that there’s a local class which implements this “set as current local” which is a global or single term somewhere in the application and then that’s maintained as a state in a central place and you can manipulate it. When you manipulate it, it fires events and those events will be captured by these text widgets and then the text widgets outdate themselves to show the correct language.
[00:20:46] Right, so what else is there? Right, this is the figure that I wanted to show you about the productivity upsides that I managed to – I don’t have much of a comparison in this regard because all the numbers that I could find were previous projects of mine. This is a number of lines of code over a year, which is not always a good metric because you can just copy paste and get into stellar figures in terms of lines of code. The code we use in this project was very high, following the framework’s principles. Within a year we reached about 90,000 lines of code gross. The yellow line is gross, which contains comments and line breaks and then the red one is the one without comments and line breaks. Just to give you an idea of how little the framework is in the way of scaling. Okay, right. This presentation is also a pitch because I’ve been working on this and with this for the past five years, but it has already outgrown myself and my former teammates who still contribute from time to time. What you can do to help is first of all use is and give feedback. If you give feedback, do it on Stack Overflow in the form of questions if you probably will have some annoyances and such. Also, contribute, that would be a goal to grow a community. These are the web addresses and Twitter accounts and GitHub accounts that you can reach the framework, share thoughts and get in touch with me.

Dan Stocker

JS Monthly London

JavaScript evolution has sped up in recent years and even the most veterans developers find it hard to keep up with the latest trends. This meetup group aims to bring you monthly bite-sized updates on the world of JavaScript.

Sessions by Pusher

We make the complex simple. Use Pusher to add realtime interactive features to your apps in minutes.

About Sessions

Inspiring talks by inspiring speakers

Meetups are a great way to hear from the experts and keep up to date with the latest ideas - but what happens if you can’t be there? As developers ourselves, the Pusher team got to thinking that there had to be a better way. This content is just too valuable to miss.

So we decided to do something about it. Our mission: make it simple for developers anywhere to watch great programming talks and learn from the experts - anytime and absolutely free.

We spoke to meetup organisers and speakers and got them excited about getting in front of a wider audience. We pulled together a professional production team to create high quality videos and transcripts from meetups. We built a video platform to bring the content together in one place.

And now we have Sessions. Watch the talks that interest you. Subscribe to get notified when new content gets added. If you’re a meetup and want to get involved, let us know.