Hacker News Reader

But is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer?

Obviously there is the advantage of the web platform to leverage with JS frameworks, but there was something really nice about being able to drag and drop standard controls that all users were familiar with, and then just attach some code to them that talked to a database or whatever. I think that was the Parent's point that modern web development, while having the advantages of the web, is still more complicated than what was popular a decade or two ago for making UIs.

"is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer"

I asked something like this too, but the other way around.

"If Flash, Delphi, etc. were so good, where are they now?"

The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams.

Delphi is "textual" as well - the designer works with text files (*.dfm) that describe the component tree. Very similar to JSON, but with more Pascal-like syntax. People mostly used the designer because it was easier - but then again, in that era, it was also common for people to use e.g. Dreamweaver to write HTML.

Maybe, getting into development got easier?

I mean, while these graphical tools certainly help, you have to learn them. I learned things like Photoshop, Sketch, Ableton Live, Final Cut Pro, Eclipse, etc. pp. and I can tell that it's a huge time investment to get up and running.

Maybe coding is that much easier, that people invest their time into this instead of a UI builder?

Maybe people got burned by Flash and now want to invest into somthing that lasts longer?

GUI designers of the RAD era were much easier than Photoshop or Flash, and certainly easier than writing it out by hand. That's precisely why they became so popular.

But why didn't they stay popular?

Did the Flash disaster cast fear into people?

Did Web-tech based systems perform so much better, business wise, than native desktop apps?

The most popular frameworks with the best tooling weren't cross-platform. VB, Delphi, .NET/WinForms (and later WPF) were all Windows-only. Delphi briefly played with Kylix, but it was very messy.

Then you had Qt, which is a very Delphi-like take on GUI in C++, and was cross-platform - but it didn't have the integrated tooling on par with the other stuff, and of course the language being C++ raised the learning bar significantly.

Qt is much better these days, thanks to Qt Creator - although C++ is still a stumbling block there. But in the meantime, web apps took over - and that was before stuff like React. I don't think that had anything to do with ease of development, but rather with ease of deployment (or rather lack of it) - it's much easier to get people to use your app right there in the browser than it is to have them download and install it. So web won not because of its technical superiority, but despite it - and then dragged the desktop down (Electron etc) as a result.

I remember in the 90s there was a push for putting things on the web to avoid licensing fees and installation, despite how limited html and JS were. And there was the temporary popularity around Java applets to provide a more rich web experience prior to Flash and then finally HTML 5.

Delphi and it's opensource cousin Lazarus/Freepascal are doing just fine and I use those to implement desktop applications. Single exe with no dependencies. Beauty. Sure they're not popular in North America but I could care less. Those tools save me a boatload of time. There is also QT.

"The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams."

Utter nonsense. They scale just fine. Whoever gave the answer seem to not know what he/she is talking about.

How big is your team?

Wrong approach. The claim was made that Delphi does not scale for big teams. Name me one single Delphi related (mis)-feature that prevents it to scale.

I don't use it, so I can't tell.

Checking if the users are all small teams would at least imply that this could be true.

> Everyone is basically complaining about complexity for applications, which are more than just a server-rendered form or message board (which is a way less complex applications compared to outlook or slack, where "realtime notification" is a requirement).

But we did more than just a server-rendered forms in delphi, vb and others! The hate is not for js or html (well, in this case at least). The hate is for invention of techniques which are hard to explain, follow, justify, implement and reason about.

Web had an enormous amount of seasoned and veteran developers around the world and threw this resource out the window by going a new fancy way of history repeating, which presumably no one did before and no one knew names for new methods when they appeared.

React/Redux is ST by the way, implemented in a language completely unready for that concept, but it’s unclear if its authors were aware of this at the time it was born.

I find lots of these "requirements" come from developers that are bored with their job and need to spice things up.

Or are trying to follow fads so they're more employable (resume-driven development?) Which is a strategy I am not criticizing in the slightest. It can suck when it means the whole team has to learn the fad framework, though.

This is definitely a thing. Lots of tech choices are made for that reason, not just front end frameworks, as I'm sure you know. But there's no incentive to put one's foot down and declare that the emperor, indeed, has no clothes, so we keep praising his fashion sense and taking home our pay. This is true for developers at all levels, project managers, CTOs, and so on. Every one of them becomes more employable—easier to find the next job, next job's higher-paying—for having lead or been a member of a team using inappropriate or sub-optimal but trendy or "serious" tools. "No one got fired for choosing..." has extended to a ton of trendy crap, a fair bit of it half-baked, and you're not only safer but also better off financially than if you risk suggesting anything else, even if "standard" solutions slow down development, require more and more expensive people (that's the point, you want to be one of those!), and make your systems more fragile.

Are you implying realtime notifications on a chat or email service is not a requirement?

Maybe! But also, as a user, I expect to do more and more in my browser.

I would find it strange, and probably switch to a competitor, if my preferred airline for example made me install (and keep updated) a desktop app in order to book a flight.

This seems like a strange example since being able to book flights in your web browser predates any Javascript "frontend framework".

You do. Not everyone.

You know one thing I expect my browser to do that it has a hard time doing these days? Efficiently and correctly displaying text documents.

It has a hard time doing this because so many web pages think they need to be web apps and overthink things instead of leveraging the tools at their disposal in the browser.

Yes, if you're building a new Outlook or Google Maps in the browser it ought to be a web app.

If you're building the remaining 90% of use cases it should probably just be a web page with boring old tech. Add JS for spice if you'd like.

Nobody asked for stupid native-level functionality nonsense in the browser.

It takes too much Javascript, which is not efficient to parse or run, and is usually wasted on "looking/feeling fancy", not actual functionality.

Looking and feeling fancy is often what sells though... that is ultimately more important.