Xojo Web Framework 2.0

Will the Web Framework 2.0 be focussed the same as it’s now in it’s “always” online mode or will there be an offline capable part (as in PWA) ?
Currently the most annoying thing is simply “this application has gone offline”, that screen can’t even be modified by a custom offline-capable page. It would be a great Web 2.0 if it where offline capable so it can resume offline tasks.
Then there is the “why is it always connected” ? it’s not like 9/10 times a web application should or wan’ts to be always connected. The server “load” should be lowered somewhat since Xojo is already single core, it would make it more robust.

Also why is Xojo not focussing on HTTP/2.0 it has HTTP/1.1 fallback and improves connection speed. It would also add 10 years of usability to the New Web 2.0 instead of it being deprecated (http/1.1 is used less and less) at the moment of release.

Chomping at the bit for it…

A common concern in this thread is a fear that Web 2 is already behind the latest technologies. That would be true. But, a more urgent concern is that Web 2 needs to be released. Fortunately, it appears that Greg has done some forward thinking. [quote]With regards to layouts, we’ve designed the new framework to support multiple layout types with the possibility of adding new ones in the future.[/quote]

As you know, when we started the new web framework, Bootstrap 4 was in early betas. Additionally some of the controls we are using to flesh out the control list require BS3. That’s not to say that we’ll stay on v3 forever.

Now I understand that you want responsive layouts. We’ve talked about this internally from time to time and we want to do it… but only if we can do it right. The main thing is that to get there, we need to have a way to record more than one layout for a single page… and it turns out that we also need that for autolayout. So while we aren’t going there first, we are going in the direction we need to if we want any chance of getting to responsive layouts in the future.

The #1 blocking issue here is debugging. It’s fine to be able to compile your code to JavaScript, but we would also have to build a debugger so you could set breakpoints and step through code… on top of that we’d need to make sure the webassembly runs code exactly the same way it does when built for other targets, and that could be a huge task… like adding a whole new target.

As we stated last year, the only option will be to convert projects to the new framework. So yes, you will need to use an older IDE for old web projects.

Oh that’s a good point I hadn’t considered…

This hasn’t changed.

The new framework has an all new connection manager which monitors the server connection and will show a modal dialog asking the user to wait a moment if the server isn’t responsive. If the connection can’t be re-established, a second modal dialog is shown. Both are customizable.[quote=474262:@Derk Jochems]Then there is the “why is it always connected” ? it’s not like 9/10 times a web application should or wan’ts to be always connected. The server “load” should be lowered somewhat since Xojo is already single core, it would make it more robust.[/quote]
It’s always connected because you write the logic code in Xojo, and that code is on the server. We’ve got some ideas about this for the future, but you’ll have to come to Nashville to learn more about it. :slight_smile:

Like Bootstrap, HTTP/2 wasn’t ratified when we started on this journey… and I saw only yesterday that HTTP/3 is in early draft now.

HTTP/2 is on the list for a future version, but i think you’ll also be very pleased with the reduced traffic and reduced overhead in web framework 2.

Greg, thanks for opening up and answering a bunch of our questions about Web Framework 2.0. I know I haven’t asked anything, but I’ve shared some similar questions and appreciate the answers. I’m really quite glad to get some insight about what’s coming up with the web framework! The future sounds promising :smiley:

Thanks Greg for answering the above topics and was very informative regarding the upcoming Xojo versions. This wasn’t the attitude earlier by Xojo Team. Its very good to see that you have changed it. Now I trust you more.

As a follow up to this comment, I went to find the Bootstrap 4 migration guide (which is inconveniently hidden now IMHO) to verify my recollection about this.

If you search for “Grid System” it says Moved to Flexbox.

Adding a Flexbox layout mode was a calculated move when we did it. It gets us closer to being able to offer a column-based layout type in the future for the users who want that.

Greg ? Will backward compatibility be there ?

It depends what you mean by “backward compatibility”.

You will be able to convert old web projects to the new format… but keep in mind that all of the controls have different dimensions, so your layouts will have to be adjusted.

Also, Web Framework 2 uses API2, including all of the new event names.

Converting projects is a one-way operation.

[quote=474375:@Greg O’Lone]of the controls have different dimensions, so your layouts will have to be adjusted.
Also, Web Framework 2 uses API2, including all of the new event names.[/quote]

This prevents me from starting a new web project now. And that in turn puts some time pressure on getting hands on Web 2.0
Web 2.0 looks really promising but time is not on our side anymore.

Xojo will have different event names for different targets? Open on dessktop, Opening on web?

Really? Didn’t we already go through this exercise to disastrous results?

Would seem this needs to be reconsidered
Otherwise we have one set of event names on desktop and console, a different set for web and who knows about iOS and android ?

What is the long term plan for event names across all targets? Is the plan to go with the API 2 names everywhere? If yes, then what will be done differently with regards to Desktop apps? Agreeing with Bob. It didn’t go well last time it was tried.

What I think should happen is that if an event is essentially the same as for the desktop equivalent, the name should be the same as desktop. If it is different in a significant way, then an API 2ish name would make sense to emphasize that.

  • Karen