If you were designing an application that was to be used for displaying data and manual data entry, where all calculations and manipulation is done on a remote server, is there any reason to have it as a standalone application rather than browser based?

If it’s standalone application you do not need to worry about supporting multiple browsers and new versions of said browsers. No issues worrying about internet security. No web services to set up etc.

An application, you just need to know what environment it is to run in and keeping it compatible with e.g. Windows versions which are updated less frequently than browsers.

Sure there are more to come, but I think they are valid starters

Slow browser connection, batch processing model, corporate standards, legacy application involvement, competency of coding team, existing infrastructure?

As computers slowly take on the characteristics of smartphones and tablets with the advent of app stores, we are going full circle. I’m not sure what the uptake of app stores is on different device types like Windows 10, Mac, Chromebook but you’d not think twice about developing an app for a tablet.

I’m not a developer but it would appear that browser compatibility is becoming less of an issue than it was 5-10 years ago.

but it would appear that browser compatibility is becoming less of an issue than it was 5-10 years ago.

Well, they just mainly develop for Chrome and the other browsers just have to play catch up and fix incompatibility issues themselves. Plus MS have thrown in the towel and are just re-shimming Chrome for Edge mark II….

https://www.theverge.com/2018/12/6/18128648/microsoft-edge-chrome-chromium-browser-changes

Coding browser based applications is a bit of a bodge, because it was never really designed for that purpose. And there are thousands of application frameworks spun off from some project by nerds hoping to get rich and famous by inventing the next greatest thing, so the current best thing seems to change almost weekly.

Writing apps native to an operating system is far easier, because the tools are better – in my experience. On say Windows, there is one way of doing things that everyone expects to see, so that makes design much easier too.

However the huge downside is that a native app only works on one platform. You’d need to develop the whole thing again for Mac, Windows and Linux never mind mobile platforms. Web apps can be made to work on everything with minimal hassle.

Of course, there’s also a solution to that in the shape of Java desktop apps but for some reason they never took off. Shame, cos the idea was a good one IMO. They had a bad rep amongst developers, as you will see shortly when someone pops on here to slag the idea off 🙂

And, you have to install the client on the computer – which you don’t with a web application. However, for internal corporate applications it doesn’t make a lot of difference tbh because you could easily roll out the client along with the rest of the corporate build.

For what it’s worth by far the worst performing apps at our place are browser based. Second, anything in Citrix.

Slow browser connection

Could you explain this a bit more? Is there something that would make a browser communicate more slowly with a server compared to an application communicating directly. Would it vary from browser to browser?

batch processing model,

Could you give me simple example of how this would behave differently for a standalone vs browser based app?

Thanks!

@slowoldman – tell the people that run the network. I spot a theme…

all calculations and manipulation is done on a remote server

Doesn’t sound that stand-alone to me, i.e. it has a dependency on another application/service.

Application:
Where are your users, how will the application be updated, what platform do they work on. Do you need to verify their identity, do you need to audit their input. Where does the data go that they are inputting?

Browser based tool:
Easy to update, easier to add in authnz, easier to load balance for many users, should be user platform agnostic (if it’s not developed by a numpty). Easier to communicate with back-end server. https comms with data repository.

These are some random points based on the limited information we have so far. Understanding the flow of information and users would be more useful though.

tell the people that run the network. I spot a theme…

Ah but it’s not.

You’d need to develop the whole thing again for Mac, Windows and Linux never mind mobile platforms

In a lot of respects, that would just be a design fail. You’d set it up with an interfacing layer so that your app’s requests can be passed off to the appropriate underlying OS. That sort of design pattern goes way back.

In other news, I agree with rest of post.

Apart from the Java bit. Java just didn’t ever seem to get its act together. And, name me one reliable Java desktop app. Nice idea, but no cigar.

Doesn’t sound that stand-alone to me

Yeah, standalone was the wrong way to describe it. I was trying to distinguish it from being browser based so I probably should have just said desktop application.

All the application does is display the data stored on the server and allow the user to manually update parameters that the server uses to make calculations on the raw data.

Nice medium here – https://medium.com/@collinmathilde/why-desktop-apps-are-making-a-comeback-5b4eb0427647

I’ll add my tuppence on this

manual data entry,

This is a ball ache in a lot of web-apps. E.g. Jira – you need a mouse to execute a lot of tasks, even when you’ve clicked on Edit, tabbing between the fields doesn’t always do what you need (nested 😛 e.g. text box comment fields don’t jump to the text edit box)

Perhaps Jira is not a great example, but in apps where you want users to input/process a lot of data correctly, a desktop app can be better.

As computers slowly take on the characteristics of smartphones and tablets with the advent of app stores, we are going full circle.

We’ve already gone full circle: dumb terminals to client-server to browser/web (dumb-ish terminals 2.0) and now to “apps” (client-server again).

The client server model means you have to keep updating the clients when you make changes, though that is easier now than it was in 1995. The advantage is that a client application is more versatile, though again that has changed a lot with web pages able to do stuff that wasn’t dreamed off ten years ago.

In the end a lot comes down to existing architecture and skills of any in-house staff.

All the application does is display the data stored on the server and allow the user to manually update parameters that the server uses to make calculations on the raw data.

Another consideration – can you run your browser based software on the same server, or are you going to end up with an app/web server in between the user and the database/processing server?

Might be a reason to avoid a web app if you don’t have that expertise in-house.

edit:

In the end a lot comes down to existing architecture and skills of any in-house staff.

That /\/\

And, name me one reliable Java desktop app.

jEdit

It might depend on how rich and responsive a user interface you require. In some cases a browser app will be unable to provide the same features as a native app (or so cumbersome and limited that it would be practically unusable).

Intellij is another example of a (class-leading) java application.

Unless I had very odd requirements (talking on raw tcp, high processing or latency requirements) I don’t think I’d ever architect a thick-client application again. The install/update ease, plus the ability for zero-footprint applications (particularly with cloud infrastructure), plus the availability of talent in future (they don’t teach ui in anything other than html/js any more) make rich single-page applications (say react or angular) make it a no-brainer for me

5lab is right, but it’s annoying to me from a conceptual point of view. Web technologies were never designed for applications, and everything we use is an attempt to mitigate that.

Given the choice, as a user, I’d always choose a full-fat client over a web client. Web clients have the portability advantage and (usually) don’t require you to install software, but they’re almost always so damn slow compared to a real client. A couple of seconds’ lag is fine on a web page but a complete usability PITA when you’re trying to get something done in an application.

Also, keyboard shortcuts.

I don’t think the software for controling nuclear reactors or aircraft traffic is web based.

Bruce – your original question is not far off something I used to ask in job interviews for developers. It was quite interesting to see the look of befuddlement on some…

However now that you have provided a bit more information:

All the application does is display the data stored on the server and allow the user to manually update parameters that the server uses to make calculations on the raw data.

Then the answer is: “it depends!”: would the user ever expect to interact with the app when they have no (or very poor) internet connection? would they expect to at least be able to see the last results/outputs when off line? are there enough “manually updated parameters” that it would be a PITA if you lost the connection and had to redo the data entry? how much data is getting moved back and forth for display? do users ever want to print the output (whilst you can print within browsers its often a bit messy)*, how long does the server take to do the calculations (that’s not necessarily a make or break – but might need to the webapp designer to think a bit differently if the server will time out).

*to a lesser extent the same may be true for saving files (where the browser typically dumps everything in “Downloads” rather than giving you a nice folder structure); and “sharing” by email, to sharepoint etc – which can be a bit clunky from a browser. These things can all be overcome but if that was the main workflow it might be simpler to make a desktop app.

True. Although I’d be surprised if it wasn’t running on Windows 2000.

so the current best thing seems to change almost weekly

Front-end frameworks tend to go out of date in the time it takes to download the SDK.

Once WebAssembly ships and is stable native will be a thing of the past for applications that require lots of grunt. However these days progressive web apps (inc service workers) are making the boundaries very blurred. Depending on what you’re doing it’s very easy to develop an application that can work perfectly well offline, and then sync up to the remote store when a connection is established.

React has been one of the most stable front-end frameworks for a couple of years now, its only competition being Angular and Vue. The eco-system is focusing more on the surrounding tooling rather than throwing out a new framework each week.

Then the answer is: “it depends!”: would the user ever expect to interact with the app when they have no (or very poor) internet connection? would they expect to at least be able to see the last results/outputs when off line? are there enough “manually updated parameters” that it would be a PITA if you lost the connection and had to redo the data entry?

No, no, and no.

how much data is getting moved back and forth for display? do users ever want to print the output (whilst you can print within browsers its often a bit messy)*, how long does the server take to do the calculations (that’s not necessarily a make or break – but might need to the webapp designer to think a bit differently if the server will time out).

Not much although I’m not sure how best to quantify it. The calculations are done continuously as the raw data comes in. The raw data is displayed alongside our calculated values (ie, this is what you should be getting and this is what you are actually getting).

Basically, if there isn’t an internet connection, there’s no reason for anyone to be looking at our software.

A well-written browser app shouldn’t be any slower than a thick client (ok, js is a little slower than bytecode but run on the v8 engine there’s naff-all in it) and a Web app can definitely take keyboard shortcuts. That said, I do recognize that well-designed apps are few and far between, and as apps often bloat out to infinity the performance suffers

That said, something like Gmail is pretty much on a par with Outlook these days

The calculations are done continuously as the raw data comes in. The raw data is displayed alongside our calculated values (ie, this is what you should be getting and this is what you are actually getting).

Sounds like something that would work well with a web socket (or SignalR) / React / observables etc.

build both web and app?

https://electronjs.org/

<ducks>

is there any reason to have it as a standalone application rather than browser based?

Sounds like the answer to your question is…probably not. Unless you need to access native OS features or your user base demands/prefers a desktop app – hard to say with out seeing a feature set.

.

And, name me one reliable Java desktop app.

jEdit

+1 to that

Still my fallback editor even after all these years – even good on a mac.

It is the only one i can think of though 🙂

My previous job was training on an application upgraded from local, server-based to cloud-based – my experience of the outgoing version was serious slowness, the cloud-basd version was pretty much always quicker, and when customers had remote sites accessing the server-based app, the upgrade was a massive speed benefit without exception (one site told me accessing the app from the remote site was a waste of time as it didn’t work and stopped the application working at the main site!). There’s also more access options – but as noted, no keyboard shortcuts, which some folks (rightfully!) honked about.

name me one reliable Java desktop app.

SoapUI, Eclipse, Tibco… I use quite a few. I’ve seen quite a few data entry desktop Java apps too, ugly things with loads of fields that expert users love. And very, very hard to build on a browser.

OK – here’s an example, a desktop application is the better solution when, in addition to remote server database access, local file/ network access is also needed. For example to read or write files to a local network shared folder, or grab data from a local ODBC source. There’s ways to bodge it with a browser based solution, but it involves browser extensions and gets silly.

FWIW I’ve spent a lot of time over the last 10 years building and maintaining some bespoke software for a distributor which is 95% a remotely hosted web app, but there is also a couple of “desktop” components which take care of the local network access requirements within the office. It’s a pain when I have to do any work on those components, which sometimes requires a site visit.

100% web based is still the goal, but it will require a behaviour change for the users, and that’s the hardest challenge (they were still using fax machines when I first got involved)!

We also have a few good Java apps for work. But I think they are being sunset. Shame, cos I think it was a really good solution and they worked out the kinks in the UI side of it.

“Eclipse”

Reliable? Our definitions must differ then.

OTOH I tend to work with stuff where the internet doesn’t exist and reliability is king.

In the OPs specific case I think you’d be slightly crazy to not do it as a web app. A thick client front end has advantages in some scenarios (local processing, easier UI interaction for complex stuff etc.) but if it’s just to display content processed by a remote server and to allow form-based data entry then that’s the perfect use case for a web client.
The only other use case I can see is for RPA (robotic process automation), when using web forms you’re generally constrained to targeting data entry at a specific point on a page and if the formatting or resolution changes the robot breaks – whereas there’s often better integration with thick clients in that the robot understands how to use them better and is more adaptable.

Slow browser connection

Could you explain this a bit more? Is there something that would make a browser communicate more slowly with a server compared to an application communicating directly. Would it vary from browser to browser?

batch processing model,

Could you give me simple example of how this would behave differently for a standalone vs browser based app?

Perhaps I should have said perceived slow connection/latency rather than slow connection – particularly if you do on form AJax etc to pull data off the server mid page. Any slight delays are very obvious to users of a form where updates take more than fractions of a second.

A batch (or page) processing model assumes a design where data is submitted at the end of a process so a half second here or there is less obvious as it either occurs as a page refreshes so is less noticeable or with a much more background task where the user isn;t aware it’s happening.

If someones going to be sat banging data into a web form for 8 hours a day they’ll notice any slight delay.

Tabbing works fine in a browser – you just have to make sure the form is setup to take the user through them entries in the desired sequence. Tbh, for an entry form it should be designed to be used with just a keyboard, tab through enterign data get to ‘submit’ and press enter.

“Eclipse”

Reliable? Our definitions must differ then.

Been using it for years, not seen any major problems assuming you’ve given it enough memory. Certainly no worse than any other software I’ve used, apart from Notepad they all seem to crash at some point.

From a user point of view, the bulk of non major name developer browser based application for desktop are a complete usability disaster. The biggest sin by far is the designer assuming they can have the whole screen. Especially when it’s a single button that refuses to leave absolute coordinates for bottom right corner of full screen that’s a major fail.