This last year I took over more software projects from other development firms and consultants than ever before. Almost universally the business stakeholder tells me something like this: "Such and such firm agreed to build XYZ for $XX,XXX. Things started well and we have completed and paid for 80% of it and now they are stuck."
I am stoked about XDC and many of the presentations that are on the agenda. I’ll write about that more later but there is one that stands out to me:
Web Framework 2.0 | Greg O’Lone, Xojo Inc.
The Web Edition of Xojo (then REAL Studio) was released in Fall 2010. Since that time very little has changed. I cannot think of any additional widgets from the original feature set but perhaps there is a handful.
It was in some ways ahead of its time and in others behind it.
For example, there still is not really a competing product or environment that can produce web applications as quickly as Xojo Web. Single page applications were not very common in 2010 and certainly there were very few frameworks for building them. Angular released around the same time in October 2010. Both React from Facebook and Vue were released in early 2014. Even with those frameworks the time to develop in them is significantly longer than using Xojo Web.
The product has aged gracefully and even kept pace with modern environments despite being relatively untouched over its seven-year lifecycle. There have been slight improvements here and there but it is largely the same product as when it was released.
Identifying the top weaknesses for Xojo Web currently:
- No responsive design capabilities which makes building for different devices painful.
- Outdated and not very secure embedded web server:
The built-in web server is HTTP 1.0 compliant only and has some considerable security and performance implications. For example, it is very easy to perform a denial of service attack on standalone Xojo web apps.
Most of these issues are mitigated by sitting behind a load balancer or running in CGI mode like we do at ServerWarp. Xojo Cloud operates their apps in CGI mode so you are good there as well. However, those of you running standalone on your own servers need to be mindful in this area.
- Lack of new and updated widgets for modern web usage.
- Building web services to interface with other desktop and iOS applications built in Xojo is way more work than it should be for a RAD platform. See my product Rapid Services for a way to improve this and build web services as fast as you can web applications with Xojo Web.
- Web styles leave a lot to desire in terms of skinning and maximizing web application aesthetics.
I have a vested interest in the Xojo Web product as we operate the largest Xojo web hosting platform not owned by Xojo, Inc. I have launched and operated hundreds of these applications in standalone, CGI, and load balanced modes. I have seen and worked with many of these customers to help them get the most out of their applications.
My biggest fear with Xojo Web 2.0 is that the desire to “build something new” could hurt the product. If Xojo completely switches to a responsive design then it will be nearly impossible to support the existing web applications which are based on fixed locations on the HTML page.
It would be cruel and difficult for customers if you said starting next release you can no longer work on your existing Xojo Web project as the new web framework is fundamentally incompatible. You could support Xojo Web v1 projects but then you end up with essentially another target. How much support and updates do they provide to Xojo Web v1 or is it considered legacy and only maintained such as the classic vs new framework debate.
The term responsive design was not coined until May 2010 and while the idea existed via other terms like fluid, elastic, etc. it was not widely deployed. I do not fault Xojo for not supporting the paradigm. According to Wikipedia; Mashable labeled 2013 the year of responsive design. It has been pervasive ever since.
Consider for a moment how responsive design would actually work in the context of the IDE. The fact that you design your web application in a similar manner to desktop apps is a nuanced, sometimes awkward, but surprisingly consistent experience. I cannot fathom a responsive design framework that would work reliably in the IDE.
I am also concerned we may get some version of the auto layout tools used for iOS. Those are terribly unintuitive and challenging to produce the correct results without much reading, manipulation, trial and error. I personally would find that extremely frustrating if used on the Web.
Between the IDE challenges, project backwards compatibility concerns, and general risks involved with a new target or framework I take pause with a “brand new framework”. I think Xojo should be focused more on finishing the new frameworks they have already started. I understand for purposes of marketing that having fancy new features and targets is advantageous. I would just like to see a new control for every supported platform each release. If that cadence had been maintained Xojo Web would not need a new framework today.
Let us assume that Xojo was not working on a new web architecture. I have a list of things I would like to see improved in what we have today. If done correctly I think Xojo Web would be future proof in the short term and allow them to focus on iOS, Android, Windows flicker, etc.
- Instead of breaking your current paradigm of fixed location widgets in favor of responsive design; How about presenting three views similar to how you do it with iOS.
A smart phone view, tablet view, and desktop view. You would drag widgets to each applicable view depending on whether they should appear and how they would appear. They would share a name across all views so your backend code is not concerned with the size.
When necessary you could still use the Session.Platform identifier to handle specific circumstances. The infrastructure is already there we just need some design time IDE enhancements to optimize for the varied screen sizes.
- Update the embedded web server to support HTTP 1.1 and 2.0. Let’s also add in request timers, content length verifications, and pre-request body header analysis to prevent and stop various attacks or bad requests.
- Add some user controls. Date picker would be a good start. I have never seen a RAD tool sold without a date picker before.
- The Web SDK via WebControlWrapper is not actually that bad but the learning curve is pretty high. I would like to see some work on making that easier or supporting some of the larger toolkits out of the box.
- See Rapid Services for a better way to implement web services creation and consuming.
- Styling and theming Xojo Web apps needs a major overhaul. I have built an entire theming library for Xojo Web for some of our applications and I plan to release soon. GraffitiWeb and others are great but for widgets but making your application look good is still too hard.
I am curious how many of you share my priority list and concerns regarding a new Xojo Web? What are you looking for in the next version or to be improved upon in the current?
I would like to share an article I wrote on my LinkedIn about designing great software. I believe great software design encourages better adoption and more accurate data in software. As such it is vitally important that software designers embrace the user experience with empathy and do the extra 5% necessary to reach the next level.
I offer some questions that need to be answered for great software projects to be built and examples of why it makes a difference.
Read it on LinkedIn at: https://www.linkedin.com/pulse/successful-employees-need-great-software-phillip-zedalis/