Tuesday, August 31, 2010

Web 3.0

When my dad first started programming, he programmed in binary by flipping 8 switches on the front of a computer then pressing a button to enter that single byte. He was quite literally flipping bits. This was considered first generation programming. Then assembler came along which was a lot easier than binary machine code. This was second generation programming. Finally, someone realized that for real productivity, languages needed to be English-like (since almost all programming at that time was happening in English-speaking countries). Languages like BASIC, Pascal and C appeared. This made programming far easier and more accessible because it was not only English-like but programs were finally abstracted from the details of the computer processor itself.

When the web came along we first had HTML, JavaScript and PHP. What you could do with these languages was so primitive, they weren't even called web applications. You could create forms and when a submit button was pressed, all the data was sent to the server where a program written in an entirely different language would process the results, recreate the page (or a new page) and send the entire thing back to the browser. This was web 1.0. AJAX brought an incremental improvement to this process where pages could be updated rather than replaced. Web applications became more responsive. This was called Web 2.0.

But web 2.0 applications are just a mishmash of files and languages. Because there are so many technologies, learning all of them is difficult and building applications with them is time-consuming and expensive. A web developer told me yesterday that it's very difficult for them to find developers. Candidates might know two of these five languages/technologies needed but rarely do they know all five (HTML, CSS, JavaScript, PHP or Java and AJAX).

Web 3.0 is supposed to bring real applications to the web. REAL Studio Web Edition provides a level of abstraction that allows developers to build apps quickly and easily, concentrating their efforts on what makes their applications unique. REAL Studio Web Edition really is web 3.0. It is finally here.

You can learn more about our new web platform here.

19 comments:

Jordan said...

Well, not "here" yet. Fall 2010 can mean sometime in November. Curious to see how it performs - even more curious to see if there are any nominal limitations preventing standard/commercial use.

Geoff Perlman said...

Hi Jordan. What sort of nominal limitations are you concerned about?

Nonchai said...

Out of curiosity, what would you consider to be the advantages/plusses of your “one-stop shop” web IDe when compared to other such products out there at the moment? Is it the speed thing ?

And do you intend to support things like the HTML5 Canvas in the future ?

Nonchai said...

What i’m really asking I suppose is whether youll be supporting the REALbasic Canvas in a future version - and if so will this be done via the HTML canvas ?.

Or maybe do you consider it more sensible to have a seperate RB control specifically for the HTML5 canvas API ?

regards,

Dan Stenning

Geoff Perlman said...

Our web framework has an ImageView control that is very similar to but not exactly the same as the Canvas control in a desktop REAL Studio app.

We specifically named this control differently because we know that at some point we will want to support the HTML5 canvas control and we don't want people thinking that our current control is that.

Anonymous said...

This is fantastic news and really opens up the platforms we can target, especially the mobile ones! Thanks and best of luck with your ongoing development effort!

That said, please continue the LLVM effort so we can have faster and smaller apps on all platforms.

Kundalini said...

Geoff and team,

This is a dream product, and I can't imagine a better outfit to have conceived it and brought it to market.

Congratulations on an exciting milestone.

Christopher

MGV said...

Will it handle requests from mobile platforms (eg iPhone) and present a different user interface to them?

MGV said...

Will it handle requests from mobile platforms (eg iPhone) and present a different user interface to them?

Geoff Perlman said...

@ MGV - It will handle requests from Safari Mobile (Safari on iOS). Using some properties in the Session class you can determine that the user is on Safari Mobile and then show them a different set of pages or change your pages via code if you wish. The initial release will not have iOS-specific controls.

Karig said...

Heh. This is one way to get around Apple's restrictions on what can be run on iPhone and what can't. You wouldn't even need to submit your application to Apple for approval before you're allowed to disseminate it to iPhone users (unless Apple is going to respond to this by blocking unapproved websites when they start doing the same things as iPhone apps).

Geoff Perlman said...

Anonymous, you are making a HUGE assumption that all engineers have the same set of skills and thus can do the exact same work. The new web platform layer has not significantly impacted development elsewhere in our code base.

Yes, 64 bit is important and we will be working on that soon but to suggest that bring REAL Studio to the web is pointless garbage....

Anonymous said...

Cocoa is obviously no concern to those who don't primarily target the Mac.. But for those that do it's VERY important.

Also as I understand it (and may be wrong) to really support 64 bit on the Mac, you need to be using Cocoa because Apple will not transition Carbon to 64 bit.

Also is suspect the compiler change REAL is working on is part of the 64 bit transition too and goes across platforms.

But I have to say I think very few apps truly NEED 64 bit for the next few years at least...

You may not beed web apps and I may not use them, but that is a huge area these days. To be able to use one tool for that is big deal, and for EB coders to be able to leverage what they know isa HUGE deal.

If it works and no too buggy I see this as becoming VERY popular for in-house developers at small to medium size companies.

If RS makes more money they can (and hopefully will) put more resources into the desktop product from which we can all benefit.

If the decline because of the popularity of web apps that won't happen...

Geoff Perlman said...

There was someone posting anonymously and being very disrespectful. I deleted their comments and will delete them again if they continue to write things I'm sure they would never say in person.

nano-cluster said...

Imagine a POS app that needs to print some report (the data is on the server side postgresql server) using the native printer driver on the client side, and sometimes needs to comunicate with some sort of serial/usb/ethernet devices like ETF-POS and printers devices ( http://en.wikipedia.org/wiki/Credit_card or http://en.wikipedia.org/wiki/Debit_card ). Maybe we can make an APP with RB desktop, but would the web edition?

Geoff Perlman said...

You could write a small console app that could be downloadable through your POS web app. The console app would communicate via TCP with the web app and would handle the any client side communications with printers, the serial port, etc. It's not a perfect solution, but without a browser plug-in (which would be an even bigger headache), no web app can talk directly to the user's system. But if you are talking about the part of a POS system that will be used by an employee (rather than the customer side), I think a console helper app that is installed client side is totally reasonable.

keatk said...
This comment has been removed by the author.
nano-cluster said...

What about a desktop app that is really a big container of a RB browser component? This app can talk to the client machine environment and the "inside" app is running on the server side. The good thing is that we just need to maintain the server side and everybody has the 'latest" app version (new menus, fields, reports, etc). But... The "internal" (HTML component) part must have some way of exchanging data with de "external" (the main desktop app) part. So the internal can send commands, parameters and data to the external part to process and vice-versa.

Another question: Memory footprint and disk access slowdown. A webserver needs to keep a good use of resources and maintain cached content and routines in memory to avoid multiple disk requests and slowdown the machine and solve multiple web requests ASAP. CGI is the worst way of doing it. Thousands of loads and unloads per second kills the machine. This was addressed in the new RB design?

Thom McGrath said...

nano, yes to both questions. We use FastCGI, so the app stays running and objects remain in memory. No disk access is required. Unless, of course, you use FolderItem do access the disk.