Web Edition Learning Curve

I had a conversation with another RB developer this morning that stuck in my head after I said it.  We were talking about how Web Edition has come a long way since it first came out.  I did a commercial project using one of the first public releases and it was, how shall I say, really rough around the edges.

Anyway, my comment was that at times I felt as if coming from the Real Studio desktop side really hindered my learning of Web Edition.  There are just some things you do in Real Studio desktop apps, like using Window constructors, that are just not possible with Web Edition.  Sometimes closing a WebPage immediately after showing another one isn’t a great idea whereas on the desktop side you don’t even have to think about it.

It takes a while to wrap your mind around the difference between a desktop app and a web app.  The desktop is easy.  It executes locally and gets data locally (there are exceptions of course) but it’s all really quick and it’s designed to interact with the local operating system.  When you want to delve even further into the OS you could always use Declares.

That isn’t how Web Edition works.  When you first start using Web Edition you think it’s on the local machine (it is) so you get this false sense of security about how fast it is.  It’s not until you put it on your web server, which might be half way across the planet, that you realize that there are latency issues to deal with and that changes to the UI get pushed down to your browser.

It only looks like your app is running on your local machine.  In fact every event (that’s used) gets sent to the web server for your app to process.  So this means that if you implemented the MouseMove event every time your mouse moves a message gets sent to the server for processing.  It is very easy to get too many things in the pipeline for your app to respond correctly.  As a good friend of my once said, “You can only piss so much pixie dust down a straw” meaning that the data pipeline (the internet) is only so fast at moving data and it will pass it as fast as it can and no faster than that.  Quite philosophical, no?

The fact that your ‘windows’ are really running in the browser is also hard to wrap your mind around if you’re coming from the desktop side.  And frankly when you’re debugging your Web Edition app you really should be running it in multiple browsers just to make sure it acts the same in each one.  Not all browsers are created equal.  And, just to make life a little harder, test them in different operating systems.  It’s really not much different, at that point, with desktop development.

If you are planning on using Web Edition and you’ve been using Real Studio desktop plan on some extra time.  It’s not THAT much different, but where it IS different will throw you for a loop.  There is a learning curve but with a little patience you’ll overcome it.

Then there are differences in web servers.  Which Linux version?  Do you have 32 bit compatibility libraries installed?  What version of Windows IIS Server or Apache?  Debugging installation issues is, in my opinion, a huge problem since there there is no “step 1 – try this, step 2 – look at this” sort of solution and it seems that every server is just a bit different.

What parts of Web Edition have you struggled to figure out in comparison to desktop apps?

4 thoughts on “Web Edition Learning Curve

  1. I had a look recently (last week actually) at web edition in connection with a small project I hoped to write.
    It looks great but big issues for me were (a) the documentation wasn’t great and (b) the apparent difficulties with deployment. There’s a ‘read this first’ section on the forum to do with deployment and it’s not been updated in ages despite the fact that people seem to have been having major difficulties long past then. Plus I haven’t a clue about virtual private servers, linux, apache blah blah.
    It all looked great on my local machine but as you say, once this is executing on a server somewhere the performance might be awful. So I wanted to be able to write a bare bones piece of code and test it on a server pretty asap.
    So really it was the fact that I didn’t want to be tearing my hair out trying to get this to work on a website that put me off and made look elsewhere.
    So despite not being .net proficient I thought I’d try asp.net express. I also got hold of sams asp.net in 24 hours, which made all the difference.

    Within 2 days (one of which was taken up mainly by the asp.net express installation which took forever but was thankfully required minimal work on my part), going from scratch I had a small application developed and deployed to a website.
    Deployment was simple, pretty much a case of copying and pasting, including an access database which the app uses.
    Whatever people say there is a lot of choice among windows hosting providers and the prices are comparable to linux hosting.
    The first 2 weeks windows hosting is free, the only cost was about $12 for my domain registration. Ongoing hosting costs are about $10 a month, shared hosting.
    Now I can open my hosted app from asp.net express on my local machine edit the code and have instant changes to the website.
    My hosting is the most basic package allowing just one domain and 1 sql server database (and unlimited access databases).
    I think RS made a major screw up not getting 1-click deployment in place from day 1.
    Even now it’s going to take about another 6 months.

  2. I have to add that Paul (and others) from Real Software already improved the docs on deployment. Still we had lots of trouble. Especially if IIS version is not the same as in documentation and settings dialogs look different.

  3. @jjb
    I agree that it’s a shame that the 1-click deployment didn’t happen sooner. However, the Web framework needed to get fixed to make it usable, first, before anything else could happen. We are only now at the point where mere mortals can use it!

    Deployment is one of the major issues in Web Edition. The level of reporting available for most people doesn’t make it very intuitive nor obvious on what to do next if there’s an error.

    The browser will give a very generic error message but the error logs generated by the server (and hopefully you have access to them) may give a completely different error that *still* might not be very intuitive.

    We’ve installed apps on 4 difference servers (for ourselves or clients) and I swear that each one is just a little bit different. It’s enough to pull my hair out (if I had any left)!

Comments are closed.