I agree to everything Esteban said. It is about options. And Web is not the answer to everything, quite to contrary. For us Web is a limitation of power, you struggle mostly with backend connectivity (reaching out for your objects) and if you want to do something nice you end up doing it in javascript with a lot of libraries. It is hard to write something nice in a web environment and maintenance is hell.
Norbert > Am 20.04.2019 um 10:43 schrieb Esteban Lorenzano <esteba...@gmail.com>: > > Hi, > > First, your examples are biased :) > Still, you do not get the point: the point is that not everything has same > requirements. Pharo is a tool to allow users to provide answers in a general > cases, not just the two or twenty you can think about. > > Also, to counter your “Case”, here what I think: > - “Most” applications nowadays have autoupdate mechanism that works perfectly > fine to keep the applications up to date. Pharo in particular is particularly > suitable for this kind of behaviour (I implemented this autoupdate mechanisms > ten years ago, when autoupdate was still not “a thing”). > - By doing a web application you may “save" the distribution of updates > version better, but you are “buying” the cost of maintenance of an hybrid > application that will rely… guess what? In third party frameworks! (Starting > for JQuery, but a lot others if you want your app to look modern and cool). > - Tablets: yes this is a constraint (still, is just a constraint not present > “in general"). But if you think a web application will work out of the box in > a tablet you are fooling yourself (thinking on UX here). > - “Prepare 3 new images”: if you are doing this manually today, you are doing > something wrong. Also, if you need to install your images from scratch for > each new user (instead just copying them), you are also doing something > wrong. > > Let me put this counter example: Some years ago before I came to work for > pharo I made this app called “the lawsuit tracker” to a legal office in > Argentina. Since they had two offices in different regions I proposed a web > application as a first solution which they rejected because “is > uncomfortable”. So I took wha I had in hand there and I made an app that > mixed Magritte with Glamour (this was the origin of Voyage framework, btw). > - I added an autoupdate mechanism (they query for packages in a particular > ftp location and they install them if new are found), > - local configuration was in an external file. > - I packaged it a “one-click” image with some extensions to verify which libc > they where using (they target was to move to linux from windows in some > couple of years). > > And I "installed it” by sending a mail saying “download this, unpack and > click”. > > So, each time there was a new version I was producing the same (with a > script), and already installed versions were updating automatically. > > (Ah, btw I was collecting errors by fuelizing them and saving them in the > database, so I was able to dig into errors later). > > This was 2011. > By 2012 I came to work for Pharo. > > Last time I went to Argentina (last year) I talked with the guy that is > responsible of doing the “technical service” of that place (he is a friend of > mine): they are still using the same application (and very happy with it). > In the same time they opened two new offices so the user number passed from > 18 to 35. > They completed the migration to linux. > > Everything is still working: > - Pharo 1.4 > - Stack VM > - MongoDB 3 to centralise information over a secure connection. > > So… I have a very successful installation of a Pharo desktop application > (even in moments were doing this was not easy, I needed to hack a lot to > “close” the image). > And not an hypothetical case, a real life case. > > Still: I DO NO SAY THIS SHOULD BE THE GENERAL CASE. > I say this has to be possible. > And I also say: there is a lot more use cases out there when this “web” > answer just does not applies. > And of course there are other tons of cases were the web application is the > right solution. > Why you want to constraint yourself to just one solution? > > When you develop an application you have to decide the best architecture > possible taking into account the constraints you have, not some ideas of how > things should be. > > Esteban > >> On 19 Apr 2019, at 23:50, TedVanGaalen <ted...@gmail.com> wrote: >> >> Hi Esteban >> let me write an example: (lots of time at the moment) >> -------- >> Hypothetical CASE 1 Stand Alone Solution: >> >> Currently it's just a pilot/study project, but let's assume for a moment >> that after a year so of really hard working on it in Pharo, I finally >> completed my dental application system, that is, as as a stand-alone desktop >> application... >> >> After splatting a few initial bugs, the dental clinic is happy with my new >> dental application, and they paid my bill. Mods were relatively easy to >> implement, because it is Smalltalk, not to mention the fantastic debugger >> facilities, simply very cool. >> >> They need to run the app simultaneously on 4 computers: that is 4 stand >> alone apps running their own separated Smalltalk images. Using a Postgress >> server as a DB on one of their PCs tied everything together. Apart from >> having to install live Smalltalk images om each computer, backing them up >> etc. not much of a problem, one would think, right? So far so good. ...apart >> from having to install and maintain the app on each and every computer they >> use, that is... >> >> Two weeks later after my app went real: The clinic is expanding and another >> 3 computers will be added soon, meaning yet even more to install and >> maintain. Hey! also a new update of Pharo arrives, I need to update 7 images >> import my apps packages in the new images again. ( let alone the many system >> updates on especially Windows machines) Test if everything works ok again >> etc. Having no down-time is crucial: all done outside of the clinic's >> working hours, of course. Great. >> >> Oh, I almost forgot: they will install a iPads and/or Android tablets soon, >> which will mounted close near each patient chair. They do that anyway >> because analytical imaging apps and a drill controlling app of other firms >> run on these tablets. They would be happy if they could run my dental app on >> these tablets too, so they don't have walk back and forth to their PCs all >> the time. >> >> Jikes! Now I am really stuck! Because I wrote a stand alone app that doesn't >> run on these tablets! What can I do? >> Write special versions of my app for Androids and iPads? Impossible! this >> would take me a year or so. Nightmare. >> >> In the end the clinic dumped my app and thus me, and bought another app from >> another firm, which runs on all devices because it is a web app. How could I >> be so stupid not to make it a web browser app in the first place? >> -------- >> Hypothetical CASE 2: App as Web Browser App: >> >> Took a more modern approach: programmed my app for user access via a web >> browser, A web browser is, if you really look at it, in fact nothing more >> than a very advanced user terminal with endles GUI possibilities. Which btw >> allowed me to style the app esthetically in any way my customer likes. Now >> the cool thing is, on many devices, whether PCs, Macs, Android and Apple >> tablets and Phones the user GUI presentation and interaction is nearly >> identical. Which implies, I have to write my dental app only once, and it >> will run on any device that is connected to an intranet or internet. Not >> only that, there is just *one* single Pharo Image running instead of many >> stand alone apps on an ever changing nr of computers. .When installing a new >> Pharo version or update the app, I test it on another Pharo/Seaside server >> and can switch seamlessly between the two. The dental clinic is happy >> because it runs flawlessly on all devices they have and expanding or >> shrinking the number of devices is no problem. Not only that, In case of >> problems one can switch in no time to the shadow server app so we have >> continuity here. >> >> There is another important advantage as well. The users interacts with the >> app in a browser window only, (a thin client) that means they don't have >> access to the real application, that is, the delicate Smalltalk image of the >> Pharo/Seaside server app which runs 24/7 on a reasonably fast computer in a >> locked room with an emergency power supply of course, together with its >> friend the Database, and the room is only accessible by a responsible >> employee(s). >> >> I am happy too, not only because the customer is, but also because I avoided >> a nightmare and can do maintenance and updates, say, in 5 % of the time >> needed when I had to do maintenance for e.g. 7 stand alone apps running om >> separate computers. >> --------- >> So far for my hypothetical examples, just to illustrate. >> >> Note that on the internet, each site that you might visit is of course a web >> app of its own. So you probably interact with more web apps than you'd >> realize. Note that some are really advanced like e.g. web shops like Amazon. >> There are many good websites that function really great, but a lot are >> almost depressing. You're absolutely right that a lot of it is inferior, but >> you might have noticed also that things are slowly improving. >> >> This bad quality with (still) many web apps/sites is because as you know >> these are mostly built with chaotic hybrid systems/tools and unsafe >> languages like Javascript, ever changing packages, interfaces, tools etc. >> >> Compared to that, building web apps with Pharo/Seaside is a lot more >> straight forward and reliable, because everything is done in the Smalltalk >> image. >> >> Note that the web browser is not the limit itself, but rather the web app >> using the browser GUI. You can really design and build beautiful and >> ergonomically sound web apps, because there are so many possibilities. >> >> However, the main reason for choosing to make apps as web apps is that it is >> the only way to get your app and data accessible op nearly all devices. >> Build it once and run it everywhere. >> >> You see, this is a typical application developer's perspective, not that far >> from reality, I can tell you that. >> >> Kindly asking Tool Developers to learn more about the people and their >> environment they build tools for. >> because it's not only tech but a lot of things around it too. >> >> In any case Smalltalk/Pharo/Seaside is a great to build apps with. >> Unfortunately a lot of people still don't know this. >> Kind Regards >> Ted >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >
