Sure, I’m very happy to be here, my name is Juergen and I’m the Wakanda Product Manager. I’ve joined Wakanda & 4D from a background of web development, I have been doing a lot of development, I’ve done a lot of Rails, Python and I have spent the past ten years doing web development and also did my own startup at a startup company and I use a lot of my technical knowledge went into a startup company.
2. Would you like to tell us what the Wakanda offering is and what problem it tries to solve?
Wakanda it’s a full stack development and deployment environment, an application server, which is the Wakanda server, and a studio like an IDE offering into one package. So the problem it solves is that it’s extremely easy to use, you wouldn’t have to setup dependencies like in other environments, you basically install a whole toolset and you are ready to work on your business application. So our offering is really geared towards business applications.
In web applications today you have very rich browser experiences and the easiest stack of tools that you can think of when you develop web applications is to have the browser as the client obviously, with a client framework talking to a server framework and that in turn, runs on a server which talks to a database. So that is the basic architecture and all that in Wakanda happens using JavaScript, so from front to end all is done using JavaScript and communication through JSON and RESTful API’s and so forth. So we have a database, it’s a NoSQL database, it’s a data store that is relational so you can model and structure data as you are used to with SQL but except you wouldn’t use SQL obviously, you would use a dot-notation and a data model which is at a heart of the Wakanda application, is really covering the business logic. The business logic is at the core and the model is really the structure and the scheme and also the implementation of your application. That is very central. And we provide a client framework which is called the WAF - Wakanda Application Framework - which basically handles the communications to the server, the security, handles users so users and access rights are baked into the framework and also has a rich widget set basically to allow you to write those browser applications that almost have like a desktop field to it.
To start with the structure or the schema that is based on data classes, we call them data classes, so those are entities such like employees or companies as you would find them in a regular database, with attributes of basic JavaScript data types and you can enrich those models, those data classes using related attributes which model relationships between an employee and a company class. And you can also add what we call calculated attributes to basically query and structure more complex data business logic into the model, so you can abstract that way. And the difference between MongoDB and Wakanda is that it’s a relational Data store, so you would just work like you would in a object relational way, so it almost has a feel of object relational mapping but it’s not, it’s not mapping to a SQL database, it is really the model is the database scheme.
Dio: And I suppose you also have things like constrains and mechanisms to keep everything in order and consistent.
For referential integrity and so forth we have all that in place and as I said, there is also a security model in place because we baked the users and their roles into the model and you define them on the application level and you can share those roles and access rights with other solutions but basically security is really a big thing in those types of applications and so you can protect from a simple attribute on a data class to the entire model based on roles and users.
I think it would be really a comparison apples to oranges, we really not talking about the same thing, if you come from the Rails world you would say: “Wakanda is more like Rails” where it has a very opinionated framework on how to do data modeling, data classes and how to extend those data classes, whereas Node.js is an execution framework for server side JavaScript that follows a very particular model of asynchronous calls. And we are on the other hand, we are multi-threaded and multi core and we don’t require the developer to follow that asynchronous model, it’s a synchronous development environment basically you just develop as you would in other languages like Python or Ruby, but you will do it all in JavaScript and that is really the very big benefit of Wakanda.
We’re not into generating a lot of code for you, we don’t have those generating stuff that Rails world uses but we are more into drag-and-drop environments so we have a widget set that you can decide to use and you basically create your view in that way, dragging and dropping components onto the view.
Today it is a separate application based on web kit and it’s really all HTML 5 and JavaScript based, so we are experimenting with cloud, a sort of a browser-based studio experience and we have so far seen very great feedback and you’ll see that in a week at the conference, we’ll show that on stage.
8. Do you also have some code editor component there?
Yes, actually we are using an open-source code editor for the browser studio, in the browser we call it, and in the studio there is an editor, there is a code look up, look ahead to basically help developer to guide you through the functional prototypes and so forth, so take a full blown IDE with editor, with debugger, brake points, watches and all that stuff that are you used too, when you come from .NET world and again the salute is all integrated like the server.
9. Are you using the ACE editor or some other editor component?
In our studio for desktop we are not using ACE but we have looked into it for offering the browser base version.
4D is a W3C member and we are following the standards of HTML5 and CSS 3 as well as the Ecma 5.1 specification very closely and especially in the past a couple of years we have seen major evolution in this entire space including coming from the launch of the iPhone, introducing HTML5 in the headset in a smartphone. And I think that pushed, that gave a lot of people a very rich experience and seeing what HTML5 is capable of. As for Ecma, we are compatible with Ecma 5.1 for server side JavaScript and I think we will see a lot of adoption for the new standard EcmaScript 6 in Firefox or Chrome browsers and probably the rest of the browser world will follow.
Dio's full question: These days there is a great debate about using JavaScript not by itself necessarily but like some sort of assembly language for the frontend and there are different ways that people are doing this. We have GWT for lock time, CoffeeScript now Dart and other approaches, which way do you think is more appropriate, or which one of these approaches do you think has a better chance to be more mainstream in maybe a couple of years or even if you think that EcmaScript 6 will be enough?
That is a very interesting question, a very big question and I think I really appreciate all those let’s say dialects of JavaScript like CoffeeScript, I personally also looked into CoffeeScript and I experimented with it. So far I have not deployed any applications using CoffeeScript and that is mostly because I’m used to developing in JavaScript and CoffeeScript is beautiful, it really adds syntactic sugar for JavaScript developers and same is TypeScript there are just announced. I think these are all great approaches and that definitely also had a huge impact on EcmaScript 6, so if you look at the spec of EcmaScript 6 you see a lot of similarities when you come from CoffeeScript, see a lot of similarities there.
So I personally like it, we are agnostic to it but it’s not necessary, you don’t need to use those dialects to be effective, there is other ways to structure JavaScript and I think you can also follow best practices basically on how to develop large applications and that is exactly what we want to give our developers, to give them a framework, a handle on which they can follow along and structure their applications in a very meaning full way, so that when they come back a month from now on to their applications they can still understand and they can debug into applications easily. So there is also some issues in terms of when you talk about CoffeeScript or some interprets on top of this, is first how do you debug into this, I mean you never have full control of what the compiler generates, and second when you then do a breakpoint in your browser you may not have synchronous breakpoints and stuff like that.
For TypeScript for example, you didn’t particularly asked about that, but I like dynamic languages and in dynamic languages you don’t necessarily have typing and you do not need typing if you have great tests and tools and that is what we really try to provide with Wakanda, give you the tools to write good JavaScript code.
Dio's full question: It’s funny you mentioned how the EcmaScript 6 spec follows some things that CoffeeScript has been doing, it’s funny seems not like up to a point, the spec was really driven by what was happening for example in the Python community, now is looking more to communities like CoffeeScript. How has been your experience working with end-to-end JavaScript applications, especially with medium or larger codebases? Some people stress the fact that it’s really nice to use the same language throughout your project and maybe some code reusability, how has it been for you?
You mentioned there are many developers out there that know JavaScript already and they have used JavaScript with PHP or they have used with .NET and so forth so there is huge mind share out there using JavaScript and applying that knowledge now on the server is like the next best and easiest step for them. They would not have to learn another language but the issue is how do you structure your codebase? As the application gets bigger, how do you basically keep the loose ends all together and how you structure it? So on the client side you have things like require JS that might help you get the pieces and load dependencies on the server side, you have NPM or CommonJS modules to piece things together and for the Wakanda approach it’s really as I said the data model is the core piece of your application, so you really try to get as much business logic into it and to code using that model and basically it gives you the structure to handle big applications.
13. Are you using some mechanism for loading modules on the server like CommonJS modules?
Yes, Wakanda server is compatible with CommonJS libraries and we can just load them in.
That is a great question, I think that there are many pit-faults and one is like: “What is your programming model?” When you are really into asynchronous type of application development and you are comfortable with it, there are solutions out there. So speed is a consideration and scalability is certainly a consideration and that is why we say: “You can use your existing way of programming and we give you multi-threaded JavaScript on the server side”. So you don’t have to change the way you develop, you can use the same patterns that you have use before.
On the server side it’s completely synchronous, so you would just write linear code that you can debug really well and when you use asynchronous, it becomes complicated very fast, it has also huge advantages in terms of speed but we have overcome that using multi-threaded.
16. Are you using things like Workers for emulating threads?
No, on the backend on the Wakanda server we using threads so every request does not necessarily have to spawn a thread but they spawn threads so it’s thread-safe our framework, and we also have web workers to have a separate process.
Dio's full question: It seems that new teams that are using JavaScript are having issues with scaling large codebases and especially they are if coming from other principles, for example from .NET or Java world, you have all these patterns to help them for example have you or any of your clients been having codebases that are going out of control or something like that? If you google the phrase “Spaghetti Code” most of the time you will see in the same sentence as the word JavaScript.
You are right, so those are the pit-faults really. I mean that is sort of going back to the same answer that I gave to your previous question which is, we’re really trying to guide out developers using this model driven paradigm. We say like “Focus on the model and put as much of your code in that model, and this is how you avoid spaghetti code”, but we cannot prohibit that they would still add things that make it extremely hard to maintain that code, but we provide the environment to develop in an entity sort of model driven way and we provide a test environment so you can ensure your application runs properly.
I mean, a lot of the problems that you run into as a web application developer have been addressed by HTML5 for example or talking about local storage, or communication between the client and the server using Chase and all of those things, all the technologies that exist. It strikes me sometimes how difficult still is to decide as a developer which library to choose, and which one is the one you’re supposed to use and when you are on a project, you really need to fix or address a problem quickly and you want to really focus on your problem and not about all the dependences that you have on all these packages. So that is where we are coming in and saying: “Here is the package, use the language that you like the most and you are used to, and you can focus on the problem at hand and dig right in, so I think all the technologies are there today in terms of HTML and JavaScript but weaving them all together, giving developers the right tools I think is something that we are really good at addressing.
Dio: Thank you very muck Juergen!
You are welcome!