Future of web framework

I feel a bit weird with Xojo…
Of course, the new IDE is great and it’s a big step for all of us.
But I’m very frustrated with web framework !
I use RS Web Edition since the beginning and invested a lot of work on it.
Actually, it’s still not useable for a real web project because of performance issues due to the huge traffic between the web client and the Xojo server.
I really feel like nothing is “really” happening on this side of Xojo and I feel anxious about the framework web roadmap.
I’m not sure that this must be posted on this forum but I don’t know how to get reals answers.

That statement goes a bit too far :slight_smile: We had one area in particular with a lot of traffic going back and forth, but we made a custom control for that so we would handle much of it client side. It’s certainly a “real” web project. So it isn’t an impossible issue to solve as long as you’re careful about the design…

If you aren’t deploying stand-alone yet, that’s another easy performance boost. WebSockets will take a significant traffic load off the system, when that’s ready. Fixes to the web framework have been occurring at a furious pace the past year, although not focussed on the traffic issue.

What specifically are you trying to do that is resulting in so much traffic? As with all optimization problems. getting things working first, then looking at how to optimize use of a particular resource tends to be the most economical approach. Sometimes what looks like a network bandwidth issue with a web app turns out to be a server process CPU/memory bandwidth issue.

For example, each time you change a picture on a object, the corresponding PictureChange event is sent to the server even if you didn’t put code on the event in Xojo.
This is true for many event and generating a important traffic.
I’m talking about a web application with a lot of concurrent users (1000 to 10 000 +)
On the old RS forum, I’ve read that RS/Xojo had plans for re-engineering the framework to make it more efficient and that doesn’t appear to be in the short time plans…

[quote=17556:@ValryTarondeau]For example, each time you change a picture on a object, the corresponding PictureChange event is sent to the server even if you didn’t put code on the event in Xojo.
This is true for many event and generating a important traffic.
I’m talking about a web application with a lot of concurrent users (1000 to 10 000 +)
On the old RS forum, I’ve read that RS/Xojo had plans for re-engineering the framework to make it more efficient and that doesn’t appear to be in the short time plans…[/quote]

I’m not sure if this is suppose to happen. And i don’t think those events should fire.
Perhaps you have comments in those events? I suggest remove the event if you have them, as with the WebSDK you use functions like
http://documentation.xojo.com/index.php/WebControlWrapper.EventIsImplemented
to see if the event is there or not, if not then it won’t fire…

I’m pretty sure Xojo has put this use in any control.

[quote=17556:@ValryTarondeau]For example, each time you change a picture on a object, the corresponding PictureChange event is sent to the server even if you didn’t put code on the event in Xojo.
[/quote]

A few things… Yeah, that’s easily verifiable in the Chrome debugger. Most of the overhead of that particular one would go away with WebSockets. You could use the new WebControl SDK to write a smarter WebImageView replacement. I’ll probably do this soon and add to Web Essentials because I want an easy way to support HiDPI images.

Greg’s still getting the plumbing right on this stuff. Not an easy task. Wonderful controls don’t solve much if the foundation isn’t solid. Right now, I’d be patient with their progress and learn to roll your own controls as needed with the SDK. The direction they’re going is a very good one.

-Brad

@Derk Jochems I’m sure there no code in these events
@Brad Hutchings OK I’ll invest WebControl SDK further on

I never could make Web Sockets work. I’ve seen it in framework.js like a impossibility.

@ValryTarondeau - I just did a search in Feedback and I cannot find a bug report about the PictureChanged event. We are certainly happy to fix things like this if someone brings them to our attention. :slight_smile:

I know multiple people who are successfully using WE for public facing web apps. Might I suggest that you are running into some other performance issue? Can you provide us with more information about your web app and where you are running into performance issues?

WE is 100% AJAX and any such web app, regardless of server side language, is going to have minimum latency and bandwidth requirements because it’s going to generate a lot of AJAX calls. In my experience WE is usable by anyone with a DSL connection or higher with the caveat that server geographical location might introduce too much latency. That’s something you would want to test and consider for a global client base.

If you really have 1,000 to 10,000+ concurrent users, it’s time to load balance. I would say the same thing for PHP and .NET, and possibly even for a site serving static pages. You can load balance multiple instances of a WE app on multiple servers using nginx as a front end.

WebImageViewTD does not send its change/refresh events unless you want them. You can also control JPEG compression which may help if you’re serving photographs. That said, I think the fundamental issue is number of users and the need for load balancing.

Websockets are allways disabled in framework.js (line 155) :

if(false && !!window.WebSocket && Xojo.mode == 1) {

I can’t believe anybody could make it work… Am I wrong ?

[quote=17668:@ValryTarondeau]Websockets are allways disabled in framework.js (line 155) :

if(false && !!window.WebSocket && Xojo.mode == 1) {

I can’t believe anybody could make it work… Am I wrong ?[/quote]
Still not fixed?? :frowning:

No, even in R2 beta 2

Is there a feedback case on it?

I don’t know… but it looks more like a “future feature” than a bug.
Thats why I’m asking for this in this post…

[quote=17674:@ValryTarondeau]I don’t know… but it looks more like a “future feature” than a bug.
Thats why I’m asking for this in this post…[/quote]
Please create one and I’ll hook up to it.
Xojo isn’t looking so close here for bug/feature reports :wink:

I’ve just created the case in Feedback :

It’s got my 60 points :wink:

voting!
But I believe (I’m not sure) that Greg had said WebSocket needed a very stable internet connection. So it’s annoying for mobile and tablets. :frowning:

[quote=17681:@olivier vidal]voting!
But I believe (I’m not sure) that Greg had said WebSocket needed a very stable internet connection. So it’s annoying for mobile and tablets. :-([/quote]
If that’s the case it could be disabled for such devices, I guess :slight_smile: