Single Page Applications fight - video

During the last wroc_love.rb conference we've organised a "fight" between 4 different approaches to Single Page Applications. Below is the video (0.5h) and a very short and simplified transcript from this event.

The participants, from the left-side:

Patrick Mulder - Backbone
Piotr Sarnacki  - Ember
Andrzej Krzywda (me) - Hexagonal
Adam Pohorecki - Angular

moderator - Jan Filipowski

1m39s

Can anything be a Single Page App?

(and discussion about SEO)

Patrick: only for some apps

Drogus: for interactive apps, not for static apps that need to be indexed by Google

Andrzej: for all the apps

Adam: we need better tools on the backend in order to have a better developer experience

Piotr: Andrzej, would you write wikipedia as a SPA?

Andrzej: Yes.

Adam: What about SEO?

Andrzej: It's a myth that SPAs are not indexable. Google has an official document for that. It is additional work.

Patrick: You can use PhantomJS for SEO.

Adam: We've used PhantomJS for that, took a couple of hours.

8m28s

Can you introduce the framework you're representing here?

Andrzej: HexagonalJS is not a framework, it's an architecture guide. Uncle Bob (OOP) + Raganwald (AOP) + Hexagonal Architecture. It's more like a set of guidelines

Piotr: EmberJS - it does as much as it can for managing your SPA. it's not minimalistic, for good reasons (you don't have to write much code). 

Patrick: Backbone, very small, minimal. you don't bring too much dependencies. you can choose what you want. 

Adam: Angular, Two-way data binding is the key feature. Synchronization of HTML and your JS. Choose framework with data-binding. Ember is essentially a language, forces its own object model. Backbone as well. Hexagonal or Angular is pure JS.Your application can live outside of Angular.You could use Angular with a Hexagonal app. Backed by Google, more mature than Ember.

Andrzej: Data binding is not as important as you may think. Manual control is not that difficult. Hexagonal doesn't have data binding jilt-in. Apps are not about data changes, but about actions

Piotr: I agree that data binding is important. Both, Angular and Ember are good for big applications. Nested views, zombie views (backbone). Angular has its own compiler for DOM elements. You need to know how the compiler works. Angular uses dirty checking. Angular claims that your UI shouldn't have than 2000 elements. You're screwed if you have more.

Adam: We built a 100 rows, 500 columns table. We managed to do it with Angular. It's not that hard to do the UI part. Directives are like helpers for html. 

22m6s

Do you have to take the mindset of the creator?

Adam: Most of the things in Angular are optional.If you don't use the HTML part, you lose a lot.

Andrzej: It's a problem of all of us here, including Hexagonal. We use different terminology for different things. All the frameworks are far from being Rails, we're not mature enough. All the frameworks are in their infancy years.

Patrick: It's easy to work with Rails and Backbone

Piotr: Ember has its own class model. It's done mainly for making it easy to optimise. Ember is about Convention over Congifuration. Rails in JS. Ember is like Rails, Backbone is like Sinatra. At some point you have to use more plugins if you start with something minimal. A lot of pain if you want to write a big app with a small framework.

Andrzej: I disagree. I would use a framework for a prototype or for a small app. Once the app grows, it has its own world. I don't want the framework to go into my way. I want to have the control over the applications. I'd use Ember for smaller apps, not for bigger apps.

27m23s

How to be involved in the community, how to learn the framework?

Adam: Angular has really good docs. All development happens on github.

Andrzej: Hexagonal has just started. It got the name just recently. We've used it for over a year. We have a strong team behind it. Our goal is to show the guidelines.

Piotr: Ember is 1.0RC now. Docs are better now. IRC is very active. Google Group.

Patrick: JavaScript and Ruby devs can help.

END

If you're interested in Single Page Apps, you may want to follow me on Twitter.

Why do projects take so long?

Some projects take a long time to develop. In different contexts, the definition of "long" may vary. It was always interesting to me, what are the reasons for it. Recently, though, it became my obsession.

I've started collecting some thoughts on this topic.

Ask yourself and your teammates about the last project you've been working on. "Would we be able to implement the same result in 1 month? In 1 week?".

Surprisingly often, I'm answering to myself - yes, that would be possible, given some assumption. I've had similar answers from my colleagues.

Where does it come from?

Is it the known tendency to underestimating a problem by developers? I don't think so, as we're talking about a project, that has already happened. We know what is to be done. We are aware of edge cases.

"This is time it will be different, faster"

This is another popular trend among us, developers. Most of us are optimistic, even the experienced ones. It's not some kind of a student-syndrome (I'll do it tonight), but a well-thought statement. Is it really different and faster? Not always…

Where does this optimism come from? Good developers become better at solving technical problems. With each problem solved, we know that we solved the problem forever. We love solving problems, every day we're smarter by this attitude. We're progressing and the optimism may come from that.

It's almost impossible to get a second chance of working on the same project. What would that even mean from a business perspective? We rarely get that chance.

Is it the technology that let us think, that we could do better this time? That's a serious candidate. Every time, I switched to better technologies or to better architectures, I noticed the speed increase. I was more confident. I saw the results.

I remember a situation, back in 2004/2005. I was involved in preparing an estimate for a new project. The estimate was about 6 months for 4 developers (assuming ASP.NET). Very shortly after that I learnt Rails. I realised, that the project is perfect for Rails. It was a CRUD-based web app. I kept convincing the management to give it a try. No luck. Finally, I had a chance of coding live in front of some managers. I implemented the main path in about 1 hour (I was well prepared). That convinced them. We've finished this project in 1.5 month, with one junior programmer and me being mostly a PM and a Rails mentor.

What's the lesson? It's hard to tell. I'm not trying to say that only Rails was the reason. Motivation? The passion behind it? Trying to prove something? The focus? I think it was a combination of all of the above aspects.

Is it easy to repeat those aspects? Do they sound familiar?

Have you ever attended a hackathon?

There are many kinds of hackathons. What's most important in this context, is how much can be done in a very limited time. If you look at the results of Rails Rumble, some of the apps are quite big. Many features, everything is polished.

Hackathons are proves that we are able to develop apps quickly.

How can we apply hackathon lessons to our every-day projects? Is it possible?

What else can help us developing software faster?

I would love to know your opinions.

Angular or Ember? Congratulations, you've already won.

At the wrocloverb conference we've decided to have a Single Page Applications "fight". (The format of fight worked pretty well last year for the JRuby vs Rubinius battle).

We're having Ember, angular, Backbone and hexagonaljs representatives. As I'm representing the last one, during the last few days, I've did more research on the other alternatives.

There are huge differences between all the choices. Some of the frameworks are like Rails, some are more like Sinatra. Hexagonaljs is not even a framework.

I have been making notes on the differences, collected jokes on each of the opponents. It's going to be a great fight :)

Anyway.

I realised one thing. If you're wondering which of the frameworks, non-frameworks to choose, you have already won. You are already in the world of Single Page Applications. There's no wrong choice in here. You will be fine with any of the frameworks.

There's a warning, though. I know many people who entered this world and they don't want to come back to the non-SPA reality.

Congratulations, that was a good choice!

Non-framework approach to JavaScript apps - hexagonal.js

This week we have officially launched and announced hexagonal.js.

The announcement was welcomed with a fair amount of interest. Jan Filipowski at the Arkency blog did a great job of explaining the basic ideas.

I'd like to cover the topic of hexagonaljs not being a framework.

What is a framework?

Some time ago I asked "What is a framework?". I liked the following answer:

In the case of a framework, your code is called by it. In the case of a library, your code call it. Rails is a framework, and provides libraries too.

I have a love/hate relationship with frameworks. That's why I struggled for months, what to do with the ideas that we're now calling hexagonal.js. I didn't want it to be a framework. That would ruin the whole experience.

Let me tell you a story on how it all started and why we didn't want it to be a framework.

The technical story of haxagonal.js

The first ideas were created when we were working on social web games at GameBoxed. Given the scale we were operating on (sometimes 4-5 social apps/games a month) we needed a high degree of reusability. Reusability requires good modularity. Often, we've had apps that have the same "logic", but they had much different GUI, sounds, FB integration etc.

We got the idea of use cases as objects from the DCI approach (DCI is much more than that!). We've experimented with the concept that it's the use-case that drives everything. Driving something (like playing sounds) meant calling it. Calling it directly meant creating a coupling between the use-case and the SoundAdapter, which didn't sound like a good idea.

One approach was to use events. The use case would trigger an event and the adapter would bind to it. It resulted in less coupling. It wasn't bad. To me, it wasn't yet the final solution, though. I didn't like the fact, that the use-case objects were full of "trigger someEvent" statements.

When I looked at the events, I realised that they happen usually at the beginning or at the end of a method in the use case.

Before, After....

Wait, wasn't that what AOP was about?

Introducing some simple AOP techniques (thanks to awesome Raganwald's library!), we have achieved exactly what was needed. This is what we currently call a Glue code. It's almost like a configuration, in most cases. No logic, just declarations.

Hexagonal architecture

We started with MVC in mind. The most basic rule of MVC is that when the model changes, the views are notified about it. After some time, we've realised that it's not only about views, unless you try to fit "playing sounds" into the View layer ;)

In a hexagonal architecture, GUI is just one of the adapters. It's usually the most important one, but technically, still, just an adapter.

In many apps, the GUI is the only adapter.

ServerSideAdapter, PusherAdapter, SoundAdapter, FirebaseAdapter, FacebookAdapter, LinkedInAdapter - those are just examples of the adapters, that we used so far.

It's not a framework

Given all of the above, we were struggling on how to bring this idea to people, without making them depend on any framework. The whole idea is a bit anti-framework.

Hexagonal.js is not even a library. It's mostly an architectural style adapted to JavaScript apps. We provide many examples (and more in progress..), that can guide you. You can copy them, fork them and have a good starting point.

It's probably a slightly unusual approach to deliver some ideas to you. It's not a framework, not a library.

Hexagonal.js is a set of good patterns that are extracted from real-world production apps. It was used to build dozens of apps, with a good speed of development.

You can look at the examples we already have. Look at the use case object, the glue and the adapters. It's a pattern that reappears in every hexagonaljs app. There is also an example of using it from a Rails app.

Tell us what you think about this approach. We've published it to bring more ideas. We're open for suggestions!

Thanks for reading.

Frontend first

Some time ago, I blogged about the different phases of mental transition when working with JavaScript frontends. Here's the shorten version:

1. No-JavaScript phase

2. JQuery explosion

3. Page and Widget objects

4. Single Page Application

Once you're in phase 4 and you create apps this way, you realize that you don't need the backend in order to create the Single Page App. Even more, you shouldn't start with a backend.

Frontend first

This is the additional phase. Frontend first. In most of the typical situations, it's much better to start with a Single Page Application and use LocalStorage or some kind of a InMemoryServerSideAdapter for the first phases of the development.

Only after you know how the frontend works and what kind of server interaction it requires, it actually makes sense to start working on the backend.

We've tried this approach in several Single Page Apps and it worked great for us. It now seems like the most natural way of working.

to learn more about Single Page Applications.

What is a framework?

The title question made me struggle for months.

1. What is a framework?
2. What is the difference between a library and a framework?
3. If I use a framework as a library, does it make it a library?
4. Is Rails a framework?
5. Is Backbone a framework?

Can you help me with your answers?

Rails legacy applications

The topic of Rails legacy applications is becoming more popular recently.

We, at Arkency, sometimes receive questions whether we can take control over an existing application. It's never an easy decision.

Legacy apps contain legacy bugs, which can quickly become "our" bugs. They often have no tests, or just failing tests. If you're very unlucky, you can find some really shitty code.

What's the reward?

This is a story of one such project. We can proudly say that we successfully fixed the mess, not only that, we also created some beauty on top of that.

Let me just say that it was such a pleasant experience that we decided that Arkency should do more such projects.

Challenge accepted! We're looking for more such challenges, email me if you have an old Rails app that needs to be fixed.

Read the slides of Michał Łomnicki to learn the details.

Having fun with legacy apps from Michał Łomnicki

Thanks to Michał and Paweł Pacana for the awesome work!

Let me know if you want to learn more about what we did and I will convince Michal to blog about it :)