New Web Framework

So I asked a similar question here about Android: https://forum.xojo.com/54117-android

Now I’m wondering the same about the new web framework… Now that XDC 2019 has passed, what is your feeling about how soon the new Web framework beta will be released? Are you thinking a couple of months or closer to 6 months or a year?

No timelines given beyond

https://www.bkeeneybriefs.com/2019/05/xdc-2019-ruminations/

API 2.0 Sept/Oct 2019
Web 2.0 Christmas 2019
Android Summer 2020

[quote=441726:@]API 2.0 Sept/Oct 2019
Web 2.0 Christmas 2019
Android Summer 2020[/quote]

  • a margin of 1-5 year…

Web 2.0 would be a great Christmas gift!

I think those are just W.A.G.s (wild a s s e d guesses) not actually any real dates that were leaked

Thanks Norman fro the precisions. Even if they were real dates, I still would expect delays and I’m aware that a 19 can easily become a 20 or even a 21… :wink: No offense to Xojo development team, this is just how it often happens. Even here at ML6, where we deal with much more simple stuff, we sometimes get caught with our promises…

I’m not sure what to expect from the new web possibilities. Sure hope it will atleast be HTTP/2.0 with HTTP/1.1 falback otherwise we will be behind everything else again. But the “framework” will be focussed around an open source web-html framework which will be a good thing in terms of flexibility.

The back end server will be http/1.1 to start, but as we’re dropping cgi support, we are suggesting that for public access deployments that it be behind a reverse proxy or load balancer anyway which could certainly be http/2.0.

this wait for the version 2.0 becomes heavy in terms of competition, the delay makes us see other development alternatives to migrate our current developments, I do not want and I can not throw in the bin products that I have developed in Xojo for more than 8 years , but the great decision is presented to all, how much longer? , and if the new releases will allow us to be competitive, there are many questions and doubts

Once again, I wish Xojo did not do premature announcements.

would be just a stepped transition to web 2.0 / Android / API 2.0 with the constant opinion of the entire forum community, right? I think it would settle the success

Ok that soinds great but http2.0 has alot more it can do which xojo web app are not able to if they are not also http2.0
At least we get a something that’s old bit more functional.
How about HandleURL and persistent connections?

[quote=441918:@Derk Jochems]Ok that soinds great but http2.0 has alot more it can do which xojo web app are not able to if they are not also http2.0
At least we get a something that’s old bit more functional.
How about HandleURL and persistent connections?[/quote]
HandleURL and HandleSpecialURL both use the same server as the rest of the framework, and we’ve already added persistent connections to the server code, so that’ll be there too.

Keep in mind that persistent connections have their own set of issues… the biggest of which is that they are locked into being first in first out. That is… if you were to send three requests and the first one takes a long time, the other two have to wait until the first response is returned. Great for short http requests, no so much for long database queries.

[quote=441927:@Greg O’Lone]HandleURL and HandleSpecialURL both use the same server as the rest of the framework, and we’ve already added persistent connections to the server code, so that’ll be there too.

Keep in mind that persistent connections have their own set of issues… the biggest of which is that they are locked into being first in first out. That is… if you were to send three requests and the first one takes a long time, the other two have to wait until the first response is returned. Great for short http requests, no so much for long database queries.[/quote]

Maybe you have no idea how people want to use it? For example i’d like xojo to implement the complete HTTP/1.1 spec (or atleast allow us to be able to do so) and Allow Us as customers to use that. I’m not really interested in the “website” part for now, but more the HTTP custom/api possibilities.

We’d like to use (in the xojo web app side):

  • Server Sent Events
  • Keep Alive (persistent, as per http1.1 spec using chunked encoding for example)
  • Total control from request handler when to disconnect the client.

I’m NOT talking about the javascript framework or web UI, just the App.HandleURL as it’s currently is but with more power.

As we don’t get http2.0 i’m getting the idea we get the same as before, which is not very usefull for our (and perhaps others) use cases. Having a half baked version of http1.1 use useless as there is much more competition to this available.

If this is the route Xojo goes we know what is about to expect what we can do.

That’s not really practical. Xojo Web doesn’t need the whole spec, so we’re implementing the parts that are required to call our server HTTP/1.1 and to make our framework as efficient as possible.

There’s nothing that prevents you from creating your own HTTP server for your special needs.

[quote=441928:@Derk Jochems]We’d like to use (in the xojo web app side):

  • Server Sent Events
  • Keep Alive (persistent, as per http1.1 spec using chunked encoding for example)
  • Total control from request handler when to disconnect the client.
    I’m NOT talking about the javascript framework or web UI, just the App.HandleURL as it’s currently is but with more power.[/quote]
    Keep-alive aka persistent connections will just work, but we have no plans to expose server sent events or connection control as a developer might inadvertently disconnect a connection that we’re using.

First of all, we never said that HTTP/2.0 would be part of the Web 2.0 package. To do so would require a huge refactoring over what we’ve already done and we were not prepared to delay the product any more for the unproven improvements we would get. If, as you say, there is “much more competition to this available”, and our web framework doesn’t suit your needs, my suggestion is to use what works best for you and your product.

[quote=441954:@Greg O’Lone]That’s not really practical. Xojo Web doesn’t need the whole spec, so we’re implementing the parts that are required to call our server HTTP/1.1 and to make our framework as efficient as possible.
[/quote]

Please don’t take this personally … and I am not speaking specifically about the WE.

I understand why you need to do that given the resource constraints that Xojo has, but it (incomplete implementation of standard technologies and features generally ) is what i find most frustrating about Xojo as a RAD environment…

I use Xojo because I am not, and don’t want to have to become, an expert in this kind of stuff. I pay for Xojo because i don’t want to have to learn all the intricacies of the standards and deal with a lot of low level details … but I do want to be able to use them in ways the should be possible if fully implemented, even if Xojo Inc has not needed the capabilities itself …

I know no product can do everything, but over my 18+ years of using the product that (and bugs) it has felt like that frustration happens too often, and is what has gotten under my skin most, so I can understand his disappointment.

  • karen

If HA proxy is in front of a Xojo web app you get a ton of functionality including ssl offloading and the ability to scale your apps. There is no cost and it is fairly easy to setup and supports http2. Also it frees xojo from having to do a ton of work and in turn brings web 2.0 to us more quickly. What am i missing? Since xojo recommends this anyway, what would be the benefit of having xojo add http/2.0 support to the web framework? The web framework is for building web apps and i suspect that using it for something else is not the best idea.

There’s nothing that prevents you from creating your own HTTP server for your special needs.
[/quote]

While that’s true, it’s harder to maintain different projects. And currently the App.HandleURL does provide “some” functionality but it’s incomplete, we can’t keep a connection alive, we can’t flush “partial” data. It seems to be threaded but unable to “flush” so keeping alive is not possible currently. Therfore the whole http1.1 spec can’t be implemented making it not very practical. Reconnecting for realtime data over http is alot of overhead.

There is no need for Xojo to expose the whole http/1.1 spec. There IS a need for a Xojo user to be able to do so.

[quote=441954:@Greg O’Lone]
First of all, we never said that HTTP/2.0 would be part of the Web 2.0 package. To do so would require a huge refactoring over what we’ve already done and we were not prepared to delay the product any more for the unproven improvements we would get. If, as you say, there is “much more competition to this available”, and our web framework doesn’t suit your needs, my suggestion is to use what works best for you and your product.[/quote]

I didn’t said http/2.0 will be in there but it PROVIDES alot of very usefull features (priority, concurrency etc.) in the spec. So if we’re able to use that, then it would be a big plus as it’s HTTP/1.1 backwards compatible and we won’t be behind the hurdle again.

Look around in the forums, see how many people talk about “API” (REST API’s) and creating them. Having this as a complete possibility in XOJO would get more attention to XOJO itself. As it’s easy to use xojo and create micro-services and such. It’s scalable (especially having a stand-alone webserver) and extendible.

Currently we are stuck with very limited possibilities or “create your own” but then using open-source alternatives is easier and provides more possibilities. We DONT want to go to other tools, we want code-reusability.

It’s not that Xojo isn’t going the way we ask as App.HandleURL came by FB request and it did help alot. Just having “a little more”* to it would mean we can move along with the “tech” currently still in use.

*allowing a developer to start a web app project and implement App.HandleURL and keep the connection open (closing when the event returns or sets a close flag. I don’t think this is too much to ask?

But it is an implicit expectation for a web framework that will be released around 2020, and that will probably be mature a few years later (like all frameworks).

Even commercially, for you, it still makes a lot of sense (marketing an HTTP1.1 web framework in 2020?)… If I were you, I would prefer to delay the project for a few months and release it in http2. Because once the framework is released, it will be much more difficult to change its foundations and you will have so many other things to improve and add.

That being said, if in reality, http2 does not make a huge difference, I understand that it is not a priority for you. But commercially, it seems to be risky. Put yourself in the shoes of new customers who will look for a new web framework and make comparisons.

Translated with DeepL Translate: The world's most accurate translator