Will framework survive RIA? I hope not.

Everybody knows that frameworks are the best way to develop large applications, aren’t they? This type of the common knowledge is dangerous – good indication that cycle is over and it is going to become obstacle. So, is framework friend or foe in the age of RIA applications?

I think frameworks can be bad for application development. Here are some of the reasons:

  • They enforce certain patterns, code generation and separation that may be not appropriate – you end up of more code that should not be there to begin with
  • More difficult to debug and maintain as you have a lot of framework code processing your flow – longer stacks, unpredictable reactions, extra bugs.
  • Forces thinking of “adoption” of the framework sample application as your application prototype

Most importantly, patterns like MVC are not necessarily best implemented as external framework. In RIA world, intelligent controls like SuperDataGrid, DataForm, etc can have databinding, all the way to the back-end and provide MVC patterns INSIDE of the control – giving you all the hooks dictated by pattern, but removing the complexity and extra code. In the age of RIA, more controls of that sort will emerge, forcing you to make a choice between conventional frameworks and controls that take care of you. When was the last time you thought of using framework on the top of Excel or Word or any other component that is self-sufficient for the end-user?
For me, frameworks that force to separate programs in views, commands, etc. are like forcing everybody to build/use cars with manual transmission. Manual transmissions are more efficient, have advantages in performance and easier to maintain/repair. They have most vocal advocates ( for record, never convinced the guy who is responsible for “usability” here at Farata that clutch is a good way to do it). They suck on small projects like in-town commute. As for the future (and present for some of us) – good luck finding one in the hybrid or electric cars. Platform is changing, more functions are in platform, less control needed on outside – just enjoy the ride.

Anatole Tartakovsky

PS: I will spend next month collecting statistics on the projects that use frameworks and not use them – including code size per function and success / failure rates. I can be biased as I derive my current sentiment from the projects done 10-15 years ago and few “Save our project” kind of assigments I got involved lately. If you have good or bad experience using frameworks please send me your comments so I can include them.

9 thoughts on “Will framework survive RIA? I hope not.

  1. You say frameworks are bad because they enforce certain patterns, then what you’re really saying is the patterns being used are inappropriate for a specific case. Which may be true, but wouldn’t that mean there’s a lack of understanding of what patterns are out there. A knowledge of all patterns is beneficial in helping one decide on which patterns to use.

    But are you saying that the existing frameworks prevent you from choosing the most appropriate pattern to help solve the problem because the framework is NOT general enough to accommodate any and all patterns?

    Maybe its time step up a level and have patterns that separate out the platform-independent elements of the business logic from the platform-specific elements used to automate it. Then implementing software systems would come closer to the way building are designed and built. The design would be independent of the materials and construction techniques used to build it.

  2. Agree with you very much. I’ve gone through 2 books now on building database front ends using Flex 2, and the “proper way” of constructing these apps is horrific – to create a simple data form means duplicating every field name to 3 or 4 different places of code, and there is a huge amount of transfering objects from component to component – it becomes spaghetti-ish.

    I come from the Delphi world of creating db front-ends, and Delphi was always fantastically fast and flexible. What would take me literally half an hour in Delphi would take 2 days if I used these Flex “best practices”. Ugh. I may just drop Flex and look at the new “Delphi for PHP”.

  3. Anatole, you sound like you are advocating moving to a more, err, PB-like construct? :)

    I agree that a lot of GUI MVC design is overkill–especially if your data is form/grid oriented and almost all your data manipulation/interaction is through those controls. Much easier to say grid.getMyData() and then grid.saveMyData() and be done with it.

    However, in a world of SOA where the backend isn’t as malleable as it was in the PB days, MVC frameworks give a nice way to ensure separation of concerns. Of course for enterprise applications, developers tend to have a lot of control over the middle tier.


  4. Hear! Hear! Let’s stop this nonsene of reusable components! Let’s develop everything from scratch, it’s the only way to be completely in control. Let’s reinvent the wheel every time we need to go somewhere.

    This is the worst load of bollocks I have read all day.

  5. Steve,

    DataGrid is MVC construct. Framework is already in. Building framework over framework does not always work as expected – the complexity rises very quickly.

    If you looked through our presentations / code we advocate more developer’s control on each step of the way – including middle tier. As a matter of fact we are building communications squarely on native DTOs and FDS’s ChangeObject making sure you can bind any standard Flex adapter you can think of. In the same time we have our own one with better deployment model, transactional support and built-in flow for automatic updates in relational environment with referential integrity. In the end of the day you have 99% probability that your SOA has to serve those.

    At this point of time more then 50% of the new Flex developers are former ColdFusion/PHP users and having streamlined, faster-then-ruby-on-the-rails PowerBuilder like approach would drive the adoption a la ’92. As far as people as advanced in SOA as yourself – I do not think you are in day-to-day “application” development. Think what PFC did to developers in 96-97 – with overhead/ limitations / structured approach – do you want the same here now?

    Let us be realistic here. Flex is client framework. There is FDS middleware/driver to connect to your Java / middletier framework, but most of the Flex development happens on the client. Middle tier is already distributed, configurable and switchable. 99% of the time (assuming retrieve and update do not take long) middle tier is irrelevant – assuming it is communicating properly and does not add complexity. PB was completely on it’s own – with ideas like dynamic create/modify/scripting inside datawindow, VM, classloaders, etc. At best, it will take another Flex 2 years to reach PB3 level of robustness and simplicity for application development.

    You add it all up – and see it as a spiral, not as linear progression. Drivers have changed, you got transparent distributed architecture in non-homogenic environment – but the strength of the client portion is still to be uncovered.


  6. Theo,
    Flex controls are reusable – I use them. Frameworks for Flex I have seen have very limited applicability to the cases that used them. In most cases they provided “support” – registration, delegation, control, etc. – sometimes they help by orginazing your code, more often they turn it into large beurocratic mess.

    The post was not about reinventing the wheels, just about the quantity and quality of them you need to make your vehicle. But I would encourage you to take a look @ one in your vehicle – you whould notice that a lot of things are packed into one – including breaks, safety and ride protection elements, etc.. Some things have to be in-place. They are also going to be different for your bike, scooter, rollerblades, board or computer chair. Mainstream applications define scope of reusable components.

    But I am open to design of the computer chair with bike wheels – opening possibilities to people with special needs. Again, the scale of application drives the selection of components, and not the “pure” design.

    Anatole Tartakovsky

  7. John,
    Glad you found us. Please ping me offline – I would like to see if our “5 minutes” approach is what you are looking for in terms of Flex DB development.

    Thank you,

  8. Unfortunately, these days many programmers turn into configurators. They prefer spending time learning how to configure XML of a particular framework instead of writing code. I raised a similar concern about overuse of frameworks in the Java world in the JavaLobby post “A new breed: Framework Java coder“, which was about people who do not know how things work and assume that the framework will do the job. I was surprised that lots of people who left comments there said that it’s OK to not know what’s going on in your program.

    Flex is a domain-oriented programming language that covers the GUI part of Web applications, and we should not overcomplicate programming there. I’m for reusable components vs. frameworks here. Sure enough, we need quality self-contained components thar are losely coupled with each other.

  9. Separation of concerns is a valid point, inherent in Flex architecture. When a DataGrid is populated from a POJO via the AMF protocol, we have MVC at least twice, depending how south of API the point of view is. The main issue to realize, I think, is that time-to-market expected from Flex should put further separation of concerns in a very pragmatic corner. I have observed concerning incidents when Flex has been labeled as not matching the expectations. The problem is two sided, of course. Flex has been, IMHO, intentionally and rightfully introduced NOT as RAD approach to penetrate the market faster and easier; highly automated solutions are hard to “swallow”. The question is whether Flex will become RAD eventually and how fast.

Comments are closed.