What does “modern” mean?
Business users. I understand your customers want/need something, ours want/need something different. The world is not binary 
For me what Chase, Discover, Fidelity, United, etc. are doing on their websites once you login into your account. A lot of changes in the last few years to make the account application more “modern”.
2 Likes
At least I can tell you that the “web app that looks like a desktop app” is not what they consider modern.
The real definition is up to debate I guess
This tells me not a lot I’m afraid, I don’t know who these people are or what they do.
Again, what Chase, Discover, Fidelity, United customers want/need and what Chase, Discover, Fidelity, United employees need is very different. Besides Chase, Discover, Fidelity, & United are unlikely to ever be using Xojo for customer facing websites but they might consider Xojo to service their employee’s needs. In fact I have a number of “major customers” using Xojo internally.
1 Like
A couple of years ago I presented a customer with a prototype of a web app I made with Web 1.0 their first reaction was to comment on how outdated the UI looked. So I was an early adopter of Web 2.0, delivered the project and it’s been working for them.
As I’ve said, personally I like the web app that looks/works like a desktop app. But not everyone does.
2 Likes
Bank, credit card, investment, airline. I can also mention supermarkets or other companies in the USA. All going for that “modern look”. Also banks in Mexico doing the same, changing the way they present transactions to their clients to be more “modern” (I don’t know other countries, sorry).
And that has nothing to do with my answer, I was just answering what a “modern” look is. Great that your “major customers” does not need/want that “modern” look but there are other customers that prefer that “modern” look. And the best thing is that you can get the modern look or not with both Web 1 and Web 2. So I don’t know what is the problem with some look modern or not.
Was it customer facing or internal for employees?
Sorry for the misunderstanding. And yes the “modern look” can be delivered using either Web 1 or Web 2. Many here are apparently equating website-like and modern-look as the same thus the misunderstanding. Point being customer facing software must always have the look and feel those users expect, but for internal employee facing software the level of workflow efficiency usually takes presidence.
2 Likes
P.S. I have always tried to deliver attractive, “modern-looking” software even when I was limited to character based DOS. The original IBM character set had some very interesting graphics characters that could be used in many creative ways. Back then with FoxBase I had to write my listbox using assembly language. Now those were the days. Lol
Internal app for employees.
As AlbertoD has pointed out a “modern look” can be achieved with both Web 1 and Web 2 although with Web 1 the programmer has to make a conscious effort not to fall into a not so modern appearance. I always try to strike a happy medium between efficient functionality and any one particular style. In the end, though, it sounds like your customer was happy so that’s what really matters.
I think that’s what’s important: Happy customers 
There are many different types of customers and developers. And as they say: Horses for courses. We use the tools that make our customers happy.
That will work until you have to go from Intel to Apple Silicon (on old software and if you’re running Apple computers).
And that do not means they will release a modified version in the future…
As usual, Michel knows how to conceptualize things and how to explain them well.
Yes, but it’s still stressful to use a framework and an IDE from the past. And of course it’s not wise to start a new project with a no longer updated framework.
It’s not the same to say “we’ll still support 1.0 projects” and to say “Xojo offers two web frameworks: one for desktop-like apps, the other for more fluid apps, and better suited for touch and small devices”. And for a certain audience, important for Xojo I think, the “who can more can less” concept (one framework for all) is not attractive. And the maintenance costs of the desktop-like web framework (with last IDE) would be low now.
1 Like
I worked on Web 2.00 to come up with RubberViewsWE 2.00. It is not as evil as some make it to be. It is simply a bit alien for people accustomed to Web 1.00.
The thing that many don’t remember, or realize, is that Web 1.00 required a good content of JavaScript/CSS to work perfectly. So is the case for Web 2.00. It is no more offensive to use JavaScript and CSS to get proper results in Web 2.00 than it is to use declares or plugins in Desktop.
I read that using a different language was not cool. The numerous JavaScript workarounds I posted all these years don’t require knowledge of the language. Most of the time, it is just a copy paste away, like a declare in desktop.
The perfect language simply does not exist. A good programmer must be able to apply workarounds to get to some results. There is nothing outlandish about it. I have applied declares or even machine language ever since I started back in 1982.
Now, would it be cool to start a project in Web 1.00 rather than Web 2.00 ? If the idea is to have an app that looks and behaves like desktop, perhaps. But frankly, my next big project will be in Web 2.00.
1 Like
If Xojo were willing to release a Web Classic product (with Apple Silicon support and a few other little things) it would make a LOT of people here very happy. Web 2.0 may become far “less raw” in the future but until then MANY of us would prefer a Web Classic product. Heck, I’d even be willing to help support it. I have as much experience using Web 1.0 (over the last ten years) as anyone.
1 Like
There are a few reasons that I don’t think this is going to happen:
First and foremost, because of how the Xojo IDE is constructed, it is darn near impossible to support two different classes that have the same exact name. Having two WebControl objects with different code inside exist in the same project is (and was) a non-starter. This is also why each target has a different prefix on its controls. Could this be remedied, yes. Will it be? I highly doubt it because the bang for buck just isn’t there.
Second, web 1 was designed in a time when the web frameworks like jQuery and Bootstrap (and all the others) either didn’t exist or were in their infancy. This meant that the entire framework had to be written from scratch. This was 2008-2010 after all. Thom did an great job putting things together at the time, but as browsers evolved, it couldn’t take advantage of newer technologies designed to quickly deliver the app and it’s ongoing data to the page. Web 2 started with jQuery and Bootstrap so the framework could evolve over time as they were seen as the frameworks most likely to survive over time, and a lot of web sites & apps were using Bootstrap at the time, not to mention the plethora of controls that are available for bootstrap.
That leads into controls. One of the things we learned from web 1 that we didn’t want to repeat in web 2 was the ui of the controls. As was said above, web 2 was designed from day 1 to look like a web app because the whole idea of making it look like desktop was a long abandoned idea even in “modern day” designs. Couple this with how hard they were to maintain and we decided to add a wrapper on top of existing controls so we would have a base set of controls on day one.
7 Likes
Because I accidentally pressed the Reply button…
Then comes the back end framework. In the original framework, Real/Xojo used what it had, an HTTP/1.0 web server that did only what it needed to do to serve pages, and HTTP/1.0 itself had some design flaws that caused very heavy memory usage and slower than necessary data delivery times. Over time we remedied some of this by adding some HTTP/1.1 support (gzip most notably) but there were things that we couldn’t add without redesigning from the ground up which were required to call it a truly HTTP/1.1 compliant server. The changes required ended up being so extensive that it was decided to design the new web framework around the new structure. Web 2 (like the other frameworks) was designed from day one to provide the bits that the average user couldn’t easily do, a basic set of controls and an easy way to create your own controls if you knew JavaScript & CSS. If you’re a Xojo Cloud user, you can see several custom controls in the control panel which were designed to handle special situations and they were created rather quickly.
I know that a lot of you loved web 1… lord knows you’ve told me that over the years (some even screamed it thinking that being louder would somehow change my mind after the fact) but the reality was that I was tasked with creating the next web framework. Something that would be easier for Xojo to maintain, which used newer technologies, which would better fit into what end users expect a web app to look like and would survive another ten years of changes on the web. Stick a load balancer in front of web 2 and it can handle many more sessions per instance than web 1 ever could. That’s what you should have been doing all along anyway. IMHO, the use of a Perl helper app was a non-starter from the get-go. The memory overhead was just too great and the solution was fragile at best, but it’s what we had in the beginning because load-balancing didn’t really exist back then. Over the years, and as Xojo evolved, fixing and updating web 1 took more time than we had available and we took the opportunity to start over and build a new foundation.
10 Likes