Recent

Author Topic: Future of Lazarus / FreePascal  (Read 446698 times)

JD

  • Hero Member
  • *****
  • Posts: 1848
Re: Future of Lazarus / FreePascal
« Reply #105 on: July 12, 2011, 11:49:54 am »
Here is a screenshot of my current application:

http://logicasw.com/varios/ppgt1.png

Looks like web application or desktop application?

I have to commend you on this. It looks very good.
Windows - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe),
Linux Mint - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe)

mORMot; Zeos 8; SQLite, PostgreSQL & MariaDB; VirtualTreeView

ssamayoa

  • Full Member
  • ***
  • Posts: 163
Re: Future of Lazarus / FreePascal
« Reply #106 on: July 12, 2011, 02:46:14 pm »
I have to commend you on this. It looks very good.

Thanks but L&F is the default ExtJS's theme and in this application I just extend one component with little behaviour addition.

Regards.

jl

  • Full Member
  • ***
  • Posts: 178
Re: Future of Lazarus / FreePascal
« Reply #107 on: July 12, 2011, 05:25:31 pm »
I have to commend you on this. It looks very good.

Thanks but L&F is the default ExtJS's theme and in this application I just extend one component with little behaviour addition.

Regards.


Is the back end python?  Is FPC or Delphi involved?

ssamayoa

  • Full Member
  • ***
  • Posts: 163
Re: Future of Lazarus / FreePascal
« Reply #108 on: July 12, 2011, 05:58:36 pm »
Is the back end python?  Is FPC or Delphi involved?

I'm affraid not, is Java (server code using JAX-RS & JPA) + JavaScript (front end using ExtJS).

But you can write your server code in FPC.

ExtJS data components communicates with server using JSON or XML so you can choose whatever language you want.

Regards.

Leledumbo

  • Hero Member
  • *****
  • Posts: 8747
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Future of Lazarus / FreePascal
« Reply #109 on: July 12, 2011, 06:56:41 pm »
Quote
C and C++ are the king there.
Yeah, because it's easy to build crashful apps that you can charge people for upgrades though it's just bugfixes.
Quote
ExtJS data components communicates with server using JSON or XML so you can choose whatever language you want.
I see a lot of ExtJS data bindings in my component palette... wouldn't that make web programming in FPC easier especially for web service communication?

JD

  • Hero Member
  • *****
  • Posts: 1848
Re: Future of Lazarus / FreePascal
« Reply #110 on: July 12, 2011, 07:10:54 pm »
Is the back end python?  Is FPC or Delphi involved?

Following the basic Model-View-Controller paradigm:

Model - this is actually your database model/persistence layer. It can be an RDBMS of your choosing
Controller - this is where the business logic resides. It is the "brain" of the application. You can put your Lazarus/Delphi code here, maybe bundled as a Dll.
View - this is where you can build an desktop based GUI using Lazarus; an ExtJS (JavaScript) or Python (Python Script) web based user interface; or even a view for a PDA device like Google Android. It's up to you.  :D

The three levels could communicate with each other using a standard like XML or JSON.

If you had followed this paradigm from the very beginning of your application design, the only part you would need to change significantly would be the user interface (the "View"). As you might have guessed, using data bound components in the View is not advisable.

I hope this helps.  :D
« Last Edit: July 12, 2011, 07:34:42 pm by JD »
Windows - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe),
Linux Mint - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe)

mORMot; Zeos 8; SQLite, PostgreSQL & MariaDB; VirtualTreeView

jl

  • Full Member
  • ***
  • Posts: 178
Re: Future of Lazarus / FreePascal
« Reply #111 on: July 12, 2011, 07:34:38 pm »
Following the basic Model-View-Controller paradigm:

Model - this is actually your database model. It can be an RDBMS of your choosing
Controller - this is where the business logic resides. You can put your Lazarus/Delphi code here, maybe bundled as a Dll.
View - this is where you can build an desktop based GUI using Lazarus; an ExtJS or Python web based user interface; or even a view for a PDA device like Google Android. It's up to you.  :D

The three levels could communicate with each other using a standard like XML or JSON.

If you had followed this paradigm from the very beginning of your application design, the only part you would need to change significantly would be the user interface (the "View"). As you might have guessed, using data bound components in the View is not advisable.

I hope this helps.  :D


Thanks JD.  By data bound do you mean like scripts that query the database directly.

My current application is basically a service that read/writes from/to an sql db, and which communicates with multiple windows gui 'clients' using sockets in a web service like manner.  The job of the gui client is to render the data from the server, and also submit data back to the server.

JD

  • Hero Member
  • *****
  • Posts: 1848
Re: Future of Lazarus / FreePascal
« Reply #112 on: July 12, 2011, 07:50:07 pm »
Thanks JD.  By data bound do you mean like scripts that query the database directly.

Databound controls are user interface controls that are bound to actual fields in the data layer - the model. An example is everything on the Lazarus "Data Controls" tab in the IDE. They render data faster since they are tightly bound to the data but the application loses flexibility & can be difficult to maintain especially in a multiuser application. Things work best when there is division of labour/separation of functions into layers. The downside is lower speed but the upside is easier maintainence.

It is better to use generic text boxes etc that are filled from the results of communication between the various layers. Such communication could be the results of query scripts formatted in say XML or JSON.

This gives you the flexibility of changing what is in each layer without having to do a complete rewrite of the entire application. You only need to update the layer that needs updating.
« Last Edit: July 12, 2011, 07:58:49 pm by JD »
Windows - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe),
Linux Mint - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe)

mORMot; Zeos 8; SQLite, PostgreSQL & MariaDB; VirtualTreeView

jl

  • Full Member
  • ***
  • Posts: 178
Re: Future of Lazarus / FreePascal
« Reply #113 on: July 12, 2011, 07:57:01 pm »
Databound controls are user interface controls that are bound to actual fields in the data layer - the model. An example is everything on the Lazarus "Data Controls" tab in the IDE. They render data faster since they are tightly bound to the data but the application loses flexibility & can be difficult to maintain especially in a multiuser application. Things work best when there is division of labour/separation of functions into layers. The downside is lower speed but the upside is easier maintainence.

It is better to use generic text boxes etc that are filled from the results of communication between the various layers. Such communication could be the results of query scripts formatted in say XML or JSON.

So I guess i'm not affected since i'm already using a multiple client to one server model.  The clients don't connect to the database directly.

jl

  • Full Member
  • ***
  • Posts: 178
Re: Future of Lazarus / FreePascal
« Reply #114 on: July 12, 2011, 07:59:11 pm »
Quote
C and C++ are the king there.
Yeah, because it's easy to build crashful apps that you can charge people for upgrades though it's just bugfixes.
Quote
ExtJS data components communicates with server using JSON or XML so you can choose whatever language you want.
I see a lot of ExtJS data bindings in my component palette... wouldn't that make web programming in FPC easier especially for web service communication?


I took a look at the ExtJS examples in fpweb or fcl-web (can't remember which), they look a bit intimidating.  ;)

JD

  • Hero Member
  • *****
  • Posts: 1848
Re: Future of Lazarus / FreePascal
« Reply #115 on: July 12, 2011, 08:05:13 pm »
So I guess i'm not affected since i'm already using a multiple client to one server model.  The clients don't connect to the database directly.

That great. Might I suggest this book Microsoft Application Architecture Guide, 2nd Edition
Chapter 5: Layered Application Guidelines http://msdn.microsoft.com/en-us/library/ee658109.aspx
Chapter 18: Communication & Messaging
http://msdn.microsoft.com/en-us/library/ee658118.aspx

I actually found it to be quite helpful in spite of the fact that it comes from Microsoft.  :D
« Last Edit: July 13, 2011, 12:17:37 am by JD »
Windows - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe),
Linux Mint - Lazarus 2.1/FPC 3.2 (built using fpcupdeluxe)

mORMot; Zeos 8; SQLite, PostgreSQL & MariaDB; VirtualTreeView

rik_rs

  • New Member
  • *
  • Posts: 42
    • www.riksoft.it
Re: Future of Lazarus / FreePascal
« Reply #116 on: July 13, 2011, 11:38:45 am »
Quote
Granted. But thats because everybody wants web bases applications and no more locally installed applications so most of the industry is working on that, abandoning desktop applications.
"Everybody wants":THAT'S SIMPLY NOT TRUE!
I face 1 customer every 1000 who prefer a web app instead of a desktop one.
If we are talking of fashion ok... I'm italian... :D but the truth is that only some (AND FEW ONES ) scenarios can benefit from web based applications.

Simply ask to the extreme: what do you prefer, developing on your computer or using an online IDE? Do you prefere Aptana or Titanium? What you prefer a desktop chat client to put on the systray panel or a google chat in the browser?
Obviously if a global shared task manager is needed, surely web app is better.

But the main reason the industry/developers TRY to make everything web based, is for a WRONG paradigm: web app are OS independent and everywhere (or nowhere :D). Yes, right, but are isolated from browsers, components (hundreds that born and die every year), servers, protocols, glue that interconnect a component/framework together, etc.?

Even entering the domain of what is "best" (at least more than system tools :D) suited for web application, that is, business, financial and accounting management software, there are many caveats and problems, not only technical problems, but also legal and from from user point of view.

Some examples:
1) Usual user sentence when he try demo web apps: "It is too slow!!!". ALWAYS! Even using a Cray-X server! That's due to a more complicated verbose protocol. Even in the best case where java is used in the client side instead of JS, the overall software is perceived SLOW compared with a native/dedicated client.

Real case
Do you know Zurich Insurance? They had a DOS based software till last year, on novell LAN, called OASI. They have only recently changed to a web based equivalent software.
RESULT:EVERY USER feel this new application a down grade! :D Everyone feel it bad because of the low responsiveness compared to the previous super quick software. Obviuosly it's not a matter of money because Zurich... you know..., nor config: dedicated lines, backup lines, etc. The problem is that there is nothing to do for phisics reasons. As the best truck of the world can't compete with a Ferrari or a Lamborghini Gallardo so a web app cant compete with a desktop one.
Responsiveness and other features are the reasons you can find desktop clients even for twitter, facebook, and other web app etc.

What developers have to understand is that end users are not developers. They don't rejoice only because we have an easy life making "write once execute everywhere" web app. When a user see a click response after 1s he think: "WHAT A SLUGGISHNESS!!!! What's wrong? (click click click click click click)".

End users are not like us. If a user wants a car and you give him a truck, is not more happy reasoning that it is tecnologically better, can carry more stuff, has more value in the industry, and so is OK that is slower. :)

2)
I both develop RIA and Desktop applications. Small/medium companies that call us to buy a software, after 2 seconds ask: "Isn't a web software, right?" (That means: if it is a web app I'm not interested at all).

Why? Simple:
a) They want data on their LAN, not in fantasiland or distributed all over the clouds of the world even if we are proud to hilight "cloud server" or GlassFish in the brochure! :D

b) They want to work even when DSL is down, and are not interested if the app is slow because of the line.
They also want to work if notebook don't have a line (for many could seem strange but in many nations trains, bus and ferry boats are places that rarely or often NEVER have a hot spot).

c) They would like to work from a pen drive if needed.

d) They know that online software (at least in Italy) is subject to the Guardia di Finanza (italian police whose specific task is to enforce tax evasion laws etc) WITHOUT ANY ASK OR ADVICE.

3)
Initially I was willing to simplify my work making web app for everything. I thought I could gather every user under the same web app simply changing the location of the server:
- installing the app/server on the customer LAN (VMware/VBox) to cope with the clients mandatory will to have a desktop app
- installing on the web for those who need global access and no installation,  working even from a pub client.

... but today I ask myself: what is the real benefit againsts a real dedicated client? It's only because I can't give them pub client access?

So after some years I have the evidence that only some web solutions are really well accepted from the users:
1) Software intended for occasional use, touch and go
2) Software for the big mass (es. communication like facebook, twitter, gmail)... by the way... about google.... try asking people to use Google Apps instead of m$ Word  :D. Have you ever tried a serious documents? Try the speed/responsiveness.
3) Software for huge companies where slowness is less important that everywhere + no maintainance (no manteinance... only idealistic idea! Let's say: Today is: I have all of the problems distributed on the cloud  :D)

and I'm now oriented to:
1) Hybrid apps (web app only for some functions)
2) Portable app (real native executable), that are also useable the way java web start do.
This can cope with almost every need the best way we can (in the user view point).


Developer view
Despite I have no problem developing RIA applications (I have also developed a framework), to me, there is nothing more satisfying than working with native applications, for plenty of reasons. Beyond a certain line, it's even easier because RIA apps is not that panacea. The worst thing for a desktop app is OS changes.... but now browsers war, technologies that appear and disappear, frameworks, GUI components (YUI, etc), servers,  etc, brings more changes and need of mainteinance than a desktop applications using something like lazarus, all in one.

Just an example: In a small web app, i'm using jQuery and some jQ visual components, plus TinyMce + AjaxFileManager. Some days ago I update jQuery: problems! >:(

So there is no better relief developing web apps. Don't counting problems  such as resize images client side before uploading, dialogue with a cash register and other devices, changing the printer if the software has to print an invoce, using another printer if it has to print a chart, or using a Zebra card printer if it has to print a new fidelity card. Let's do it with a web app! ;D How easy is it? :D

Web apps are limited to some targets: out of that targets the only benefit are... problems! :D


Quote
Not sure if you are thinking that Swing itself is dead, but from what I have read, this is referring to an enhancement that was planned for Java 7 to build a framework around Swing to make it easier for developers to build Swing apps.
That's referring to what it says: Netbeans Platform.
About the Swing framework (the best way Netbeans had to compete with VB/Delphi/Lazarus/RealBasic/code:blocks/and the rest of the desktop world), what you see when you choose New Project->Desktop application, IS DEAD!.

Swing probably will last for a long time, but the web is full of question like: "Is Swing dead?" Probably there is a real reason!  ::)
Whatever the case, I don't trust Oracle! Sun was another matter. Oracle is very similar to m$: you can aspect everything, even they shut down Java tomorrow (exaggeration but... not too much :D).

About Netbeans Platform: is something like developing.... how can I say.... just imagine developing under Open Office or Microsoft Access. The developer get tied to Netbeans more than Java. With the previous way, you could choose to migrate the app to Eclipse. With NetBeans Platform is not possibile anymore.

Even though I was not very attracted from Pascal (reason why times ago I used C++ Builder instead of Delphi), Lazarus is so interesting that I changed my mind and I'm seriously studying it (I exhumed from my shelf a tome of Marco Cantu` on Delphi 6  :)).
So thanks to every developer and your great work with this product!


« Last Edit: July 13, 2011, 12:02:13 pm by rik_rs »
Rik.

ssamayoa

  • Full Member
  • ***
  • Posts: 163
Re: Future of Lazarus / FreePascal
« Reply #117 on: July 13, 2011, 06:28:25 pm »
@rik_rs

Wow!

Certainly you was inspired to write so long post!

Again, what drives applications to the web and the cloud is MONEY:

With very little resources you bring applications to a lot of people.

Intead of a big and costly workstation to run some often bad crafted Client/Server application you only need a Browser.

Intead of having hundreds or thousands database connections each one possibly with its own credentials, in web applications you use few to support the same ammount of users.

Intead of an army of help desk and field technicians to support client/server applications you need few.

I remember the first time I replaced a Client/Server application with Web based on LAN (not only for public access you use Web Applications) and despite the "slowness" of the rendering in the browser, people were happy because new application haves a lot more features than previous one. And help desk calls drop almost to 0 because every body knows how to use a browser, no need of client software installation (not only the application itself but the components needed like database client software for example), no update nigthmare, etc.

Almost any application can be crafted or converted to the web despite the technology used to do that. There are some that perform as fast as fat client application (Flex, ExtJS, Silverlight) because, after all, are client/server (have you kown about the binary protocol used by Flex? Have you looked at JSON, not so compact as binary but small enough); others are slow because is Web 1 technology (full page rendering per click) or use Ajax but slow because and large portions of the DOM, etc.

Remeber: The slowest part of the system is ALWAYS the user, so "slowness" is acceptable. But believe me, Web based applications in general aren't slow if there is enough band width.

There are some kind of applications that can't be converted to Web because of its nature: daemons, realtime (ej: aircraft control), compilers, media editors and so: When speed really matters.

So, every body is looking for web applications not because they are "best technology", "cute", "fashion" or whatever reason you want, is to lower TCO costs and, in many cases, to made accesible to its users from Internet even if is thru private Intranet or VPN.

Regards.


rik_rs

  • New Member
  • *
  • Posts: 42
    • www.riksoft.it
Re: Future of Lazarus / FreePascal
« Reply #118 on: July 14, 2011, 01:19:36 pm »
Quote
With very little resources you bring applications to a lot of people.
I'm not very sure of this statement, at least not in absolute.
You can have at least these solutions

Solution 1: RIA online software. Client: Flash or Js/Ajax or Java or anything else.
Solution 2: as the above on LAN
Solution 3: desktop application with DB on their LAN
Solution 4: desktop application with web service

Just imagine a software to manage a store with the above solutions

- Developing cost: almost equal (for ordinary things) or more (e.g., as I already mentioned: try to change printer by software).
- Server cost: Web server, bandwidth/Traffic
- Manteinance: it depends on many factor. I have sold 1 thousands copies of desktop applications software for legal purposes by http://www.ilsole24ore.com/ and no one has called me for problem because I develop like NASA do. I have sold real estate software to a huge amount of agencies and I have THE INVERSE problem: they never had problems so is difficult to ask them money to justify assistance, because my software never have 1 problem. This is a problem but also a great value! 8)
So it depends on some factors, and the 95% is THE PROGRAMMER! :D
Just think at the maintenace of a satellite or airplane software: do they call for problems every day?

How much cost to make an online software SURELY not breakable by hackers, reduntant lines, backups, legal problems, risks of class actions (see italian Aruba.it web farm!), and so on?
How relaxing, on the contrary, is the 99% customer responsability of a desktop app with no other cost than BUY + assistance contract, without the hassles of line problems, server problems, webfarm problems, block out problems, slowdowns, and everything that even if not generated from a good software fall anyway out on our head?! Yes also OS problems can often be pushed against the desktop app, but web app are SURELY, LEGALLY, directed toward the software house, while that's not true for desktop apps.

LEGAL: hacking, server problems, bugs: surely 99% better avoided with desktop apps.

So I don't see a real COST problem of a portable desktop app where the only part of the installation could be a DB server if needed, against a server (don't touch glassfish!) web based one online.
Obviously that a desktop app that is a mess of spaghetti code, piecies here and there, lots of external Windows components, and so on, is not comparable.
But I can assure that a good desktop application can be ZERO MAINTENANCE. I SWEAR! I must call my customers to see if they are still alive! :D The only times a customer call us is for other reasons or because it is changing computer and want be sure that clicking "ReInstall" is OK. :D

I have more calls for email problems than for my desktop apps!


Quote
Intead of a big and costly workstation to run some often bad crafted Client/Server application you only need a Browser.
Where are big and costly workstations?!!! If you need one, you can SURELY abandon the idea to cope this problem with a server and browsers!!! Think also that a browser today require 200MB after 2 seconds of use: with the same amount of ram I can make the world control software for Obama. :D
Think also that today the worst computer of the world sold in a super store, is able to run very fast, every desktop application I can imagine to create, and 100 times faster than web apps... unless you have a Cray-X server or this one  :D http://cyberarms.wordpress.com/2011/03/29/nasa-systems-still-vulnerable-to-attack-even-after-warnings/
(see the title).

Quote
Intead of having hundreds or thousands database connections each one possibly with its own credentials, in web applications you use few to support the same ammount of users.
:o Desktop app are only SPECIALIZED CLIENTS like thunderbird for email instead of using a browser. Nobody force you to have a client/server DB with a connection for client instead of apache web server that provides web service results, even I think a good free/open DB like PgSql has no licence problems and dedicated connections can be a benefit more than open/close or pool management as happen on classic web apps.

Quote
Intead of an army of help desk and field technicians to support client/server applications you need few.
My case: 2 thousands licences and nobody call us. I receive no more than 100 calls per year and I could even go better. On the contrary of your idea, I seriously should think to CREATE PROBLEMS to justify manteinance contracts! We are now giving free assistance for NOT SOFTWARE RELATED software to the customers of our software to cope with the problem that our software has no problems! :D

Quote
And help desk calls drop almost to 0 because every body knows how to use a browser
:o You think the problem is about using the browser instead of using a native app? But a RIA app is WORST than a native app because ha controls the user is not accomed to. Furthemore, a desktop app can be identical to a web one if you want to worsen the interface! :)

Quote
no need of client software installation
What kind of installation need a portable app? DB? Depends! A web app need not only DB also installing a web server. We are talking of 1 for all server? OK the same for desktop app!
About unspecialized client (browser) against specialize client (portable desktop app): what if a client doesn't have flash, JRE, no java plugin, version problems, old browser, pop up problems, cookie not enabled, js disabled, IE security too high, FF no script add-on, banned IP, corrupted cache (some of my customer with sometime happend were directed on other sites by corrupted cache! :o), refresh problems, and so on?
A desktop app need only 1 thing: the existance of the OS... and is surely  there. :)

Quote
no update nigthmare
It depends: a portable app is only 1 executable: if a customer can't do this, it can't have a computer.
Think also that update of web components are more nightmare that a single monolitic executable. See my previous example: changing jQ stop TinyMCE working. The same happen for TONS of web COMMON components.
You are talking of update once for all? Solution: auto-update ad Firefox do. Don't forget that for web app, the browser is the client so is like part of the app, that has to be updated on computers basis one by one.


Quote
Almost any application can be crafted or converted to the web despite the technology used to do that.
Again: how to make automatic and direct printing, automatically using a printer instead of another, o using usb code bar reader, and so on with a REAL web app?

Quote
There are some that perform as fast as fat client application (Flex, ExtJS, Silverlight)
Other problem you remember me: some extreme technologies are not open source and tied to commercial companies like Silverlight or Adobe ones. Are they secure? How do they last? How you must invest in been aligned? Take a look at Silverlight: born yesterday is already at it's end as stated by M$ that is now more interested to HTML5.

Quote
Have you looked at JSON
I live on JSON! Xml ha 50% overhead! :D
Binary protocols: I have created some of them on my own with security enclosed.

Quote
Remeber: The slowest part of the system is ALWAYS the user
Surely and from the times of ENIAC, but this is true only on the overll view of a process, but has nothing to do with the problem exposed: the user perceive the difference of response from a real switch and a button independently from how dumb he is. Just imagine what he think of the web response when he is angry, stressed, caffeine addicted, and mobile phone dependent (that has the same effect as 100 coffees) and with 10 clients at hes desk waiting! :D

Quote
But believe me, Web based applications in general aren't slow if there is enough band width.
I believe you: buying a 10Tbps line always solve problems! :D It's only a question of money. Especially these days I don't find many rich/prone customers ready to spend X web app when they can have a desktop app for X/100 and possibly una tantum payment.

That's why I think that web apps are OK only under some circumstances, not as a forced substitute for desktop apps. I think that ONLY when a web app cannot be avoided for 100% reasons, then that's the moment to develop a web app; not first.

Quote
So, every body is looking for web applications not because they are "best technology", "cute", "fashion" or whatever reason you want, is to lower TCO costs
TCO cost I think can benefit only in some limited situations. Especially if apps are intended for single offices and not 2000 offices all together, TCO costs are surely bigger. Why paying a web server/lines when no requested? Are customers Santa Claus? And what if you want to sell a small app once for all with no mainteinace? How do you give for free an online web server to 1 millions of peple? Are you Google?
Why so many people abandoned big management software web based and start developing back dekstop applications?

I want to hilight that I'm not contrary to web app. I have some so I know what we are talking about. I also have more complicated stuff than RIA web apps, such as hibrid software: desktop app + web API, communicatings with online services and RIA apps. I'm also very well inside into web business: I own 2 real estate portals, hundreds of auto-updating sites (from desktop app) esporting towards 65 real estate famous portals. I'm developing special complicated site/apps for Zurich Assurance Agencies, similar to a CMS customer updatable and with an engine able to brings official datas from Zurich platform to supply agency users of many services, such seeing policies expirations, reminders, and many other automatic services. And so on...

I'm not contrary to web app, web sited, web solution. I am contrary to those who think that from today on we must develop only on web server because is the best o the best and cost nothing. THAT IS NOT TRUE AT ALL!
IMHO, the real reason this myth exists, is that the more users are tied to a web service, the less can migrate or stop paying that service. Commercially speaking (on the vendors view, not customer view) having 1000 customers paying 50$ for a web app, is better than having 1000 customers having a dekstop app because you OWN them like a telephone company: if don't pay a bill at the end of the month you stop working! If they buy a desktop app and by contract there is no monthly/yearly costs THEY ARE FREE.
This is the MAIN reason web app/web service (in both meanings: "SOAP" and generally speaking) are so appealing. The TCO cost is 2nd reason but is valid only in very few scenarios.
The 3rd real reason could be mobile phones, ipads, etc.: a web app is almost ready for everything without developing dedicated apple app and so on. This could REALLY be a real reason to have even a bigger TCO cost. However is not so simple: who prefer Safari web app instead of apple Objective C app in the iPhone? (Just to make an example...).

So web apps ok, but when they are really useful and a must, don't forcing their role, going out of scope making web app for everything.
Rik.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Future of Lazarus / FreePascal
« Reply #119 on: July 14, 2011, 03:20:45 pm »
Again, what drives applications to the web and the cloud is MONEY: With very little resources you bring applications to a lot of people.

While somewhat true, those arguments mostly only applies to the enterprise, a sector where smaller software developers hardly get entry to anyway.

Quote
Instead of a big and costly workstation to run some often bad crafted Client/Server application you only need a Browser.

Modern browsers are heavier than the avg db client nowadays.   And any new computer of the last 3-4 years (avg writeoff period new computers in companies) can handle both. This is nineties propaganda, recycled thin client/net computer stuff. A lot of RIA thinking is recycling of those ideas IMHO.

Quote
Instead of having hundreds or thousands database connections each one possibly with its own credentials, in web applications you use few to support the same ammount of users.

Only in the early nineties client- databaseserver apps. Most are 3-tier now, just like webapps. And webapps can make dumb assumptions and not pool connections and make mistakes with transactions too. THat is not just a class for webapps.

Quote
Intead of an army of help desk and field technicians to support client/server applications you need few.

Again a true one, but again mostly only for larger corporations or plants with centralized off-site IT.

Quote
I remember the first time I replaced a Client/Server application with Web based on LAN (not only for public access you use Web Applications) and despite the "slowness" of the rendering in the browser, people were happy because new application haves a lot more features than previous one.

That is not a client-server app vs webapp, but "old app" vs "new app".

Quote
And help desk calls drop almost to 0 because every body knows how to use a browser, no need of client software installation (not only the application itself but the components needed like database client software for example), no update nigthmare, etc.

New apps in corporations roll out via MSI's and group policy automatically.  I think you are comparing a nineties client solution to a modern webapp again, not a modern client and -delivery system with a modern webapp.

A modern clientapp wins hands down from an old webapp too.  E.g. when I helped sb upgrading an old webapp, the company was tremendously happy to finally be able to kill off IE6, and move from XP to Win7.  The webapp and related IE6 quirkiness kept them on XP.

Quote
Almost any application can be crafted or converted to the web despite the technology used to do that. There are some that perform as fast as fat client application (Flex, ExtJS, Silverlight) because, after all, are client/server (have you kown about the binary protocol used by Flex? Have you looked at JSON, not so compact as binary but small enough); others are slow because is Web 1 technology (full page rendering per click) or use Ajax but slow because and large portions of the DOM, etc.

Yeah, but that is just it "must be web".  With the plugins, the "just a browser" principle already goes out of the door. Flash has almost weekly security updates, and with plugins, zones where they are active must be configured etc etc.

The pure web apps  (the html5 bussword stuff) works fine, but often deals badly with large resultsets. Also the integration of webapps with e.g. word and printers is often bad.

Quote
Remeber: The slowest part of the system is ALWAYS the user, so "slowness" is acceptable.

This is totally bollocks. One slowliness doesn't excuse the other. An average office coffeemachine brews a cup in 10 seconds, that the officeworker takes 5 minutes to drink. But I think there would be hell to pay if the brewing process suddenly also took 5 minutes :=-)

Quote
There are some kind of applications that can't be converted to Web because of its nature: daemons, realtime (ej: aircraft control), compilers, media editors and so: When speed really matters.

One must always keep reality in sight when moving stuff to the web, and never assume that the first order mantras (webapps less maintenance) ALWAYS apply. You have to keep checking your assumptions and expectations. As already demonstrated, plugin management is client-stuff creeping back through the backdoor.

Also one must remain critical of articles and benchmarks. Many of the praising articles are written or sponsored by the vendors of webkit software. Like any commercial piece, they choose their benchmarking parameters to be ideal. 

Just like Intel sells you a quadcore that it says is four times as fast as your old single core, but in reality for your mostly singlethreaded apps, the improvements are only a fraction. But of course Intel benchmarks with a threaded app.

So the webdevel system vendors compare with older client apps, and compare it with the best they can deliver (which often is often a squaky clean project, homogenous topdown designed and legacy free, while your own app needs to reuse existing databases, is a heterogenous platform and has to work in a real company with less than perfect or new infrastructure (read 6 branch offices that still use original win95).

Quote
So, every body is looking for web applications not because they are "best technology", "cute", "fashion" or whatever reason you want, is to lower TCO costs and, in many cases, to made accesible to its users from Internet even if is thru private Intranet or VPN.

My rule of thumbs are:
- I don't really believe in RIA (as in Adobe Air, Silverlight etc, even flash ). All applications I have seen are cumbersome and a maintenance hazard, and I've doubts about their longevity. Maybe this will change, but it is IMHO not there yet.
- I do believe in browser/webapps and their TCO advantage. But not for everybody, and not every app perse. But those advantages don't apply to anything stamped with the "web" moniker, and only reasonably cleanly implemented solutions with few dependancies are truely futureproof and low maintenance. As soon as you need assistive technologies like plugins, reconsider if this is really the way.
- Rule of thumb there, the more "occasional" use, or use by low ITed personel, the better a webapp is. ( Computer skills differ between a reception coworker vs a licensed bookkeeper with a lot of SAP skills). 
- Consider a tiered system with both a webfrontend for occasional use (and by branch offices) and a full client only for the handful of real heavy users. (that use it all day)
- Webapps are often horribly underpowered initially, and branch offices (that switch from occasional batch data transfers to an "online" model) are often forgetten. Avoid this trap, and make sure your initial analysis is right, and do performance testing on sufficient scale before rollout.

- I've been out of the running the last two years, so the practicalities (and economic "feel") for "the cloud" has mostly passed me by. I do worry about their longevity, specially for the more specialistic clouds. Migrating between clouds often means rewrite of application, and you bet that the prices of legacy cloud generations and systems will go up in time.
« Last Edit: July 14, 2011, 11:34:14 pm by marcov »

 

TinyPortal © 2005-2018