[bluejellybean]

The web, and much of programming really, feels so far behind the curve of what's possible as a programmer. Take a dive into shader design in something like unreal engine 5, it sounds exactly like what you're describing in Delphi, mind you, I say this as someone who has never programmed in that language. The ability to drag and drop functions, compose higher levels of abstractions, and really all of the fun programming stuff we do can be accomplished in these engines. I've found it very enlightening, and even somewhat frustrating, to go from drag/dropping some graph nodes that generate a playable world for fun, and then back into the world of javascript for work where I am slinging 100s of lines of text-based code just to get a form button to operate correctly.

[magic_hamster]

In game engines, and especially in UE where things like Blueprints exist, the low level stuff is just conveniently hidden or abstracted away. But the long textual code that makes the button work, eventually exists somewhere in there. At least when you write it yourself, you know who to blame (and probably where to look) when it doesn't work.

[hutzlibu]

"the low level stuff is just conveniently hidden or abstracted away. "

Yes. This this is exactly what I want.

When I write an engine or framework, I will deal with low level stuff. But for basic tasks, I don't want to. But I have to, even where it would not be necessary.

"But the long textual code that makes the button work, eventually exists somewhere in there."

Also there exists even longer textual or even binary code that makes the code for the button work, etc. etc., but I still do not want to deal with it on a daily base. When I make an button, it should be as simple as possible.

Where is it positioned. How is it styled. Where is the onclick method to handle it. Those 3 things I want to do with simple clicks in the IDE.

Everything else is only distracting.

[Ygg2]

> Yes. This this is exactly what I want.

But the more abstract you go, the less efficient does your editor become. And speed of development goes down. It's not a simple - just put more abstraction.

[hutzlibu]

"It's not a simple - just put more abstraction."

Of course not. It is about the right level of abstraction.

Abstracting all the details away, I do not need to accomplish the task at hand.

If done right, this also will not slow things down, rather the opposite. Imagine programming a button in assembler and opengl. There you have all the details (and power). But chances are, you will be way slower and with a worse result, because you have to focus on other details and not on the task at hand.

[salawat]

Stop. Abstraction is not a magic pill that absolves you of the need to know wtf you are doing.

At best, it allows you to defer the deeper reading for a time. You might not even have to do the deeper reading for this piece of functionality, but the time will come when you have to figure out where an impedance mismatch is.

This quest for abstraction is the most infantile attitude I straw to squash in ever developer I meet. If you aren't reading the code that your code depends on to work, you have no idea what you're actually doing.

[hutzlibu]

"Stop. Abstraction is not a magic pill that absolves you of the need to know wtf you are doing."

Erm, a beginner who wants to place a button that calls his defined method foo, really does not need to know about all the framework details to get the job done.

When I was a beginner, I was happy that I could place a button and link it with whatever with ease and it worked!

I simply did not needed to know about event loops, rendering algorithms, or internals of the framework. Now I happen to know quite a lot about it, because I designed a UI framework from scratch to solve a custom need.

But most use cases with UI are to display text, images and give text input and buttons. Ordinary programmers should be able to do that, without having to learn the graphic stack. Thats why we have frameworks. They just could be easier with better tooling.

[barrysteve]

I've used UE4 for years and the Blueprints system doesn't save you much. Those abstractions are bricks, made for building brick houses. If you want to build something made out of anything other than brick, you're back to custom HLSL nodes and better off programming your shader somewhere else.

Blueprints are nicer for known problems, they are a better glue for old knowledge, but when you want to do something custom or new, you're out of luck.

This is the same problem with all programming, you can't make something specific and new without doing an engine teardown and rebuilding it. All the parts are terminally interconnected and always will be.

At the end of the day, UE4/5 is a landing pad for all the work you make in other tools. I agree web dev is no fun though.

[pjmlp]

Not wanting to pay for tooling is the major culprit.

One can pay for a CRM like Sitecore, AEM, low code like Outsystems, or enjoy the freedom of manually glueing HTML, JavaScript and JSS.