Blog 

El Blog

de Lucasian Labs

GTK + Chromium + Clojure + ClojureScript

18 Agosto 2013 Escrito por 
Publicado en Colaboraciones
August 18, 2013

It’s been a while since I wrote a desktop app. I have an idea involving something called “FIEL” (you personal digital signature in México), and I’ve read some really good things about C++11, so I decided it was a good idea to try and build something with those two.

There are a few GUI frameworks available, but to be honest I don’t really grok GTK, QT 5 looks nice but there’s all those IDEs and and XMLs and I’m not really an IDE person.

After a little research I found the Chromium Embedded Framework sounds pretty good, there are some good points:

  • Ubiqutous frontend technologies You can just use what you’ve probably been using the most for frontend: CSS, JS and HTML
  • JavaScript interoperability You can write you JS functions with native C++ and export them, using Chrome’s V8 API and call JS from C++. So you can open files, connect to databases, download things or do whatever you want with the host OS.
  • Supports some neat things Like WebRTC!

Tha bad side:

I’m complecting things together, but that’s OK. I really want to do this.

But behold! There’s more complecting waiting for us.

For this app I have a strange use case, I need to be able to call some custom Java classes to sign and encrypt, yeah I could use openssl, but eventually someone is going to ask me to add those JAR files.

So, I embedded a JVM!

Ok so let’s take a step back, and check where we are:

  • We have JS for the frontend
  • We have Java for the backend (Not really, I don’t mean to use Java for anything else than SSL, well.. maybe the scripting API would be a nice fit for something)
  • We have C++ as duct tape

I know what you are thinking… everyone’s favorite platform runs on top of the first two… Yes, I’m talking about clojure!

So… it doesn’t hurt if I write clojurescript instead of Javascript and Clojure instead of Java, right?

At least it sounds interesting, I’m half way through it but it seems that it’s going to work.

Let me show you:

Firmavio starting

It does nothing, but I think it is a good starting point for every desktop app that I write from now on.

BTW you can check the code here


comments powered by
Valora este artículo
(0 votos)
Eduardo Diaz

Eduardo works at Lucasian Labs México as a software developer engineer. Proficient at Java, and Javascript, he is also very interested and involved in Ruby, Clojure, Scala and a few other things.

Artículos relacionados (por etiqueta)

  • A modern web frontend vision
     
    June 9, 2013

    We are living exciting times when it comes to web technology we are really close to having for instance:

    • Functional programming for the frontend.
    • Close to native performance for webapps.

    Let’s check each bullet closer.

    Functional programming is becoming a hot topic, and we can see how a myriad of languages that have been living for longer than the languages we use are becoming now important.

     

    Scala, Clojure, and Haskell are good evidence, but even better are classic imperative languages getting functional features. Ruby, Groovy, Javascript’s lodash and underscore. And finally… Java 8 is getting “lambda blocks” or functions as first class citizens.

    Why is this happening?

    Multicore architectures are the hardware’s guys bet, even my 200 dollar phone has two cores in it. Software guys need tools to use those multicore architectures. Functional seems to be a good bet, it makes concurrency easier, sometimes even automatic (Clojure’s map function is always multicore wheter you like it or not).

    Ok, but why is this relevant for the frontend?

    Node.js had a vision, what if instead of writing wrappers between language constructs we could communicate transparently the frontend and the backend? And not only that, but having the same programming paradigms, syntax and semantics available wherever you are?

    Javascript for the backend was the answer, we could use Google’s fine V8. It seems to be working… LinkedIn, Microsoft, Yahoo among other companies have found a good place for Node.js.

    But couldn’t it be the other way around? Isn’t it possible to use a backend, nicely engineered language for the backend? (Not to say that javascript is a bad language, I actually love it, but let’s face it.. there are a ton of ways of using it’s bad parts).

    Well, there is. There have been some efforts, like Google’s DART, Coffeescript, Clojurescript. Let’s talk about clojurescript, a Lisp for the frontend.

    Really, a Lisp? In the 21st century?

    Yep, and it is really nice, imagine the power of lisp’s simplicity for the frontend, even better imagine you can jump seemlessly between frontend and backend code which is clojure. Nice, huh?

    Well, that’s Clojurescript, and it’s working. Relevance, a software development firm is using a complete Clojure stack for it’s development, and it has some pretty big customers, IBM, BestBuy, BBC, livingsocial. Granted, they also use rails, but there’s a lot of clojure going in there. They are pretty commited, having some Clojure’s core commiters, they have their own clojure web framework among other things…

    So, how does Clojurescript work? It has to be javascript in the end, so the clojurescript guys decided to use Google’s Closure compiler.

    But… things are not perfect, there are claims that the ui starts to slow down when you add things like angularjs to the combo. And it is completely normal, stuff like this happens when you have a zillion layers.

    But… worry not… there’s some hope.

    Performance is still a big problem when it comes to webapps, even though the javascript interpreters are making a huge effort to improve things. Week after week we se how Firefox and Chrome get faster and faster, and there’s some new kids around.

    asm.js

    Have heard about asm.js? It’s a VERY cool idea, and it involves compiling javascript into native code.

    How do you get that? The idea was to make javascript simpler, by defining a highly optimizable subset of it. Once you have a ver simple subset of javascript you can invest a lot of work into compiling it into native code.

    Seems too wild to be true? OdinMonkey will be released in a few weeks with Firefox 22, it already supports asm.js.

    Google seems to be interested in giving support to asm.js in it’s V8. They already made some optimizations without compiling to native the got a 2x performance boost in asm.js compatible code.

    What does all of that mean for me?

    Just have a look:

    Let’s tie the knots, just imagine this:

    • You write your webapp in clojure entirely, the frontend is Clojurescript, the backend is JVM Clojure.
    • The frontend is compiled into asm.js compatible code.
    • Google’s closure compiler further improves your code, generating asm.js compatible code too.
    • You get an extremely fast application, the backend runs in a modern JVM, the performance is close to native, you need not worry about concurrency, clojure handles it automatically. You frontend is asm.js compatible code, the app feels like it is a native app.

    What is needed to make this possible?

    • asm.js needs to mature a bit, the specification is still a draft, maybe Mozilla’s move with Firefox will make developers and companies interested.
    • We need more support for asm.js, it developers start using it apps will be much faster in Firefox than in Chrome, if Chrome embraces this, maybe Microsoft might make something to support it.
    • The clojure guys might change their compiler in order to generate only asm.js compatible code.
    • Google guys might tune the Closure compiler, to get even better asm.js code.

    We aren’t that far, and this is only a vision, the name of the technologies, and who implements them might be different. In the end, I imagine a world where you can use whatever device you want, a tablet, a phone, a computer. Any OS: Linux, MacOS, Windows, and you get an amazing user experience NO MATTER WHAT CHOICE YOU MAKE!

    Freedom is the important thing here, let’s work for that!


    comments powered by
JoomShaper