Hacker News Reader

Comment by mtkd | Hacker News Reader

If anyone using Delphi to build big apps in early 90s was told that to do the same function in 25 years time they would need HTML, CSS, JS, Ruby or PHP or similar, some SQL, some Rust or Go and probably a few DSLs - it would take months longer to build - require multiple servers - and would need more test code than app code to get it 98% as stable - you wouldn't have believed a word of it.

Every single time I have to use a grid control online I shake my head.

I strongly suspect the generation after this will rediscover the power of desktop apps and some of the dev tools that were around at that time. Web interfaces just don't work efficiently for some roles - especially in enterprise environments.

View on HN

You're still using Rust / Go ? I've been using Luna on the Rocket stack, with Huston for distribution and Apollo for stack management, and it fixes mostly all the problems you've mentioned.

I seriously can't tell if those are things or not. I'm so far behind!

I invoke Poe's law.

I'm out of the loop of the cutting edge of UI stacks, so I genuinely do not know whether you are sarcastic or sincere...

Just make sure to avoid Apollo release nr. 13 as it is rumoured to contain a nasty bug. Something with some storage method causing it to blow up I think it was.

I thought someone proposed a fix for the AGC module?

So, you should be safe with v. 11...

Houston's great for monitoring.

This is either sarcasm / joke, or the top of the current hype-berg.

I use emacs+org mode, and it fixes all those problems even better

> I've been using Luna on the Rocket stack, with Huston for distribution and Apollo for stack management

That's so 2016, you really should get with the times.

No! Ethereum.

You're wasting your time with Luna? I'm using stackless Albus, and use ADD (anticipatory driven development). It eliminates all config and perf issues with the Rocket stack, and leaves me time to contribute to the Satori project.

>I strongly suspect the generation after this will rediscover the power of desktop apps and some of the dev tools that were around at that time.

The biggest thing desktop apps are missing was the delivery mechanism. With web apps:

* a new user is just a hyperlink away * pushing app updates is a page reload * server-side state eliminates all of the migration headaches for client-based state

People are fickle and they will decide not to use a service if it takes a couple of seconds to load. When you require them to download an app and install it, you've already eliminated two major categories of users: impatient users, and users who don't know how to (or aren't allowed to) install applications.

webassembly + full page canvas. games already work like that. hopefully sanity is just around the corner.

Wouldn't Canvas need more advanced text handling for that to be practical? I know that's a big reason canvas based frameworks never took off.

The problem with using the canvas functionality for everything is that it's an all-or-nothing proposition, and you end up having to write a lot of stuff that is already handled by the browser, or can only be handled by the browser (think bi-directional text/NLS issues).

I don't think that's a problem, personally. Something like canvas should be an all-or-nothing proposition. There's very little overlap between what you need for content-based static web pages and applications that just happen to run on the web.

The problem is canvas wasn't designed to be that all-or-nothing alternative to the DOM. It was designed as an alternative to the flash player for html5 games. As a result, it lacks several features that are needed to display generic content, the most prominent of these features being proper (and easy!) font rendering.

I suppose you could build your own advanced font rendering engine (I think Flipboard did exactly that), but that's more work and risk than most companies or even individuals are prepared to take these days. And you are right; creating your own would cause you to re-create a lot of stuff that's already handled by the browser, like font highlighting, copy/paste, etc.

I personally suspect that actually, Henry Spencer's famous prediction is more likely what's looming around the corner.

You just wait - there will be a terminal emulator written with webassembly+Canvas eventually. Perhaps powered by the already existing Emscripten port of Linux.

Could you run a browser in that thing?

yes this was always the reason given for not using Delphi instead of making a web app in every enterprise I worked at. Every time I said "hey how about we do this in Delphi, we'll have it finished in a couple of weeks" the argument was "but we'll have to put it through the windows guys and get a package made and distribute it to the users", so we made a web app. a couple of hundred grand later we had a web app, it wasn't as good as what the Delphi one would have been, it was slower, less features, but hey our 20 users didn't need to download it. lmao, I was paid by the hour.

I write enterprise apps almost exclusively in Ruby and a very small amount of SQL and HTML, but I'm guessing Delphi doesn't have some magical fairy dust that makes SQL unnecessary.

If you told me your stack is as you described, I'd say there's either some serious overengineering going on where you work, or you're solving a very different problem that would have been very complicated even in the Delphi world.

I think you're also vastly underestimating the operational work involved in deploying, maintaining, and syncing thousands of desktop apps in this type of environment. I'm personally happy I only have to get my software running on a couple nodes both with the exact same configuration.

Delphi used drag and drop and property setting to do most of what you'd do in Rails. Whether it's validation, master-details views, specifying display formats to represent decimal formats as currencies, specify the correct editing control for a database column - all specified as properties on the components representing the connection to the database.

You'd then be able to drag and drop columns from the list onto a form, and it would create the correct components depending on type, with appropriate labels, etc. Similarly, drop a grid on a form and get type-aware in-cell editing. Automatic updating of a details view when navigating through a parent data set. Etc.

One of the nicest things about Delphi was that you could compile into a single executable that you could deploy without further dependencies. One of selling points of Go, 20 years ago.

Same with when we developed oracle forms apps in late 90s or to a lesser extend VB. So much slower and more complicated to produce something simple which works for 90% of cases for business apps.

You can use Java with GWT everywhere.

Reply on news.ycombinator.com