One of the things that always surprises me about Dart is that Google continued to invest in it for so long without any real returns until fairly recently. Dart came out in 2012 and to my knowledge had basically no usage for several years. Flutter came out in 2017, and then it took a decent amount of time to start picking up steam. Very uncharacteristic of Google to invest in something like Dart for 7+ years before it really started seeing any returns on the investment.

> but that's missing the point.

How is pointing out that you don't need the tools you hate and you can use the same kind of tools in the CLI as you would with any other framework missing the point?

You only need dart and flutter itself, and both of those can used via CLI just fine, I know because when I develop flutter I exclusively use my classic tmux+vim setup to do so.

If I want to create an android build I naturally also need the android SDK, but that is even packaged for Debian or Arch Linux, and even if I use the newest one directly from Google its just a one time setup, and that is completely unrelated to flutter (which I can test via the native or web build too) but 100% related with the build target (android in this case), so really not seeing your point.

I don't understand: I am using Flutter just fine from vim and I have never even tried their IDEs. What do you mean by "disable"? What "bloatware" were you forced to install in the first place, and how is it running?

"How is the market for "standard" apps doing? One would think that by now "UI for a Database/API" should have died out already? Even if companies do need an UI for a DB or an API, that job must have had become really simple with all the frameworks and libraries."

From my casual observation the learning curve for "UI for a Database/API" is becoming steeper every year. Such software reached its high point with VB6 or MS Access but since then simple tools have been dying and replaced with ever more complex frameworks. You still can't easily develop a web app that's as powerful and simple as you could do on the desktop with VB6 or MS Access.

In my experience there's always _something_ that isn't well supported by design tools. Some validation rule, some odd required relationship, a UI that isn't at all supported, and what is supported isn't at all liked by stakeholders. Half the app is legacy and still being migrated and this new widget depends on XX legacy component, etc.. I've personally observed 3 apps start as a GUI-based application, but by the time it shipped v1, and definitely v2, most of the app was hand-rolled.

Also in my experience, basically every company out there needs or wants an app. A web app, a phone app, a TV app, a tablet app.. internal apps, external apps, apps to gap 3rd party app integrations, they're fucking everywhere. A lot of these 'apps' are just web forms over CRUD data for one reason for another, but it's custom for some reason. And the reasons for why a GUI builder gets phased out also applies to why app-farm apps also get phased out of a company. Eventually, with enough success, having an internal dev team is just so much smoother than contracting or bridging the gap with excel spreadsheets. Someone has to wire things together, and eventually they get to fixing the root cause of inconsistency and a custom app is born.

I think we will have programming jobs for basic forms for a lot longer than any one of us would suspect, for a lot of reasons. But my last and most important thought is, once something becomes easy for anyone to do it becomes common. To stand out you need to be uncommon in some way, so there will always be space for people who can do what most others cannot.

The basic UI is the easy part.

Established companies have established company problems, complex flows that need to account for things like legacy deep links, A/B testing, UIs that go off the beaten path for brand identity, etc.

It all adds up to very little of a common denominator for all of these apps.

I've worked on some of the top apps in the play store for their respective categories, and if you saw their codebases your first thought would be "I could recreate this app in 1/10th this much code!".

After actually talking to all the stakeholders involved your second thought would be "I'm amazed this didn't take 10x the code!"

You would think so but no, in fact, such apps have been getting more numerous yet harder to make over time rather than what you'd expect.

Causes:

1. Web platform is very unproductive and hard to learn compared to what was available in the 90s. There's no widely accepted, robust and modern equivalent for Access, VB, etc. These tools were designed to be easy to learn. Smart business analysts could throw something together. It'd be a mess but you could graduate it into a "real" app, or something approximating that, without needing a rewrite. This culture is gone. No, the web is definitely not as easy. Think about how complicated just binding a DB table to a paging table view is. HTML doesn't do this, SQL queries can't even be serialized natively, so you end up needing a custom web server, a backend framework, a frontend framework, extra JS libs or widgets to give paging or scroll or fast updating search. Consider that with Access or FoxPro it could be almost all GUI driven.

2. Although a few complex requirements got simplified out by the march of tech (e.g. offline access, supporting downlevel browsers), mostly, enterprise requirements became more complex. Some of this is reasonable and legitimate, like integrating with SSO systems, mobile versions, better auditing, more beautiful UIs and elimination of scheduled maintenance periods. Some of it is of questionable legitimacy. A lot of CRUD apps become over-engineered because of CV-driven development. Does your internal app for the business really need to run on AWS Lambda for scaling reasons? No. It doesn't, because the traffic levels are predictable a long way into the future and a single dedicated machine can do what you need. Will you be able to find a developer who will actually admit that and throw together a simple Spring Boot or PHP app, instead of trying to Web Scale™ it up the wazoo? Maaaaybe.

3. Platform churn. Businesses don't like rewriting apps but from time to time they have to, because either they can't find anyone who knows the old tech anymore e.g. COBOL, or the platform goes out of support. So the same stuff gets rewritten again and again without underlying change in business requirements. Worse, these projects often fail and may need to be attempted multiple times.

4. Many of these "standard" apps are astoundingly complicated. "Regular UI" can involve complex and frequently changing UI designed to navigate large datasets. Is Facebook a "regular UI with a login form"? Well yeah but it's still a lot of work to build. Think about the complexity of Bloomberg terminals for example.

5. The idea that all business apps were written by 2000 already is false. Even today there are a shocking number of business processes that have little or no IT automation; they're still based on physical paper. I didn't believe it myself until I worked in the enterprise space for a while and saw it with my own eyes - there is still enormous business value that can be delivered from writing new "standard" apps. And of course, even once you get beyond paper the long tail of business processes that are automated using an unholy and unstable mix of nightmarish Excel macros, PDFs and executive assistants is more or less unlimited.

I think programmer salaries are partly being squeezed upwards by the fact that we've made the tech stack so difficult to learn. Have you ever watched someone try to learn programming from scratch, like at a bootcamp? I have. It's excruciating. I watched as they tried to teach someone who'd never coded before how to write a "standard" CRUD web app, using Ruby on Rails. Total failure. They were not even remotely in reach of the goal. To succeed with even a basic app they needed to learn about Ruby, SQL, HTML, HTTP, ORMs, JavaScript, JSON, CSS, and of course the UNIX fucking shell because even if you pay $$$$ to Heroku to simplify deployment, it's all driven by a CLI anyway!

Back in the 90s one reason Microsoft won was that they managed to hide the complexity of their underlying platform with beginner friendly languages and tools. When Windows programming starting sliding into irrelevance and they dropped VB to try and compete with Java, we made the on-ramp way steeper.

On the other hand, it is like using Flutter, JVM, iOS/macOS, Web browser without additional tooling, IDE plugins, FFI debugging issues or having to add layers of idiomatic libraries.

If JavaScript ever gets replaced, that will be by embracing TypeScript's gradual typing.