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!
Saturday, February 23, 2013
Friday, February 22, 2013
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:
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.
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.
Thursday, February 14, 2013
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.
Thursday, December 6, 2012
What is a framework?
The title question made me struggle for months.
- What is a framework?
- What is the difference between a library and a framework?
- If I use a framework as a library, does it make it a library?
- Is Rails a framework?
- Is Backbone a framework?
Can you help me with your answers?
Monday, August 27, 2012
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.
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 :)
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 :)
Sunday, August 26, 2012
Is CoffeeScript better than Ruby?
If you are subscribed to our Arkency newsletter (we send an email every week or two with some interesting links and our comments), you probably noticed that there is an ongoing debate in our team - whether CoffeeScript (actually JS) has a good standard library.
I have recently watched an interview with DHH about his opinions on Single Page Applications.
DHH was explaining why they don't go the SPA way with their new 37Signals applications. They chose to generate JS and HTML on the backend and send it back to the client.
One of the DHH's arguments was that they prefer the Ruby stack (with Rails) than the experience of writing CoffeeScript application, with the server being just for JSON API.
Overall, I think that DHH makes some good points, but I don't agree with the assumption that it's better to work with the Ruby stack than with CoffeeScript. Sure, the patterns are not so mature as with a typical Rails app, so sometimes it takes more time to do the same thing, however their approach of sending JS is also not the most trivial one and it creates a complex architecture, IMO.
First, the syntax of CoffeeScript is better to me, than the Ruby syntax. This is subjective and I'm not expecting everyone to agree. To me, it's enough that the code is mostly shorter while still very elegant.
Second, the libraries. Yes, JS stdlib is almost non-existing. It's almost always better to avoid the existing stdlib and rely on sugarjs or underscore. Ruby is winning here. Now. With the growing JavaScript communities, we'll see a huge improvements very soon. The sugarjs library is already awesome and I don't feel I'm sacrificing anything by using it, compared to the Ruby libs.
You can improve the libraries, but it's hard to improve the syntax.
I may agree with DHH, that the SPA environment is not yet at the same level as Rails is now. Even DHH says that the situation happening with JS MVC is a huge shift. In my opinion (and not only mine), we see a revolution that can be only compared to Rails in 2004-2005. Back then, Rails also wasn't that mature, but we were able to use it and have a really well working applications (my first production Rails app was released in April 2005 and was used by hundreds of users every day).
Back to the title dilemma. Is CoffeeScript better than Ruby?
We need them both. The trend of SPA will be growing and we can't use Ruby there. On the other hand, it's not easy to use CoffeeScript on the backend (nodejs based solutions are nowhere near the stability of Ruby solutions) and Ruby is a great choice in there. In most of the apps that I'm currently working on, I spend like 80% of my time with CoffeeScript on the frontend and 20% on Ruby on the backend. That's my answer :)
I have recently watched an interview with DHH about his opinions on Single Page Applications.
DHH was explaining why they don't go the SPA way with their new 37Signals applications. They chose to generate JS and HTML on the backend and send it back to the client.
One of the DHH's arguments was that they prefer the Ruby stack (with Rails) than the experience of writing CoffeeScript application, with the server being just for JSON API.
Overall, I think that DHH makes some good points, but I don't agree with the assumption that it's better to work with the Ruby stack than with CoffeeScript. Sure, the patterns are not so mature as with a typical Rails app, so sometimes it takes more time to do the same thing, however their approach of sending JS is also not the most trivial one and it creates a complex architecture, IMO.
First, the syntax of CoffeeScript is better to me, than the Ruby syntax. This is subjective and I'm not expecting everyone to agree. To me, it's enough that the code is mostly shorter while still very elegant.
Second, the libraries. Yes, JS stdlib is almost non-existing. It's almost always better to avoid the existing stdlib and rely on sugarjs or underscore. Ruby is winning here. Now. With the growing JavaScript communities, we'll see a huge improvements very soon. The sugarjs library is already awesome and I don't feel I'm sacrificing anything by using it, compared to the Ruby libs.
You can improve the libraries, but it's hard to improve the syntax.
I may agree with DHH, that the SPA environment is not yet at the same level as Rails is now. Even DHH says that the situation happening with JS MVC is a huge shift. In my opinion (and not only mine), we see a revolution that can be only compared to Rails in 2004-2005. Back then, Rails also wasn't that mature, but we were able to use it and have a really well working applications (my first production Rails app was released in April 2005 and was used by hundreds of users every day).
Back to the title dilemma. Is CoffeeScript better than Ruby?
We need them both. The trend of SPA will be growing and we can't use Ruby there. On the other hand, it's not easy to use CoffeeScript on the backend (nodejs based solutions are nowhere near the stability of Ruby solutions) and Ruby is a great choice in there. In most of the apps that I'm currently working on, I spend like 80% of my time with CoffeeScript on the frontend and 20% on Ruby on the backend. That's my answer :)
Monday, July 16, 2012
JS frontends are like desktop apps
I noticed a trend recently, among developers, that we need to learn how to work with JS frontends. Obviously, it's great that people want to improve their skills, but is it really something new that we need to learn?
I suppose, that many of us at some point have been working on a desktop application. Was it a Java Swing app or a .NET Windows Forms or maybe Delphi app, doesn't matter that much.
What's important is that a JS frontend is very similar to a desktop applications.
Yes, they are not completely the same, we can do a few things that are easier in the browser than on the desktop app. Those differences don't influence the way we architecture the JS apps.
If you haven't had a chance to work on a desktop app then you're missing a lot, but still, it's much better to read about the desktop patterns, than to try the new shiny JS framework.
I suppose, that many of us at some point have been working on a desktop application. Was it a Java Swing app or a .NET Windows Forms or maybe Delphi app, doesn't matter that much.
What's important is that a JS frontend is very similar to a desktop applications.
Yes, they are not completely the same, we can do a few things that are easier in the browser than on the desktop app. Those differences don't influence the way we architecture the JS apps.
If you haven't had a chance to work on a desktop app then you're missing a lot, but still, it's much better to read about the desktop patterns, than to try the new shiny JS framework.
Subscribe to:
Posts (Atom)