4 ms·

>Flutter still has its quirks, but hands down, it's the best platform for the majority of "standard" apps How is the market for "standard" apps doing? One woul

by mrtksn 5y ago

>Flutter still has its quirks, but hands down, it's the best platform for the majority of "standard" apps 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. On Twitter I keep seeing people building the millionth water tracking app, so I guess there's still market for everything but I feel like "Coding regular UI with a login form and stuff" kind of jobs must be vanishing, aren't they? Surely design tools must be able to extract functioning UI's or a bit of coding know how should be able to enable anyone put together a decent UI using components libraries?

spaetzleesser 5y ago
"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.
- doo_daa 5y ago
  I completely agree. It's amazing to me that MS Access is still probably the best rapid application development tool ever made. There's just nothing like it that works for the web.
BoorishBears 5y ago
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!"
- mrtksn 5y ago
  Oh sure, all good points. However in such cases React vs Flutter is not the part of the discussion at all because they tend to have so much investment that re-do is almost not an option. Bespoke tools, integrations, accommodations for odd behaviours or bugs etc. are huge costs. So many horror stories of failed re-do's. I was thinking about greenfield projects.
titusjohnson 5y ago
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.
native_samples 5y ago
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.

by mrtksn 5y ago

spaetzleesser 5y ago

"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.

doo_daa 5y ago
I completely agree. It's amazing to me that MS Access is still probably the best rapid application development tool ever made. There's just nothing like it that works for the web.

BoorishBears 5y ago

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!"

mrtksn 5y ago
Oh sure, all good points. However in such cases React vs Flutter is not the part of the discussion at all because they tend to have so much investment that re-do is almost not an option. Bespoke tools, integrations, accommodations for odd behaviours or bugs etc. are huge costs. So many horror stories of failed re-do's. I was thinking about greenfield projects.

titusjohnson 5y ago

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.

native_samples 5y ago

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.