Sessions is temporarily moving to YouTube, check out all our new videos here.

Rapid Web Development with Huncwot & Marko

Zaiste speaking at London Node User Group in August, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Huncwot is an opinionated and minimal Node.js web framework, slightly inspired by Clojure, and built for ES6/7 era with a "batteries included" approach. It tries to formalize conventions and eliminate choices, by providing solid defaults for building web applications that increase a programmer's productivity. In this talk we'll explore how to build an application with Huncwot, what it brings to the table and how to make web programming more approachable, especially to non-programmers.


So I'm here today to talk about a project that I'm working on and I won't say framework because we heard what emotion that's going to create. So short info about me, I'm Zaiste. This is my website, I'm also on Twitter but I'm not very social on the internet. I prefer to be social in real life. I organised a small conference. It's been like ten years. It's call PolyConf, it's like TET but for programming. The idea is to put different programming languages together and to seek inspiration and to never see horizons. See never see boundaries but always see horizons and to change and to explore. I highly invite you to it. We use organised this year edition in Paris. We plan to organise the next one probably in French Riviera. And I just came back from meetup, from meeting in France, here in London, and we'll be organising a small one day PolyConf certainly even here in London. So if you'd like to get involved, let me know. I'd be happy to work with you guys. I also organise type projects and ideas to help organiser to find speaker. So if you're interested, let me know. Okay, So huncwot. We're looking for an introduction of the word. It's like a perisher, rascal, or scallywag in English. I'm not sure if the order are good, but it's basically about someone who is naughty but in a positive way. So this is huncwot. And I won't tell you what it is, I'd just give you example on what it looks like. And we'll try to maybe together have this intuition on what this two can do and help you with. So let's start with the Core. It's a basic huncwot application. We just require it. We just instantiate the app and we create a very simple routing. As you can see, this is a web application. And probably this is some kind of framework. But there are some interesting things. There is only one perimeter for the handler. Which is underscored because we don't really care about this. And there is this implicit return of a string. So let's dig deeper. We have some helpers, we have some wrappers. For example, if you want to create 200 response, we can just import it required it okay function. And we can pass regular data structure. Like a object, SQ object, and it'll return 200 response http response of the proper type which is application json. Okay but you may ask, if I want to have more flexibility regarding responses. Well this is easy because responses are object, regular data structure in javascript. It's not something fancy. You don't use getter, setters to create that. It's very declarative. So you have a lot of power, you can use regular ways of transforming this data structure available in javascript. So as you can see we just say, return a body of this starting code. And with those headers. It's very simple, it's very straightforward. So how about this mysterious input perimeter. It's just a request, it nothing fancy, it's not a context. It's just a request. So as you can see, the handlers always accept requests. It's not very well visible. But handlers are functions. We can say, we can argue that they are pure functions. So it's like some kind of functional approach here. They always take request as input and always return response as output. It's very simple. So this idea was, I got inspired, because I was working a lot in civil work, with closures and closure script. This is idea that I've stolen from ring which is a very interesting web application in closures. So I encourage you to check this out. So like I said responses are just objects regular data structure in javascript. They are declarative. And if you want to have a response, you just need to define the body and statusCode at least. You can define more. Okay this kind of tool can be very useful. Just return strings and data structure to be converted into json response. So we need more to have a proper view layer. And this is possible with huncwot as well. So we have this function call page. We just require it, we just pass some bindings to our template and we generate HTML as a string. So as you can see her, I'm not defining where the template is located. Because similar to arrays, huncwot is using some conventions. And I'm trying to find this sweet spot between magic which I don't really like and usefulness. For example, it'd be easy to understand but at the same time, not too magic. So in this case, it's just about the location of the template. There are some nice things you can do with that. We can import another function called gzip. We can combine functions in mathematical sense. For example, we have page function which is in a function and gzip function which is another function. So we return HTML which is done in gzip, and we return it to the client. Because as we said before, everything we return from the handler is for a response. Very simple. So this is the template. This is proposition for our template. But you may say I like HTML, it's easy to work with designers, they understand HTML, but I prefer this invention based approach. That's fine with huncwot. We can just convert it, and we can use both, this approach. And this approach on the same project at the same time. And all that is possible because of this wonderful library. Which I recommend you to check out. Which is called Marko js. It's from the engineers at eBay. And they created something truly amazing. It's a library of template language and we will explore further what it can do. So for example, regarding benchmarks, you should never trust benchmarks, you should never base you should never choose library because of a benchmark. It gives a nice perspective. This is comparing a minified and zip version between react and Marko. For example, you can see that Marko is four times smaller than react. Okay so just to sum up, we have pages, in huncwot. They allow us to generate HTML. We use Marko as template language. The content is generated on the server. And we have this convention which you put anything like pages, directory, you can use it without specifying the full path. Okay, going further, Model. So now we have view, we should think about how to interact, how to get the data from our data storage. Its very straight forward. So if we imagine we have a database and we have a table called widgets. We can just do await db. And this is a regular select start from widgets. But you may say, well we would need more flexibility here. Well, it's possible, we can just define, we can change functions. We can say, well I'm only interested in the column ID and name. How about finding something. It's also possible. And as you can see, I'm not just using string here, I'm using regular javascript data structure. So I'm passing a data object which defines how to find this piece of data I'm getting. Inserts, also the same approach. I'm just passing the object, I can also pass an array. And it'll be transformed to the proper SQL query. As you can see I'm not adding any abstraction here. We're using plain old vocabulary we all know which is SQL. So I'm using words like insert, where, etc. It's similar we can chain those. We can say, well find me that and that piece of data and update it. Okay so models are just plain, we interact with database using SQL. We don't need ORM or any of that sort. This all is based on a library call knex js. And again with small convention which says that all model should be in the model directory. Okay we have view, we have data, which connects somehow to those two. We'll be using controller to that. Controller are just functions. and they have some proper names. Some imposed names. For example to read a single element from the database. There is convention which says you should use a read function. As you can see, this is a passing function. Here we can like plug in where the three dots are, we can plug in our database query for example. We can have another function which is add. And there like five functions which are predefined. And they read like bread. So I think it's better to have. I think bread is more tasty than like crude unpleasant thing we use to use. So lets use bread. Okay so controllers. Again, Lets sum it up. We use it to expose our data. They are somehow standardised but it's like a very thin layer of standardisation. Again, there's a convention which says they should be located in the directory called controllers. Okay you may say now, well it's interesting but what you're saying is all the approach to programming. It's like arguing that we should do the server side approach when the content is driven on the server side and pushed to the client. Well, I started with the less radius. Those ideas I presented are not very important. More important in huncwot and in market js is this component based approach. We're all be using this approach. So using component is more easy way to think about constructing user interfaces. And a component is a way to put behaviour and styling together for market. So this is all possible in huncwot. For example, lets imagine this piece of UI. Just some interesting things happening here. For example, when you define classes, you don't have to say class equals something like that. You can just use selectors, things to marker. Also we can also way like h1 dot title. We can combine them. We have special syntax to read the state of the component. And we can attach handlers to possible events that can occur. This is the part which allows us to define the styling. This is almost exactly same as in the view or the react. This is the part which allows us to pass the behaviour. So again, similar to those two, there are some kind of predefined methods, life cycle methods which are available. It works exactly the same. So I think I would argue declarative approach to UI representation is better. And this is possible with huncwot. And on top of that, there is, I'm using Redux. So you have already pre configured with Redux, with huncwot. And you can just if you already use react application or huncwot you can already start. You'll be familiar with that. Router, we've seen server side router. But here is also client side router. We just integrate it into huncwot. You don't have to configure it, you don't have to find the best one, it is already there in the works. So in summary, huncwot is one side it's just a replacement for Express and Koa. It's unified full-stack solution. We can build very easily RESTful APIs. And I encourage you all because I'm quite a fan of GraphQL. I'm also working on making it very easy to start. Very easy from scratch to learn the GraphQL API. It's a batteries included approach, so you have everything you need. You don't have to worry about different libraries, how to put them together, will they work together, will they be maintained, etc. We can build primarily SPAs like single page application, but we can also build regular application as well. There are some conventions. I try to provide solid defaults. There is similar terrains, there is this common line tool, which allows you to have this streamline experience work flow where you can create things very easily and it's 100% javascript. So yeah, yet another framework. So maybe lets take a moment of silence. Some awkward silence. Okay, Lets move on. This is the definition I was planning to give out at the beginning, well it's the end. This is definition of Node js web framework. It's built for the ESNext because I'm in love with I would say ESNext 6 and 7, and it's built in mind with batteries included approach. So you can ask why did you do that. Why another framework. The first reason I was doing a lot of mentoring and I was doing a lot of workshops, react, closure, closure script, few js, angular. And people started asking very interesting questions. Building this tool, I started thinking maybe I would just create something that would allow them to better understand the principles of programming. So it's not something I'd be hoping you'd be using or it's suitable for production because it's not. It's just a toy. But that was the reason, the primary reason. Teaching experience I had in all those question that people ask me. The other thing, the minor motivation was we have so many choices right now, and when you want to build your react application, you have to many libraries. You don't know which one to choose sometimes you choose a library but it's got, we just no longer maintain after a few months. And you have to worry, you have to fork it, etc. So there is a nice quote by Eryn. Which says that everyone wants to write reusable code but nobody want to reuse anyone else's code. Yeah, there is some truth in that. I always recommend you to read a wonderful article by Jessica Kerr called Reuse. which is somehow related to what I'm working on right now. And it gives a nice perspective on that matter. So the goal is to have a single library. Which all modules you need, for everything. Like one repository, one MPM module. We just develop it in a coherent way. That's the key difference here. And I'm trying to find programing productivity first so I'm trying to make programming more approachable, more easy especially for beginners. I don't want to deal with explaining why we have to choose this or that. I would just provide the defaults. Because at the beginning it's not hat important. If you're dong something like a full large scale that's something you should care about. But in the beginning or the mid stage, it's not that important. And I'm looking for feedback, I want to just bounce off the idea off you and try to work on some community conventions. And it's full stack, 100% javascript solution. So thank you very much. This is the github if you are interested and if you have any questions, I'd be happy to answer.