While the TechCrunch50 conference was occurring, I was watching to see what development oriented tools would appear. At most of these type of conferences, someone always tries to launch some new, exciting and easy way to build applications. This TC50, there was one company that looked interesting, FluidHTML. FluidHTML does have some interesting technology, and it definitely could be an interesting product for some uses. This is what the company says FluidHTML can do:

FluidHtml is a text-based markup language (like HTML) that lets you dynamically generate Flash  content. This is an extraordinarily powerful idea.  It means that anyone can build highly animated websites, ads, media players and 3D animations quickly and easily.

As you can see, the main idea is creating flash content easily and make flash development easier as well. This is a fine direction and I hope they do well.

However, I have a problem with the way this is being seen. Admittedly, FluidHTML could make your website look very cool, and that is a big part of your web application. But there is a lot more to an application than the polish and finish. If we go back to my table building analogy, the finish is equivalent to the web design portion of the web application:

The web designer would look at the table and try to figure out what would make the table stand out from other tables. Maybe the legs of the table would have a lighter natural oak finish and the top of the table would get a rich cherry finish. They might bevel the edges of the table for a more distinctive look as well.

I am all for making this part simpler, but people tend to forget that applications typically have much more code behind the scenes. If you are an ecommerce site, there is the product catalog, the shopping cart and the payment engine. The product catalog is a mixture of database code (or whatever persistence architecture you choose), some application logic (which product to show on a given page) and the presentation (using something like FluidHTML). The shopping cart is mostly a server side function and contains the same mixture of database and application logic with minimal presentation elements. The payment engine is almost all application logic, with a little database code, and almost no presentation layer. Granted, an ecommerce site is not your average site.

However, what if we look at a content management system (CMS). Obviously, content management should be presentation heavy, right? Well, not exactly. A CMS is really a way to create pages without needing to know all about HTML, CSS and other web technologies. In a CMS, there is a lot of application logic, some database code in order to store the content, and some presentation typically taken from a “theme” or bundled CSS code.

So, FluidHTML and other presentation technologies are really just a piece in the grand software development puzzle. Some of you are probably wondering whether there are technologies that make the whole development process simpler. There are others that are probably screaming at me for ignoring certain technologies as well. There are software packages to make some things easier, like workflow management, CMS, and even ecommerce engines. There are also technologies that help us link things together or make components, like web services and osgi.

The problem is that software is not the same as the business processes they are supposed to support. Software development is complicated for a bunch of reasons. You may have an ecommerce site, and you may want to use one of the freely available engines. However, you still need products to sell. You will also want to customize the site to suit your business. So, even though the technology portion of the application is mostly supplied, it still needs to fit your business. In the case of an ecommerce engine, you may need to just skin, or design the presentation. In the case of something like workflow management, there is configuration and integration work that needs to be completed. What workflow are you managing? It is likely some business process, but that information needs to get into the system in some manner. Workflow management systems just make the software side of the process simpler. There are simple hooks into email services and approval hierarchies. But, your business, or the actual process you are trying to manage, still needs to fit into the software.

The other side of the story is that when certain things get simpler, people want the software to do more. For example, WordPress is a great CMS system. However, major corporations would like more from a CMS, and there are companies to support this. An enterprise level CMS must include things like approval workflows. There has to be a way to simply create new page layouts and new themes. WordPress does not provide all of this functionality directly and even some of the major CMS vendors lack in some areas. However, if you go back to the year 2000, many corporations would have been ecstatic to have something as simple and extensive as WordPress.

As developers bundle more functionality together, the business processes become more complex. Why? It is because you have made the previous complex process so much simpler that the parts that are remaining now look complex or difficult. As systems get larger and larger due to additional functionality, they tend to get more brittle. As applications get more brittle they fall out of favor, or the idea of large, monolithic systems falls out of favor. Then we get new companies that do a small part of the picture really well, like FluidHTML. And the cycle starts all over again.

http://static.zemanta.com/readside/loader.js