Web Edition basic client-side operations

Often times with web apps there will be a bit of interface lag because of the server-side processing and general internet lag. If this lasts more than a second it can seem quite odd to the user.

What the best way to do client-side processing to (for example) disable push buttons and entry fields in a login form when the submit button is pushed? Doing it via the control’s action event obviously doesn’t work because all of that is done server side when the data goes through, so it will sit there enabled until the login credentials have been sent/received.

Is this something to be done using Javascript? Also it says in the Docs that WebTimers are client-side, but I wasn’t sure if that would be able to update controls without first contacting the server.

If your login process takes a long time, you could set the button.enabled = false and then send the login code to a thread for processing. That would allow the response to be sent to the browser immediately.

It’s not that the login process takes long (mine does not take long at all), it’s that if there is lag of any kind it seems awkward because there is no loading indicator or way to change button states client-side. You have no way of knowing you hit the button and that you’re waiting for it to connect to the server to process the next line of code.

Is there any information about client side commands in WE for manipulating the interface so we could indicate that it’s waiting to hear back from the server?

Separately, if all actions go through the server, wouldn’t there be a way to catch that and display a loading indicator client-side if nothing has been received after a second or two?

The client-side javascript is undocumented because it has changed quite often since it’s inception, and as such you shouldn’t be manipulating the DOM directly.

That being said, you might want to file a feature request for this. I could see us having a “Submit Button” with an AutoDisable property if enough users thought it would be useful

Thanks Greg. Created a request here: <https://xojo.com/issue/31768>

Hi Tom,

While XOJO makes it easy to write the code for a web app, you can’t write a web app like a client server application, the underlying technology is different and you have to take that into account.

The thing to keep in mind is that in it’s simplest form HTML is a connection less protocol and that all conversations are initiated by the client (browser). Yes there are technologies for getting round that, but the more you add on top, the more requirement you add for users that want to use your application.

Another think to keep in mind is that when you are doing client server, the database server already has the multiuser part covered and you are doing the client coding. In a web app, you have to take into account that you are doing the server coding and you have to design for responsiveness.

If I have a process that is going to take more than about 15 seconds to run, then my approach is to do the following:

  • Have a task server running in the background that is do the actual work (multi user capable of course)
  • When the user submits the request, do as little work as possible needed to validate the user and data, then assign the task to the task server
  • Immediately respond to the user indicating that his task is being worked on and add header meta tag, telling the browser to do an auto refresh every say 2 seconds or two
  • When the browser executes the refresh, I check the task status, perhaps update the status information and return the refreshed page if the task is not ready
  • When the task is complete and I get the auto refresh request, do a redirect to the page that handles the competed task, what ever that might be.
  • If I fail to get a ping back from the client within a certain period, then the task server cancels the task (I assume the client has gone away)

That way the user gets to see something is happening and the web server can continue servicing as many requests as possible while waiting for the task to compete.

Disclaimer: I have done this with other languages, but not XOJO yet…

Hi James,

Thanks for the info. I think you may be misunderstanding the original point and what I was saying. By “client side” I meant the computer with the open webpage of the web app, where the “server” is your server hosting the actual web app that does the processing.

The problem isn’t that the server will be busy doing processor intensive tasks, the problem is when there is lag sending an action to the server (which often happens) and getting any response.

It is my understanding that, for example, when you press a webbutton the browser sends the pressed action to the server and the server processes any code within the actual action and sends back commands to the client’s browser. The delay in getting back results (again, due to lag, not from processing complicated functions) can sometimes be several seconds and makes many things awkward because there is no indication that the client’s browser is waiting for a response from the server.

Hope this better explains what I was saying! Thanks.

I agree with Tom. Xojo should implement some features to make webapps more responsive. Just tried the sample webapp Eddies Electronics with the Network Link Conditioner and every profile 3G and worse makes the webapp more or less useless with response times of more than 10 seconds :confused:

Hi Natascha.

The technology desired under the Xojo hood would be HTML 5 websockets. If you read other web threads mentionting HTML 5 websockets now you know what’s being asked for :slight_smile:

This is a loose but helpful description of understanding how Xojo web edition currently works :

Let’s say you’re hungry and you want a pizza so you call up Domino’s and you order a pizza.
The Domino’s guy takes your order over the phone and you both hang up.

Time passes and you don’t hear from the Domino’s guy so to find out if your pizza is ready you call Domino’s and ask :

You: <calling Domino’s> (ring… ring… ring!)
Domino’s : Hello?
You: Hi Domino’s is my pizza ready yet?
Domino’s dude: NO.
You: Bye then ( hang up ).
Time passes…
You don’t hear from Mr. Domino’s about your pizza and you’re wondering if it’s ready now so you call again.

You: (calling Domino’s again) Hi, is my pizza ready ?
Dominos: Nope.
click :frowning:
More time passes…

You: Jesus man I’m starving! My pizza better be ready now!?! (dialing Domino’s)
You: Is MY PIZZA READY NOW?!
Domnios: Nope. Not yet.
You: Pffft! Whateverz! (hang up). LAME!

Again more time passes…. STILL no information from Domino’s.
You: This is crazy! I’m starving and this dude doesn’t even tell when my pizza is ready and I gotta keep calling him over and over otherwise I’ll never know when my pizza is ready!

You: (ring ring fricken’ ring!) IS MY PIZZA READY NOW!!?!
Domino’s :Your pizza? NO! Not ready yet and I’m SO busy answering all of these stupid phones for people asking me if their pizza is ready it’s slowing my pizza making down and annoying the crap out of me!
You: Ugh! (hang up). Grrrr.

Even MORE time passes, surely your fricken pizza is ready now!
So you call again and sadly, it’s not. Boo hoo hoo, you cry but the only thing you can do is to keep calling and asking if your pizza is ready until it’s actually ready :frowning:

This ridiculous repetitive retardation of a protocol -constantly having to call Domino’s over and over to see if your pizza is ready is called polling. It’s what http clients in this case web browsers [in our example, you] used to have to do to the server (Mr. Domino’s) to find out if any new information was available for you from the server. It’s outdated technology and was a lame idea for the web wizards to implement. There’s a newer process called long polling which cuts down on the number of calls (polls) you have to make compared to polling but it’s still lame because it has a lot of overhead which isn’t good. Xojo’s web edition probably uses long polling. The more recent and finally smart solution the supposed web Gods came up with is called websockets. Coincidentally anyone that’s programmed with TCPsockets already knows this technique of keeping the connection alive, it’s pretty stanard stuff duh. Don’t know why it took the www web tards so long to figure it out? Probably because the scientific nerds who created the net didn’t visualize it to become what it is today. It was just static text based boring blah blah blah. Yes they very limited in their vision. Just like those Government employees that never correctly design freeways to properly accommodate population growth. Or the other fools we call Government that can’t figure out that Nuclear power is far too dangerous for simpleton humans to be playing with. Those idiots still haven’t stopped the Fukushima meltdown.What has it been? 3 years of melting down? Morons.

Back on topic :
With HTML 5’s websockets you simply contact the server once and it keeps you on the line (the connection stays connected) and the server gives you the information as soon as it’s ready. You do not have to constantly harass the server over and over wasting it’s resources and using more bandwidth slowing everything down.

The HTML 5 websocket version of ordering a Domino’s pizza :

You : Gee I’m hungry. I’ll call Domino’s and order a pizza (ring ring ring). Hi I’d like a yummy pizza please.

Domino’s : Oh? You want a large thick crust yummy pizza with extra cheese and a beer? OK. Got your order. I’m working on it. Stay on the phone and I’ll deliver your pizza to you the instant it’s done. Yay!

Of course the ‘pizza’ here are packets of data and the point is, there is no constant wasteful polling. Your data is delivered when it’s ready.

The end.

Using HTML 5’s websockets is much faster and far more efficient than polling, even long polling which I suspect Xojo is using.

If you search the web section of the forum you should see people asking for websockets. I don’t think many web developers will take Xojo’s web edition very seriously without them.

Xojo had tried to correctly implement websockets previousy but they goofed it and pulled them. I’m sure they’re aware they need to correctly implement websockets for most web developers to take Xojo web edition seriously. That means you can count on it coming in the future Marty!

Of course these guys are so busy who knows when it will happen but I’m hoping they take this very seriously and get it to us within a couple of months :slight_smile:

[quote=59944:@Tom Iwaniec]
It is my understanding that, for example, when you press a webbutton the browser sends the pressed action to the server and the server processes any code within the actual action and sends back commands to the client’s browser. The delay in getting back results (again, due to lag, not from processing complicated functions) can sometimes be several seconds and makes many things awkward because there is no indication that the client’s browser is waiting for a response from the server.[/quote]

Tom I fully understand what you are saying, the exact same issue has been around in similar technologies such as ASP.NET forms for a long time. And it is a limitation of the underlying model rather than the XOJO implementation. Yes there are some tweaks the can do here and there to improve it, but there is a limit to what can be achieved.

I think it is important to keep in mind what this model has allow us to do - without much knowledge of the underlying techniques of web development, developers are able to provide line of business applications to their employees which perform reasonably well over the intranet at a cost more or less akin to desktop applications.

Now to get the kind of responsiveness you wish for today, requires a willingness to get involved in HTML5, CSS3, javescript and so on, regardless of the development environment you choose and that costs money! Now I expect that for in-house applications most businesses are willing to live with the few seconds time delay rather than caught up the extra money required to achieve it.

Today you could use the XOJO server to implement such an application too. Simply render up a standard HTML page to the browser with a lot of javascript libs that makes JSON calls to the XOJO server for its data and so on. But of course you would have to dip into the HTML/CSS/Javascript world, just like everyone else is doing.

Right now I see XOJO as a very good way to deliver cost effective web applications in the enterprise, but if I was going to do an internet app, I would do a SPA, possibly call an XOJO web service in the background.

While WebSockets will improve things a bit, it’s not a fix all solution for the latency issue. First of all, remember that WebSockets only work for Standalone apps. Without writing a plugin for the Web Server (Apache or otherwise), there’s no way to make a persistent connection to the app, and it would require an overhaul of how we handle incoming connections for non-standalone apps.

FYI - What WebSockets does get you is a savings of packet overhead, but there’s still the matter of encoding/decoding the WebSocket header block, which will still take a little time. Basically, the browser needs to negotiate only one connection (unless there’s a disconnection of course), and from then on, there’s no duplicated header info, just raw data streaming back and forth (like a TCPSocket).

Anyway, users that are farther away from your server will always have a slower experience than the ones that are closer and there’s not much we can do about that besides moving more logic to run directly on the browser without the requirement of a round-trip to the server. There’s a limit to that if you want to be able to write that logic in Xojo code. The 3G example above is a good reason to tailor special versions of your apps for mobile devices (although I don’t think I’ve ever seen a 10 second latency in the real world unless I was in an place with a really bad connection), and if you talk to any developers who have been successful at this, they’ll tell you that it requires a bit of a mind shift.

The next best solution for this will be geographically distributed load balancing, where you basically host a version of the app closer to the users, and keep them all in sync through a database or other means.

It could be so easy if javascript was Xojo but it’s not.

What i think is the best option here would be to have an Event or property to all common web controls (UI browser stuff)
wich accepts javascript code. Of course syntax highlight would be awsome…:wink:

With this you could improve the actions on the client side.
The problem with WEB EDITION is that it does EVERYTHING trough the server… Wich is basicly slowing down everything. And you get visitiors that never return.

[quote=60035:@Derk Jochems]What i think is the best option here would be to have an Event or property to all common web controls (UI browser stuff)
wich accepts javascript code. Of course syntax highlight would be awsome…:wink:

[/quote]

While a big job, maybe for such methods there could be a Xojo to javascript translator under the hood? I assume it’s mostly libraries used now.

One could define what was legal to do in such client side Events and provide “context” properties and methods that could be manipulated in the code to link into the library routines downloaded.

If possible, something like that might give a big boost to WE performance in some cases while still coding in the Xojo language.

The websockets are not a panacea, but they are still eagerly awaited. Socket IO makes things much easier, it is a popular library, it is even compatible with iE 5.5! Xojo could rely on.

[quote=60036:@Karen Atkocius]While a big job, maybe for such methods there could be a Xojo to javascript translator under the hood? I assume it’s mostly libraries used now.

One could define what was legal to do in such client side Events and provide “context” properties and methods that could be manipulated in the code to link into the library routines downloaded.

If possible, something like that might give a big boost to WE performance in some cases while still coding in the Xojo language.[/quote]

Not really a big job, i’m more thinking keep it simple. There is something called WebControlSDK. You can do alot with it, but it’s not perfect for this.

Re-creating controls that are already implemented is not allowed i think. But it would be great if each control can add javascript that is send to the browser wich gets executed if for example a button was pressed or a slider has moved…

[quote=60057:@Derk Jochems]Re-creating controls that are already implemented is not allowed i think. But it would be great if each control can add javascript that is send to the browser wich gets executed if for example a button was pressed or a slider has moved…

[/quote]

A major objective of the WE is (was?) not to need to know javascript and still be able to write good responsive web apps.
As I know Xojo reasonably well, not having to learn the alphabet soup of Web technologies is what I find attractive about the WE… particularly as I don’t know them :wink:

All that is why I suggested client side events written in Xojo but translated behind the scenes to Javascript and sent to the browser, if possible.

[quote=60062:@Karen Atkocius]
All that is why I suggested client side events written in Xojo but translated behind the scenes to Javascript and sent to the browser, if possible.[/quote]

Yes there have been several attempts to do this, the most recent is Google’s Dart, but it still has a long way to go before it gets to something like what you are suggesting.

We’ve looked into this, but the problem is that you’d basically have to code in a sandbox environment.

Imagine for a moment that you added code to a button that calls SQLExecute. What are we supposed to do with that? The database code is on the server, and any calls to that code would now have the latency delays, and have to be asynchronous. Oh, and there wouldn’t be a way to use the xojo debugger if everything was translated to javascript, so if there was a problem, you wouldn’t be able to step through your code to find it.

The thing that Tom was asking for in the first place (the ability to disable a button immediately when it is clicked) is fairly minor in comparison to compiling code into JavaScript.

Come to think of it… Think about WebCanvas. That control is an excellent example of the things that we can do to cut down on the latency issues. We completely duplicated the basic Graphics class into WebGraphics. When the code in the paint event runs, we actually generate the javascript commands necessary to do the drawing on the client side, and thankfully, it’s almost 1 to 1. When we looked at the prototype though, as soon as you got more than 50 or so lines of code, the delays were considerable because if any changes were made at all, we had to send the whole script to the browser again.

The solution in this case was to use Diff. Now, we serialize the changes and only send the differences (unless they get out of sync, in which case we have to start over from scratch). If you had a long Paint event and the only thing that changes is to change a circle from Blue to Red, that’s the only line that gets sent to the browser to replace that one line in the script, and it gets there in a fraction of the time.

My point is that there are things that we can do for each control to make them work better over the long distances involved, but there’s no magic bullet to make a browser on the other side of the planet suddenly behave like it is on your local network. For what it’s worth, traditional web developers deal with these issues every day. We’re trying to soften the blow as much as we can, so if you have ideas of things that you’d like to see, please keep those feature requests coming.

[quote=60062:@Karen Atkocius]A major objective of the WE is (was?) not to need to know javascript and still be able to write good responsive web apps.
As I know Xojo reasonably well, not having to learn the alphabet soup of Web technologies is what I find attractive about the WE… particularly as I don’t know them :wink:

All that is why I suggested client side events written in Xojo but translated behind the scenes to Javascript and sent to the browser, if possible.[/quote]

It’s a good suggestion. But what i wanted to say is it could be done, that’s all.
Welll you can ask Xojo if they would create a Xojo-Lang to Javascript converter but that would be A HUGE job.
I would be REALLY awsome if there was a Code Snippet database on Xojo server or so wich could be found from the IDE. Where one would select an snippet (javascript or Xojo) wich will be added to a control.

Let’s say the snippet name was (for buttons only in Web Edtion): “Hide button locally” and the code was:

Xojo.get(me.ControlID).hide();

(The ide needs to know if a snippet is to be shown for the Project type that’s currently open, so it shows only Web Snippets for Web Edition projects).

now That’s the only thing that has to be done it could be accessible to everyone.
If snippets where to be edited by a moderator (wich knows javascript very well) to extend Web Edition to true WEB power. This would be a major advance in my opinion.

I’d be happy to build it, but since i have no access to te IDE source xd…

(ofcource the community should be able to suggest snippets).

  • It would be good to know if this is even possible to be a Feature Request (xojo staff) ?