
Ask HN: Why Isn't the Construction of CRUD Web UIs 90% Automated? - davidjnelson
It seems silly to write the same types of code over and over to build CRUD web user interfaces.  There have of course been hundreds of UI builders.  Why aren&#x27;t they used?  Styling should just use plain CSS.  Behavior should be mostly auto generated config from a standardized format such as json schema or a db schema.  Behavior customizability should come from tweaking the auto generated json config, and adding some HTML and JavaScript to higher order components.  The build targets should use plugins, starting with angular and react.  Components should use a shared plugin infrastructure.  Designers should be able to prototype in an invision like tool with real CSS and HTML that can be checked into source control.  Why isn&#x27;t this the way things are done?
======
jasonkester
I suppose a better question is "Why aren't you using a framework that
automates 90% of your CRUD?"

There are lots of those. Rails is the obvious one to point to, but there are
dozens of others built in the late 00's that all tried to recreate that "20
minute DB-Backed Blog" demo.

I imagine the answer (to my question, and thus yours) is that fashion changed.
Everybody wants to build Single Page Apps today. For everything. Even when it
makes no sense whatsoever to do so.

So you find yourself dragging in a few megabytes of javascript just to render
your static blog page. And you have all the power that made sense for the
engineers at Facebook to use on their newsfeed, where things would regularly
change behind the scenes and the page needed to re-render and re-flow itself
several times a minute without the user noticing, for which a brief 3 second
"flash of empty container" was a reasonable trade-off. And you use none of
that power on your page, but you have it there in reserve, just in case.
Because that's what The Trend has told you to do.

Step back and build some pieces of your site with tools that can look at your
database and spit out some sensible defaults for CRUD screens, shamefully pre-
rendered on the server as they may be, for the pieces where it makes sense to
do so.

~~~
LargeWu
Tell me about it. I'm currently working in a javascript shop where we recently
finished a 4 month react project with 5-6 full time developers. The website
had about 10 pages, with about half a dozen forms, all but one of which were
very straightforward, and not a ton of fancy UI.

As an experienced Rails developer, I could have built the whole thing myself
in about a month and a half. Less if the html was provided. There was
absolutely no reason to build this thing in React. But, the architect and lead
dev have decided we're a javascript shop, damn the torpedoes. For certain
things we do it makes some sense, but mostly it just slows things down and
makes development unpleasant.

~~~
dabockster
Currently working in a Wordpress shop. I feel your pain. Because the client
_might_ want to blog in the future, so we build everything in Wordpress with
this one theme based in ZURB Foundation developed by one guy that incorporates
its own build system in Gulp for Sass that breaks the Wordpress theme engine
if you don't have the files in the right places.

Ugh.

------
saltedmd5
The truth is that the construction of CRUD web UIs _is_ 90% automated.

The web and storage frameworks do the vast majority of the heavy lifting - the
application code is really just simple wiring and validation.

The trouble is that (in my experience, at least) many web shops and web
developers enormously overcomplicate that application code; shoehorning
enterprise "layering" into simple components, creating poor - and often
unnecessary - abstraction. These things lead to grossly over-engineered
solutions with bloated code and control flow flying all over the place.

So the reality is that what can be automated largely is already - we are just,
by and large, pretty bad at doing the bit that isn't.

~~~
staticelf
One can compare it to any other product in the real world. Just think about
cars. Every car is about the same nowadays, many uses the same parts under the
hood. But still, every car has different functions, different designs and
slightly different placement of things UI-wise.

This is the state of the development world as well. It is like this because
not everyone wants the same generic model and every company has to stick out
in some way.

~~~
matt_s
The thing about cars, or any real-world comparison, is that software is always
changeable. Its hard to change manufacturing lines over a new design for cars,
thats why they have designs out there for years at a time.

I think the vast majority of our time isn't wiring a UI to CRUD actions, its
dealing with the complexities of whatever business domain the CRUD app is
intended.

~~~
shubb
It's also worth pointing out that the design cost of a new model of car (which
is equivalent to a new VERSION of an existing software product) is at least 1
billion dollars.

If a really good big crud app costs 100k on upwork is more similar to
remodelling an office. In many ways.

[http://bramaindustries.com/wp-
content/uploads/2015/05/office...](http://bramaindustries.com/wp-
content/uploads/2015/05/officeremodelling01-1000x600.jpeg)

------
adrianratnapala
This is a very good question because it gets into a deeper issue that I find
in all corners of real world programming and results in large complicated
applications even when they use powerful frameworks.

Real-world programming is absolutely _choc full_ of things that look like
simple applications of a well known solutions, but which turn out to need lots
of special-snowflake code to actually implement. Part of this is unforced
errors, but usually I can't look at other people's work and say _in detail_
how I would have done it substantially better.

So I think there is something fundamental going on. One guess is that although
we can write tools that automate the perfectly common case, we are not good at
writing things that smooth the inevitable app-specific corner case.

~~~
buro9
A really good example of this could be validation.

Almost every CRUD app builder includes the ability to validate fields and
properties, and this would appear to be sufficient for nearly all scenarios
except it is not.

I can not name a single CRUD app that I have built that didn't require multi-
field validation... i.e. start date prior to end date, time must be completed
if date is filled in, if this part of the form is filled in then that part
must be blank.

Without this capability to really express the application business logic, the
technical simplification fails short.

~~~
adrianratnapala
The existence of multi-field validation is a sign that your app can't really
get a way with an "anemic" domain model -- i.e. the app is not just a front-
end to the DB.

What's really going on here is that you have a domain object with some
nontrivial invariant. It's a mistake for the UI or anything that is aware of
the UI library to try to model these domain invariants. Instead a call should
go the model layer which then returns (or throws) an error providing enough
info for the UI to gracefully help the user.

The UI framework can play an important role in this: but that role is to help
programmers provide a UI for the validator that lives in a model layer. It is
not to do the validation itself. (Although frameworks should provoide an
arsenal of simple, single field validators, of the "this field has data-type
phone-number" kind).

~~~
buro9
Sure, I don't disagree.

But for the current state of CRUD application frameworks that do not do this,
it implies some enforcement at the data layer and probably some hint at this
at the ORM level. This really does not exist in any sufficient way.

It reminds me of the idea that a graph/diagram generator that used some
generic data source could be a common analytics tool, and that with a few
well-defined defaults no-one would need to run lots of different analytics
tools, or they could be generated automatically and would be good enough.

In reality they never are good enough. There is no one-size-fits-all analytics
system because the KPIs differ from company to company, project to project,
and these differences go all the way down.

Sometimes we see something being sold as a "this is all you need", i.e. a SAP
solution or some generic tooling, even Stripe, etc. But the level of
customisation typically required to make it sufficient for a mature
organisation to use it is typically quite high.

A strategy to resolve this usually is: Change the org to fit the tech, rather
than the tech to fit the org. But I've seen this fail consistently as
typically the tech is too simplistic.

Then there's the "customise it to fit your needs", but going back to custom
multi-field validation, or analytics... the number of permutations of logic is
immense and the customisation tools themselves only allow simple expression of
that customisation.

The end conclusion is that we need extreme levels of customisation, but when
provided through tooling the effort to perform and manage the customisation
(with auditing of who changed what, when, etc) is such that actually it is
simpler and cheaper to write the customisation in code.

~~~
davidjnelson
We absolutely should write the customization in code.

------
zokier
Have you considered that maybe CRUD application building is actually already
90% automated, and the things you discuss are the remaining 10%?

~~~
yen223
Hah, good point. Be thankful we don't need to rewrite an ACID data store
everytime we need a crud app

~~~
brianwawok
Count how many datastores you can use right now. I bet we could find 200
active data stores.

------
edanm
The most famous article on this topic is called "No Silver Bullet". It
basically answers this question: split up the work you need to do into
"essential complexity", which is specifying in minute detail exactly what you
want your app to do, and "accidental complexity", which is all the programming
work around that to get it done. The "essential complexity" is still most of
the work.

Thought experiment: If I gave you a programming environment in which you just
said, out loud, exactly what you wanted to have happen, and there was no
programming, it just happened, how fast could you build a CRUD app?
Significantly faster, true, but there'd still be tons you need to specify,
just because you want something that does something specific.

If you want an example of something that that _is_ fully automated, think of a
Facebook page. You can build it in seconds, but you're sacrificing _tons_ of
customizability. In terms of our thought experiment, this is like saying "make
my app exactly like that". It's _very_ efficient, but lacks most
customizability.

~~~
alexasmyths
I'm not sure I agree.

The essential complexity usually isn't that hard.

From a high level view - most apps are _basic_.

Even a second order articulation of function i.e. 'screen here, buttons here,
images here, button does this' etc. is not that hard.

Below that, it's kind of a mess.

The byzantine tools we have (I'm talking to you HTML/CSS/JS), to complete the
task engender a massive amount of 'arbitrary complexity' and make doing
anything really quite hard.

Which is why, by the way - once you have a Dev that becomes 'really familiar'
with a 'specific stack' \- they can move really quite quickly.

But most of the tools we have are a mess, and they keep changing, hence, all
the complexity in our systems - which grows exponentially across more and more
developers until you have any number of very smart people all trying to paint
a Picasso at the same time.

FYI - I believe that making an app shouldn't be that-that much more
complicated than making an FB page.

There isn't really a lot of 'essential complexity' in most apps, I think.

~~~
jstimpfle
I agree to some extent, but I wonder if you actually tackled a web project of
more-than-trivial complexity?

I did, and tried to find a number of good abstractions (for example,
generating UI / ORM according to data structures), but in the end didn't come
up with something satisfying. It's too easy to paint yourself into a corner.

In my opinion one of the big sources of essential complexity is the layering.
You have representations of your data in the DOM, in Javascript objects, in
HTTP bodies / URLs, in server-side plain text representations, in the server-
side language's objects, in the database... And strictly speaking you have to
make sure (de)serialization works and data integrity holds at each of these
boundaries. Also, many functional parts need to be present in more than one of
these domains.

~~~
alexasmyths
I've worked on big and small.

Even for the 'big ones' the (there were network management apps) - the
'business logic' (networking logic in this case) - was not rocket science in
the end.

As you indicated, not only is the 'layering' a pain, but often there's a whole
set of technologies and toolchains at each layer!

Even just starting with 'identity' for a web app, i.e. Facebook and Twitter
integration along with basic credentials - can be a big pain.

------
pavlov
It's not too easy. I've worked on one such app, React Studio:

[https://reactstudio.com](https://reactstudio.com)

It's maybe 80-90% of the way there, depending on what you need. Closing the
gap feels demoralizingly hard with no resources (I'm spending time on it
unpaid).

The design environment is quite complete, although it doesn't even try to
expose all of CSS -- instead it's more like a "walled garden" of the parts
that make sense for mobile-first designs.

I'm most proud of the exported code's quality (no extra junk, no giant library
hanging around) and also the component and plugin architecture. You can either
design React components visually or import them from code (e.g. an npm
package), and both will work the same within a design.

The fundamental problem is that the technological foundation for web apps is
so unsuitable, like building a house on quicksand using decayed planks. CSS is
a cruel joke with its thousands of properties, their decades of cruft and
their unpredictable interactions. HTML was designed for documents, then was
semi-accidentally turned into a view layer, but it never adopted any of the
learnings from the successful '90s GUI desktop frameworks. Some of that
missing structure has been added back by efforts like Angular and React (and
the latter is fine to my taste), but it's just really frustrating that web
front-end development is still stuck endlessly patching over a rat's nest of
<div>s into something that resembles actual UIs. But what can you do? It's not
like browsers are going to add a real app framework. So here we are, still
trying to decide whether buttons should be <a> or maybe <input> elements.
Sigh.

~~~
copperx
There are two reasons we're here:

1) For the end user, it's too hard to download and run an app. 2) For the
developer, it's hard to create an acceptable multiplatform app.

~~~
TheCowboy
And platforms can be moving targets. New platforms are introduced and adopted,
along with new ways to interact with them.

The platforms can also change and break applications in unpredictable ways.
For example, iOS 11 won't run 32-bit applications.

~~~
aminorex
I think what you mean is that Apple platforms will change and break
applications in unpredictable ways.

------
koliber
The issue is that each piece of customized functionality is different. It also
changes through time. Much of the functionality is standardized. Many of the
places where customization is expected, hooks are built into frameworks to
allow easy extending.

Designers come up with new rules that do not fit into the mold that the
"automated" tool offers. For example, tool tips that appear only if the ? key
is pressed on the keyboard before hovering. Custom code is needed.

The customer decides that they don't like the ordering, content, or display of
the timezone field. Custom code is needed.

The law changes and it in addition to "Male" and "Female", additional values
are required for the gender field. Custom code is needed.

Country XYZ decides that your software cannot be used as is because the
country dropdown contains Fakeystan. Country XYZ considers it part of its
territoy. Custom code is needed.

There are analogous situations in the real world. However, they are
encountered less often as we got used to accepting the standard offerings that
are available. True customization is rare. When we build a custom house, most
of us decide between one of the handful of standard options that are available
on the market. Picking and installing a standard toilet with one of the myriad
toilet seats available in the store is easy. But wait until your you get asked
to install a plus-sized purple Italian marble bowl with a faux-fur seat that
is anti-bacterial, easy to clean, and doubles as a floatation device. These
are the problems we are dealing with building software every day.

------
gwbas1c
Because then you could only build very simple applications where your data
model was extremely tightly bound to your application and user flows.

Once you need to do things that require pulling from many DB tables and rows
in your views; enforce complicated logic about who can see what; and enforce
complicated logic about who can do what, the automation will get in the way.

The thing with manually writing SQL queries and data access code is that it
doesn't take as much time as you think it takes. The problem with tools that
automate this is that they can be buggy, or have a steep learning curve in
order to generate a reliable and high-performance program. SQL queries and
data access code is very straightforward and easy for the next guy on the
project to maintain.

With the hidden cost of learning, debugging, or working around flaws of
automated CRUD systems, it's easier to just take an extra few hours, or few
days, to "do it right," at the beginning of a project. Otherwise, you risk
spending many days trying to work around problems in your framework.

But, think about it this way:

\- Ruby on Rails is popular because can build an entire CRUD web application
around a basic schema / data model. You start with your CRUD fully running and
enhance from there. Most of your time is spent enforcing your business rules
and making it look pretty; (or working around the fundamental performance
issues that come with such an environment.)

\- Excel is popular when the user doesn't need the UI. Very complicated
business processes live in Excel spreadsheets. So, if your use case is so
simple that an application could be auto-generated, Excel might be "good
enough" instead.

------
ronjouch
What if it _is_ 90% automated? As other pointed out, see Django REST
Framework, Rails, Elixir, Scala Play, and enterprisey frameworks like SAP,
Odoo, JDEdwards, Oracle Whatever™, ENOVIA, Windchill, etc.

Those tools/frameworks cater for the _accidental complexity_ of "writing CRUD
stuff". Remains the _essential complexity_ of what makes your app what it is.
The business logic for YourBusiness is not Uber's, is not Greenpeace's, is not
Pfizer's, is not Ford's. The logic may be mundane, but that doesn't change
there's nothing _" natural"_ to it, so it has to be expressed, and that's what
we do using code and the tools at hand.

As for the percentages: sometimes it's gory and you do everything by hand
(where you manually and painstakingly write yourself 50% of this non-
essential, non-value-added 90% accidental complexity due to lack of tooling),
then by all means go grab a few shiny shiny tools for the next project, and
some other times you do have tooling to cover these 90%; remain questions to
be asked to your users, specs to derive, and code to write.

~~~
lawik
I'm guessing you mean Phoenix where you wrote Elixir. But yeah, I immediately
thought of these frameworks and how fast you can get from zero to CRUD API
with them. Phoenix definitely felt 90% automated, Django and DRF had some
extra glue-work last time I set them up. Not sure about now.

Anyone tried API Star by Tom Christie? Seems pretty interesting and relevant:
[https://github.com/encode/apistar](https://github.com/encode/apistar)

------
Illniyar
It used to be, back before SPAs were common, about 7-10 years ago.

Rails, django, asp.net mvc - all of them had autogenerated most code,
including html, handled auth, persistance and such.

Even now if you don't go spa it's very common.

Spa changed things considerably and the stacks haven't caught up in maturity
yet. But we are on the way there, especially node.js and react based stacks.

~~~
sampl
Firebase is doing most of this for SPAs: auth is standard, data persistence is
done with declarative rules (basically no written backend), and using Create
React App for views handles most other things.

I’m actually working on a boilerplate now to show how simple dev can be with
these tools:

[http://getfirefly.org/](http://getfirefly.org/)

~~~
Illniyar
I love the idea behind firebase, but it's just not worth it unless they have
triggers - even the simplest functionality is extremely hard without pre-
persist triggers.

~~~
sampl
Could you tell me a little more about what that means? Would like to hear what
I’m missing out on.

Possibly relevant: [https://firebase.google.com/docs/functions/firestore-
events](https://firebase.google.com/docs/functions/firestore-events)

~~~
Illniyar
These are async functions - which means they happen after the data is already
in the database. They basically act like a producer/consumer pipeline.

Triggers happen before the data is saved - which lets you change the request
(or other data in the db) before it is saved or abort the request.

Without it even trivial operations become hard - such as add a column from
other places in the database, incermenting counters/cached aggregates,
authorization that isn't role/access based, etc...

~~~
sampl
Ah, gotcha. I think I’ve been getting by with Firebase transactions for
counters and db rules for complex authorization. Firebase doesn’t have
columns.

Can you share a specific use case that’s difficult to accomplish in FB?

------
artpar
I have been working towards this goal since the last 5-6 months. Some
documentation is up here at:

[http://docs.dapt.in](http://docs.dapt.in)

Source: [https://github.com/artpar/daptin/](https://github.com/artpar/daptin/)

The CRUD api is based on JSONAPI.org standard to make use of their available
clients
([http://jsonapi.org/implementations/](http://jsonapi.org/implementations/))

For the UI part, there are multiple things in place

1\. First, upload via ZIP to one of the storage backends ( rclone is plugged
in so storage backend could be anything from gdrive to local file system)

2\. Grapes JS for UI drag and drop designer after you have uploaded
([http://grapesjs.com](http://grapesjs.com))

3\. A detailed authorisation framework to control entity level and row level
access

4\. Actions and Outcome chains with complete JS support to handle business
logic (for example the signup/signin flow is a set of actions)

ps: earlier i used to call it "goms". recently renamed it to daptin. Also, not
focusing on other parts of daptin to keep this short.

------
throwawayknecht
> Why Isn't the Construction of CRUD Web UI's 90% Automated?

It is, several times over.

Using SQL or some other domain-specific query language against structured
records? That's the first 90%. HTTP and hypertext? That's the next 90%. CSS
and modern HTML authoring? Another 90%. Web app framework with an ORM and MVC
/ data binding / reactive / flavor of the month? Another 90%.

Your mistake is assuming that automating 90% of it reduces the work by 90%,
rather than letting you spend 10x as much time on making the bespoke parts
fancier.

~~~
davidjnelson
Not quite sure I follow. I'm just thinking about how to deliver value to users
faster.

------
konschubert
I think you're asking the right questions. And it's possible that you're onto
something. But consider this:

Often the way the data is represented in the DB is very different from how a
user thinks about the data in a given context. And another user, in a
different context, might again think very differently about it.

So you need a lot more configuration for the input data than you might think
at a first glance.

Lastly, there are good frameworks already that do a big part of the work.

Django for Python is one that I'm very familiar with. If you combine it with
vue.js and bootstrap on the front end, it's very quick to create a working
MVP.

------
paskster
It seems that folks at HN look down on so called "CRUD" apps. But the truth
for most CRUD apps is, that a lot of thought went into building these apps and
they have a lot of important parts, whose construction cannot easily be
automized. Good examples are:

\- Certain inputs might trigger other actions (integrity checks, sending an
email, notifying another users, etc.)

\- The UI / UX needs to be optimized for the specific Usecase of the app

\- There are unlimited options for filtering or ordering items, and the choice
of options depends on the specific Usecase

\- A lot of apps need Cronjobs in the background to support certain workflows
(notifying a user if a certain input has not been done in a certain time)

\- There can be rather complex rules on who is allowed to create, update,
delete or view certain items

\- AB tests and Analytics need to be supported for a lot of Tasks / Views

\- etc...

I cannot imagine a "CRUD" framework, that supports all of these issues. It
would basically just be another programming language ;)

------
AdamJacobMuller
1000% agreed.

I've actually written something (not open source) that largely solves this
problem for myself and my company, but, its a very hard problem to solve in
general. The largest benefit that I find from it is that it allows you to make
some things that would done directly (EG: UPDATE statements) be by a web UI.
Figure if you had a particular table that only got updated once or twice a
year, is it worth it to write a bunch of CRUD code for that? No. Is it worth
it to write 20-ish lines of JSON to describe the table and avoid a bunch of
problems that direct DB updates cause (accidentally hit enter before I typed
where on that update, no tracking on who makes what change when)? Yes.

Has a lot of benefits. I understand its a hard problem, I don't understand why
no one (aside from perhaps django-admin which I find too obtuse) has tackled.

I may rewrite existing code to golang (PHP now) and open source it at some
point in the future.

~~~
copperx
I love the premise of Wavemaker: Write your CRUD app visually, and add your
sprinkles of business logic with Java or Javascript. It's a shame it's closed
source and incredibly expensive ($250/mo in the cheapest tier).

------
ransom1538
I never understand when people wish to build a site they must implement the
login page. There really is no page like the login page. It should be as
standardized as it gets. If you were doing a site in rails some poor nob is
going to sit there and code the password and login logic - sure there are gems
but they aren't maintained or don't work with your hipster react plugins. You
could whip out drupal/Joomla!/wordpress have everything done for you - and
worry about skinning and which plugins to add. But that would be in php - and
using php is the technical equivalent of being called a child molester. So
where ever you go, whatever new company you work for - some tool wrote their
own login page. lion king Hakuna Matata.

------
dreamfactored
Business logic. +if you only look at the data side, most business objects
don't have the same shape as database rows, yet most CRUD programming is
tightly bound to table representation.

~~~
davidjnelson
You could do the transformation before it hits the ui, and for ui specific
business logic, call into it from the higher order components that wrap the
common components provided by the community.

~~~
dreamfactored
This is the job of a model. Say I want to manage videos and their rights as
they relate to territory, time, and user; or I want to create contracts
between my customers and financial exchanges allowing them to access specific
data feeds, each with its own additional contract, regional and volume usage
limits, and SLA's. And these are synthetic simplified examples I just pulled
out of the air - real life is way more intricate. Let's not even get into
multilingual and versioning for audit trails.

What I don't want to care about is storage implementation to implement those
models in a given channel/client. If that starts leaking through the model
abstraction layer into implementation, my business rules aren't testable, I
can't change backends to scale without rewriting all my implementations, all
of which are going to be bug-ridden and spaghettified.

The fact that we would even describe storage as a transformation (as if it was
just a mapping with some consistency rules), should flag up how brittle such
an approach is going to be. No wonder it is so painful for businesses to make
any changes to their systems.

Now having said that there are many simple cases that do map well to a table.
Those are already managed directly by businesses without the assistance of
developers - in spreadsheets.

------
rusk
I had a client ask me this not so long ago.

So I went through their requirements and separated the "mere CRUD" from all
the frilly extras, novel integrations and look and feel requirements, as well
as translating their actual business requirements into the "CRUD space".

The mere CRUD bit was very much a minority of the work that was required.

------
tmzt
Great question.

So I'm kind of obsessed with this problem, believing that programmers in our
society could be dedicated to much more than building the same application
over and over again.

If your page is a listing of items (could be e-commerce, could be a listing of
users in an internal application), it's really just a fancy way of saying
List<T>.

At the same time I know that some things can't be automated well and still
require translation from spec to layout. Some flexibility is required.

However, there can be a starting point which can be built up from. Then
components can be defined for things that need more definition, that need a
well-designed UX or specifically tailored user interaction design.

Where I am now is a small template language that also contains the definition
of a reducer-based dispatch mechanism.

I am close to having TodoMVC implemented in about 80 lines of this scripting
language, which can be compiled to javascript using any number of frameworks
or libraries, but can also be used to serve a functional site with the HTML
pre-generated which can then be hydrated with client-side javascript. This is
all done without using server-side javascript.

I have designed it to be usable by someone without an ML background, someone
who doesn't fully grok monads or lift.

It is mostly imperative with a functional pipeline/filter construction in
places.

You can see an older version of the code and a static demo here:

[https://tmzt.github.io/isymtope/](https://tmzt.github.io/isymtope/)

You can also see where it's going:

[https://github.com/tmzt/isymtope/blob/feature-
querylens/res/...](https://github.com/tmzt/isymtope/blob/feature-
querylens/res/tests/app/todomvc/app.ism)

[https://raw.githubusercontent.com/tmzt/isymtope/feature-
quer...](https://raw.githubusercontent.com/tmzt/isymtope/feature-
querylens/site/src/assets/demo/app-mvc.html)

------
inerte
I think Django's admin interface fits what you want (except maybe the
invision-like tool for design prototype)

~~~
konschubert
I have some experience with the Django admin and I think it is actually a good
illustration why user interfaces are still complex:

Because the way we abstract our data in the database is often very different
to how we think about the date in a specific context.

------
mcv
It is indeed silly to write the same type of code over and over, and that's
why people automated it 10 years ago. This is exactly why Rails made such an
impact; it automated the boring stuff, and I think Rails does pretty much
everything you mention. And what Rails did for Ruby, Django then did for
Python, Grails for Groovy, etc. I suspect there's a framework like this for
every language out there.

Of course some websites need something different than CRUD, and especially
with the modern trend of SPAs talking to JSON APIs, not everybody needs a
simple CRUD website, which is why there are also lots of other frameworks. But
if you quickly need a simple CRUD site, the tools still exist.

If those tools are not good enough, then build on them and make something
better. There's always room for improvement. But the thing you're asking about
has existed for 10 years now.

------
callmeed
I take it you've never used Rails' scaffold generator ... it does much of what
you speak of (db schema, basic html/css forms, etc.)

~~~
copperx
Sure, but going from there to doing simple stuff (e.g., handling a file
upload, authorization, client-side validation, client-side form modification
[e.g., make a selection on this dropdown and this other dropdown changes],
making the app multi-tenant) requires a lot of additional code, which should,
IMHO, be part of the framework.

~~~
tmzt
Hmm, ask Equifax how simple file upload is.

It's actually a pretty complex problem to solve securely, leading to scripts
that try to support every configuration including off-the-shelf PHP hosting.

An ideal would be something like S3 where invariants like size, type, file
format could be verified at time of upload and then exposed in on-demand
manner to the rest of the application.

------
somya
This is what we have so far: [https://varick.io/](https://varick.io/)

We make a ton of MVP apps, and what you're talking about would be amazing! But
the reality is we'd never get close to it. Every app focusses on a different
audience. We aim to help them reach their unique goal as quickly as possible,
which inevitably means a different UI approach for each scenario. It's not
worth the effort in trying to automate.

Instead, we focussed on a generating a front-end for admins. It works with
APIs so any business logic and security validation is just baked in cannot be
by-passed.

------
petra
There's a new big trend in tools for enterprize(and a bit of consumer) web
dev, called low-code/no-code. those tools offer that level of automation, plus
much lower barriers to implementation(mostly via visual interfaces), and it
seems (but i may be wrong), that they can be used to built complex
systems(often by software guys, complexity reduction and order is still
important).

But those are almost never mentioned in hacker news, which may say something
about our community more than it says something about the possibility of
building such tools.

~~~
davidjnelson
Oh cool, do you know the names of them?

~~~
petra
[https://www.pcmag.com/roundup/353252/the-best-low-code-
devel...](https://www.pcmag.com/roundup/353252/the-best-low-code-development-
platforms)

------
captainmuon
The same applies to mobile. 80% or so of mobile apps are just listviews with a
JSON backend. Why do I have to write a list adapter, syncronization logic,
lifecycle management etc. again for each app?

Ideally, you should be able to say "Here is my schema, gimme a listview, keep
it up to date. Here is a template for the list item, here one for the details
view." Make everything declarative. One crucial point is to then make it easy
to tweak everything - often abstractions make simple things easy, but slightly
less simple things very hard. Once you want to do something more complicated,
like having an animation transition from one view to another, you shouldn't
have to abandon the framework, but should be able to drop to native code.

And yes, on the web we have Django, Rails, etc.. But I still have a lot of
repetitive work to do. Why isn't there something like the Django admin which
is more suited to _users_ than _administrators_ (I'm sure there is, but it is
not mainstream). Let me define my schema, press a button, and I have an ugly
CRUD app. Then add constraints and business rules, and pretty templates one by
one. Something like, I don't know, SAP or MS Access - a glorified DB browser
which you can customize a lot. Add in a graphical designer so you can let an
intern create new forms and tables.

------
jamesmcintyre
I seem to never find areas with which this quote doesn't apply: "We shape our
tools, thereafter they shape us."

In short I think web developers build with the tools they know are capable of
delivering a spec but this does not necessarily mean those tools are the only
capable tools for some inherently unchangeable reason.

If some tool comes along that can allow devs to scaffold out 90% of a complex
web app without sacrificing fine-grained control for the remaining 10% it
could be a winner. In my mind, however, this tool would also have to weave
itself into scalable practices like git workflow, modularity so many devs can
simultaneously work on one app, etc.

I think the reason there have been so many attempts at such a tool without
great success is that engineers building such a tool quickly bump up against a
multi-layered, exponentially complex universe of edge-cases and to tame that
complexity alone likely requires an enormous amount of careful, considerate
and cohesive decision-making. And once you throw in the fact that any startup
will be asked to deliver an MVP ASAP you start to see why the odds are stacked
against such a disciplined approach.

Where I work the codebase is massive, 100's and 100's of internal modules all
working together in many "sub-apps" with teams all across the world. One task
was to add a field to a form and it took 5 engineers across 4 teams 2 weeks to
even get it in a testing stage. Maybe an app this size is not the best target
for such a tool but if it were it'd have to account the massive operational
complexity as well, the human processes at scale.

------
FLUX-YOU
This has been a thing with ASP.NET/Web Forms within Visual Studio for a while
(C# or VB.NET)

Since the views can be composed with a master view, the actual code generated
is just a table element with a loop to add the rows/cells.

Although the view model is usually a plain C# class object, those objects can
be generated from looking at the DB schema, meaning you only have a two-step
process.

You could generalize it to make a table for any C# object using reflection,
but that's kind of abusive IMO.

~~~
davidjnelson
I haven't used web forms or asp.net mvc in a while. Do they output react or
angular now? Do they not require a .net backend? Those are hard requirements
for a lot of teams.

~~~
FLUX-YOU
They can certainly work with Angular/React. There's templates to get started
with that. It would be a .NET backend, but a .NET backend isn't exclusive to
Windows any more with .NET Core and related Docker images.

------
seyz
2 years ago, I had exactly the same question, especially for the internal
tools (e.g. the admin interface). Some frameworks (like Loopback in Node.js)
have the ability to generate the CRUD API automatically based on your data
schema. The downside is the way to customize it. IMHO, it's not
"easy"/"developer-friendly" enough to convince me. Back to the admin interface
topic, there're also many tools (ActiveAdmin, Django Admin, Sonata, etc.) that
automatically generate the CRUD interface. It reduces a lot the maintenance,
but one more time, customization is limited, DSLs are just ugly and they are
not SPA :( I never understood why it's not simply based on an API.

This is why I've started Forest Admin
([https://www.forestadmin.com](https://www.forestadmin.com)). It's an open-
source library you install into your app. It automatically generates the REST
API based on your data models and it covers 90% of admin operations (CRUD,
analytics, etc.) and let developers customize the logic (custom actions,
computed fields, complex workflows, etc.) without learning a complex DSL. In
addition, we also provide to business team a customizable UI as a SaaS.

------
richev
Because developers & designers prefer to have control over their HTML, and
HTML really isn't that hard.

Any attempt to create a true multi-purpose UI builder for web applications has
resulted in something more complex and hard to use than the problem it was
trying to solve.

Case study:

Rewind 10-15 years and Microsoft's ASP.NET WebForms was popular (subjective
use of "popular", I know), and was designed to give pretty much what you are
asking for. It really did work and was great in many ways.

However, it achieved this was at the cost of a _lot_ of proprietary complexity
(search for "ViewState" or "ASP.NET page lifecycle"), which over time became
burdensome. Then AJAX came along, and WebForms was updated to achieve this but
with even more complexity (search "ASP.NET leaky abstraction").

I was using ASP.NET WebForms extensively around this time and we found
ourselves increasingly "fighting" the framework, trying to bend it to suit our
specific requirements (which weren't all that radical). Also, our design team
started delivering their work in the form of HTML and CSS, which was a
nightmare to integrated with WebForms as it dictates the exact HTML that is
used at the UI control level.

Then we moved over to an MVC framework, and were enlightened...

~~~
davidjnelson
Right, I used webforms back in 2002-2005 as well. Not the best experience.

I am talking about modern single page applications that leverage
xmlhttprequest and common frameworks such as react and angular.

~~~
cm2187
Removing the viewstate and using more ajax are merely a modernisation of
webforms. Fundamentally you are calling for what webforms was actually doing,
ie generating a UI, binding it to a database and dealing with the boiler plate
code in between.

The problem with these all-in frameworks is that they are very good at giving
you a fully functional and OK looking app in a few clicks. But from there they
work against you. You don't want to expose everything in the database to the
user, or you want to include some custom validation logic, or you are dealing
with some data that is partially normalised, or you are mixing SQL and noSQL
data, etc. And then you are fighting the framework to hack something together
that the designers didn't intend. And after a few years you realise it is less
work to do it yourself with a bunch of helper methods.

------
elnygren
I think there are two answers here that also point out a couple things about
the question & its framing:

1) Because almost no project is just CRUD Web UIs.

There are always so many small and big details that deviate from the CRUD
Model. Unless you're building a Database UI. Which almost nobody wants as
people want software that solves their real world problems - which rarely map
1:1 to a DB and it's schema.

IMHO frameworks that optimise the CRUD sacrifice a lot with regards to
simplicity.

2) Plain CRUD Web UI _is_ 90% automated, BUT: see item 1.

Rails and Django will handle almost everything hard for you and you just need
to declare some trivial stuff like the model, url and presentation. The reason
why you end up coding so much even in a Rails/Django project is because item
1.

Also, Rails and Django are definitely frameworks that sacrifice a lot in order
to show off an easy basic CRUD setup. Both have ton of horrible OOP and
metaprogramming under the hood and you'll have a tough time understanding what
they do and how.

That being said, I've worked with both and I do like them, especially Django.

------
erikb
Simply put, because it's much quicker to write it from scratch each time. A
good developer will spend time to learn all the little things like how to make
a table, how to store data savely, etc. And he will add these features as
needed, and in a form that matches well with what the other pieces will be. It
is really normal once you've hit that level of skill in one area in your life.
It can be something totally else entirely.

One could also ask why a painter doesn't use puzzle pieces instead of drawing
each picture from scratch. Sure, it would make him finish much quicker, but it
doesn't give him the level of detail he needs. And if you make these puzzle
pieces small and flexible enough you might call them pixels and then what's
the difference between using them and just drawing by hand?

What you will see often though is that people use a framework to get some
level of detail out of the way. But often the good developers will also be
able to take out whole chunks of this framework and replace it with own code.

~~~
davidjnelson
Right, abstractions are useful. I'm just curious why we keep recreating the
same abstractions over and over again.

~~~
erikb
You need to interact with the question, why a painter won't use puzzle pieces
and instead draws fresh strokes each time he draws a picture. That's the core
point of the idea and I think with the example painter it's much easier to see
than with programming.

And I also answered your question already in a literal sense. We don't really
recreate the same abstractions. They feel similar to the user, but are quite
different through having a detail different here and a detail different there.
E.g. in one CRUD app you load the data from the web API, then filter, parse
and format it for presentation. In another CRUD app you already filter and
transform via SQL in the database. This is not done randomly but for a reason.
Through the whole process something different is created each time. At a
certain skill level you simply want to have that flexibility.

------
al2o3cr

        Behavior should be mostly auto generated config
    

Key word there: MOSTLY. The trick that's never been really figured out is how
to make adding the bits that can't be generated on top without making a
brittle mess.

If you squint a little, you could also regard the Wordpress ecosystem as
getting close - I've seen things done with custom fields that are remarkable.

~~~
davidjnelson
Right, to me higher order components could get us there.

------
AndyKelley
Because you would get 90% of the way there, and then have to start over
without the automation if you wanted to close out that last 10%.

~~~
davidjnelson
That's a good argument. If it used hand coded html and CSS, and had a huge
community of fully customizable components where you had higher order
components to enable the customization, what would the challenge be for the
last 10%?

------
chriswarbo
My guess is because UI is a massive source of churn. Anything which is visible
to a user and/or customer will be under a constant barrage of changes from
customers, marketing, management, etc.

One reason for this is, of course, that it's actually visible to them (unlike,
say, a communication layer between subsystems, which may sit there unchanged
for decades).

However, there's also the common _perception_ that all software gets built
from scratch, as if it were some bespoke piece of furniture. Hence anything
generated, or using "off the shelf" code, will still get bogged down in change
requests, not necessarily because those changes are "important" enough to
justify the effort, but because "since we're building this whole thing anyway,
we might as well do this part this way" (not realising that we _didn 't_ build
this whole thing, and it's the _changes_ which are the actual cost)

------
eranation
I think things just move too fast in the web world in the past few years...
Yes, a common component plugin standard so you can reuse it in both React and
Angular would be nice (Web Components?) but remember not _that_ long ago, we
were debating between EmberJS, BackboneJs and jQuery UI. And Gulp vs Grunt,
and UMD vs CommonJS, Bower vs NPM. React and Angular4 are very, very new
relatively, and they evolve pretty fast, with breaking changes. A company
betting on building a CRUD / UI builder needs to go into market in a few
months or it's already behind.

Take a look at react studio (see comment here). They are a great tool
probably, but they are focused on one popular library at the moment. The
change is so rapid that by the time you create an automation tool, it's
generating code that will be "obsolete" in terms of people who would like to
maintain it (would you go work for a startup where you need to maintain
backboneJS or jQuery UI all day?). The alternative is to generate code that
doesn't try to be "latest and greatest" at all, and not really care (see wix
code post earlier today)... but not sure it's a great bet as well.

I think back in the day, there were just less options to choose from when
building apps, and they evolved slower. This is why in the desktop days we had
a lot more robust UI builder, app builders (Every IDE has top notch visual
destkop UI editor, but also good old Magic, MS Access, FileMaker etc...).

I do think this is begging to be changed. And I'm sure a few people have this
in mind as well. But it will always be one step behind of the latest web
frameworks.

However you do have some solutions

1\. Java - JHipster uses yeoman to generate Spring Boot + Angular apps
including basic CRUD UI

2\. Rails - rails scaffolding do basic CRUD nicely

3\. Node.JS - [http://loopback.io](http://loopback.io)

I'm sure there are more. And I'm sure there will be more. But in the end all
the above do is give you a jumpstart, if all your app is doing is just CRUD,
then your barrier to competition is already low, whether it's automated,
outsourced or done by Stanford grads getting 200K a year.

But I do think that eventually your idea of shared components should be a
thing. Just need to get google and facebook in the same room and agree...
weirder things happened... companies agreed on standards before...

~~~
davidjnelson
That's an extremely good point. The solution to this would be that the output
is plugin based. It could spit out react, angular, next framework, framework
after that etc.

Edit: Thinking some more about this. I think the future proofing is the
hardest aspect. If you were able to leverage a custom compiler to transform
react or angular components to a future framework, that would get you there.

Also, Jhipster looks really great _if_ you happen to be using java.

~~~
nwellinghoff
Jhipster looks really great. Are people primarily using it to just bootstrap a
project or actually using for the duration of a projects full lifecycle?

------
amelius
> There have of course been hundreds of UI builders. Why aren't they used?

I think the reason is that building something with these builders may be easy
at first, but when you want to do something a little different than foreseen,
the cost goes up enormously.

It's this "cost gap" that developers are so afraid of, also because it is very
unpredictable.

~~~
Finnucane
With today's web frameworks, you can set up a simple app in an hour. But that
simple app probably won't solve anybody's real problem. There's always some
complication.

------
subwayclub
The root of the problem is that we tend to need special case automations to
build UI for the same reasons that carpenters and blacksmiths need jigs and
molds, but we keep reaching for generic tools to solve them, because software
lets you extend things indefinitely and so an "ultimate" generic tool is
always just out of reach.

For example, instead of a one-step translation of "invision mockup" to "final
site" it would make sense to translate the mockup into an automation conveying
that specific design language.

HTML and CSS deceive us by apparently being those generic tools to solve
everything. But because they're generic and composable in a high level sense
they actually get in the way of the intention - layout, content, and
interactions are all shoved into non-overlapping functionality boxes. And then
we add JS on top of that, making it possible to break out of the model badly.

~~~
davidjnelson
I see what you mean. Doesn't component level style and markup encapsulation
solve these though?

------
verdverm
I've been prototyping a tool to generate most of the implementation whilst
still allowing for BI and design changes. Would love feedback on if the
premises make sense.

[https://github.com/hofstadter-io/geb](https://github.com/hofstadter-io/geb)

~~~
TheCowboy
Can you explain what the "hofstadter framework" is?

~~~
lioeters
Found this from the author's GitHub profile:
[https://hofstadter.io/](https://hofstadter.io/)

------
lr4444lr
You're asking several different questions under a general umbrella which have
a lot of specific and long-winded answers, but to be succinct about it:
business want incredible amount of customization in all different ways, and
customization is resistant to automation and patterns. Successful frameworks
straddle a good balance, which is why they have staying power.

I think if you push your question to the extreme, we can ask why Literate
Programming never took hold. Wouldn't it be vastly more cost effective for
businesses to completely commoditize the entire IT department with just a
specific kind of technical writer who could pass along these specs to a
service that would compile the application as written? Competitive technology
simply isn't that predictable and circumscribed in capability.

------
znpy
It used to be.

The grails web framework was capable of generating relatively complex web ui
from the defined domain classes.

It was super cool! Sadly, it's not so used anymore, it seems quite dead. Last
time I tried to use it I found out they switched to gradle, making its usage
twice more complicated than it used to be.

------
nawitus
>Behavior customizability should come from tweaking the auto generated json
config, and adding some HTML and JavaScript to higher order components.

Show me a single component on any platform which can be customized via
properties to "do everything".

~~~
davidjnelson
To do everything, you write your own extension of the base component as a
higher order component with custom code.

~~~
pwm
Not entirely sure what do you mean by “higher order components” but what you
seem to describe would lead to the same problems we had with inheritance in
various oop languages.

~~~
davidjnelson
[https://reactjs.org/docs/higher-order-
components.html](https://reactjs.org/docs/higher-order-components.html)

------
MichaelGG
I dealt with this quite a bit and recently consulted for a friend wanting to
do something similar.

The issue is you think you can drag and drop data fields and be all set. But
to deliver a halfway decent UI, you need custom bits and pieces here and
there. From layout, to extra JS, to new "picker" types for some fields, and on
and on.

When I've looked at it, the issue is either the forms toolkit gets stupidly
complex or doesn't have a good customizability story, and in frustration you
throw away the toolkit and just do it by hand.

There's room to do something better, so long the customization is really easy
and trivial to add one-offs.

~~~
tmzt
What do you need beyond something like React Forms with additional HOCs? I'm
curious what you found.

------
miguelrochefort
Because businesses are greedy and short-sighted. They all think the problems
they're solving are novel, and they keep deviating from standards and reinvent
the wheel as a way to diffentiate themselves from others.

Truth is, most businesses are solving the same problems and a single general
purpose platform could easily be used by all of them. I'm not talking about a
framework that all businesses could use to build their apps, I'm talking about
one app that could be used to interact with all businesses.

I am convinced that a team of 10 people could make 80% of existing software
(and tech companies) obsolete in about 2 years.

------
xmatos
I've asked myself that many times before and I'd say it's because it's not an
easy task and often you need to get things done to meet deadlines, instead of
developing a general solution, that although could save time in the future,
might not help much in the short run.

Having said that, Django admin is the best example of that. I'm a huge fan of
it and tend to use it on every project that fits a crud workflow, mainly
business apps.

To give an idea of how much work goes into building something like that, it
took 5 devs an year to build its first version, not to mention add new
features and improve it.

~~~
davidjnelson
Django admin sounds like a very useful tool.

------
sireat
What is the closest thing you can get on front-end webdev to something like
Windows Forms, WPF or QT Creator?

Ie something where adding a button or a dropbox in a specific location does
not require intimate knowledge of CSS tricks while at the same time producing
reasonable code.

I found old Actionscript more consistent than modern webdev.

What I mean I do not need to know advanced XAML to produce quick and decent
CRUDs on Windows Presentation Foundation, while for the web this means hours
spent reading up on various quirks.

It almost means that you need a dedicated front-end guy with you all the time
if you want to iterate your design.

~~~
firemelt
I also ask the same, why webdev doesn't have tools like that, why everyone
love to write a ton of css to make a button on the middle page, See struct,
it's a wysiwyg gui builder for react

------
bigmanwalter
There are a handful of Rapid Development frameworks which will automate the
majority of CRUD. My personal favorite is Web2Py. I can build a working
protoype of most ideas in a week or two with it :)

~~~
copperx
Is that faster than just doing it with Django?

~~~
bigmanwalter
I would say so. The biggest difference I find is that Django makes a few too
many assumptions and can be a pain to tweak the way you need.

Web2py was created because the author found Django too difficult to teach to
his students at DePaul University. He rebuilt Django while fixing many issues
in how it was designed, and simplified the API significantly in the process.

Instead of Django's admin interface, web2py gives you a Grid component which
allows you to create an Admin interface for any model/relationships that you
like within any page you want. So your Admin pages are just another
route/controller which use the grids as necessary.

Web2py's ORM is super nice to use. It's very similar to using plain SQL, and
incredibly powerful. It holds your hands a bit less than an ActiveRecord style
ORM but I find it also traps you in fewer corners. Especially when it comes to
reports/aggregating data.

Likewise, it's a pain to set up email addresses for the user's username in
Django, or to add custom fields to the User model. In web2py, it's dead
simple.

Web2py has an easier to use authorization layer than Django's, and it handles
migrations more smoothly.

Web2py's HTML templating language is much nicer than Django's. It's just
python, nothing extra. Super easy to pick up.

Web2py forms support file upload fields, and image upload fields out of the
box. It also has a module for automatically resizing image uploads as
necessary. It includes a datepicker for date fields, and it also has the
"LOAD" function which makes is super easy to Ajax up your site.

The other big thing that I love about web2py is that all the form/grid helpers
output Bootstrap compatible HTML out of the box, so you can throw on a theme
from Wrapbootstrap.com and just like that you have a beautiful site.

~~~
NumberCruncher
And Web2py works well with Intercooler JS so you can get quite far without
having to write any JS code.

~~~
bigmanwalter
It even has its own alternative to Intercooler built into the framework:
[http://web2py.com/books/default/chapter/29/12/components-
and...](http://web2py.com/books/default/chapter/29/12/components-and-plugins)

It's super cool :)

------
ivanhoe
For it to really work you need your environment, tool chain and all components
to be fully integrated, which significantly limits ones freedom when choosing
the frameworks and libs. Last few years front-end is evolving at a such crazy
speed that it seems no scaffolding tool was capable of keeping up the pace.
You probably can find something for technology X, but as soon as you try to
combine X with Y and Z, you're much better doing it by hand, or by combining
manually the result of a few simpler tools.

------
mamcx
As one of the dozens and dozens of people that not only do CRUD for life but
kind of like it:

Is almost 94% automated.

The name of the tools: Relational Database System.

You need to "just" describe the data, relations, queries and perform the input
of the rows. It automagically give the results you want, and kind of fast most
of time!

\---

The "Why?" CAN"T BE fully automated (or close to 100%):

How many program you can fit in this description?:

 _C_ reate _R_ ead _U_ pdate _D_ elete

Like, all of them? (given or taken a few dozen???)

\---

The "HOW" we could actually do CRUD more nicely?

You _must_ put aside the OOP model. It could be there, but aside.

The functional neither is. Nor lisp, haskell, or anyyhing similar.

You need a truly relational language (remember how a RDBMS is the answer to
your question?).

Probably need to plug a actually nice Tree-manipulator language (exist a
relational model, but for trees???). OO is almost there, but not close enough.

You can mix OO and anything else.

This is not a pipe dream or untested. The dbase family operate like this. I
code for work in FoxPro and was FAR better than Python, Delphi, .NET(F#) (all
I like, but HELL NOT, THEM ARE NOT GOOD DATA LANGUAGES)

The other side of the equation is the form/report builder.

Let me tell you: You ACTUALLY NOT WANT A (auto) FORM BUILDER.

You need a FORM BUILDER DESCRIPTOR and the flexibility of build your UI
manually based on this.

THis is not speculation or untested. This was (almost) how FoxPro operate...
the descriptor was tables. The tables were used to build the UI. _Literally_
the UI was serialized on tables. Like how cool kids this days use JSON. But
potentially better if you discover this (ie: Open the form file and see _is
just a table!_ ) and then use this for the full effect.

Obviously, FoxPro and other tools were _rough_ like you can expect for
"ancient" tech. But similar how Lisp, SmallTalk, APL, Rebol, Pascal, Modula,
ML were "rough" and we are rediscovering the potential them have, this is the
same with the dBase family.

------
skinnymuch
I've felt like I'm so close to a powerful library that will be robust and
advance my pursuits quickly. Hasn't worked out yet. I am getting better and
better. Frameworks and libraries are getting better too, but to remove
something like 90% of a CRUD app that isn't literally just a basic content CMS
site - I don't see that happening soon.

------
teyc
There's a movement called MDA (model driven architecture) which aims at large
scale automation. I regularly keep an eye on this, but it never seems to leave
academia. There's a lot of leverage that's possible but it's hard work to get
there.

------
salehk
It is mostly automated to an extent. A previous company i worked at, one of
our main focuses was making a component out of everything so when it came time
to build a new page, we just pass a config + dataset to our component and
that's it voila page built.

------
thatonechad
This is one of the reasons I use Drupal. It is bloated a bit but the CRUD
system is out of the box easy. You can add properties to entites on the fly
without code, then turn it into an API system in a matter of minutes.

------
mar77i
Well you can do it badly and end up with ... wait for it ... ScriptCase. You
know you crossed the edge to insanity when the Login form consists of 10,000
lines of generated, ugly looking code.

------
rubyfan
See Ruby On Rails.

[http://rubyonrails.org](http://rubyonrails.org)

~~~
copperx
You will start fighting Rails as soon as you add a frontend framework. Rails
was conceived in the era of server-generated webpages.

~~~
rubyfan
It will work just fine with angular or react. I have seen nothing comparable
in the era of JavaScript frameworks.

~~~
copperx
Me neither; I use Rails all the time. But that doesn't mean Rails and React
are made for each other.

------
chx
It's so funny you readily presume JavaScript as the ultimate web language. It
is everything but. The only reason people still use it because the browser
holds them hostage and then they readily march into the hell that is server
side JavaScript. Once WebAssembly breaks that hold, we will look back to the
era of JavaScript as a bad, bad dream.

~~~
DigitalJack
Penultimate means second best, fyi.

~~~
chx
Thanks. Fixed.

------
GroSacASacs
Because reasons ... First every CRUD app has specific differences in: the UI,
authorization system, rules,

It is not taught enough in classic computer science classes (what I did) to
reuse existing patterns/RAD/frameworks

Also it is to an extend automated: ui libraries, widgets, SQL/NOSQL, admin
interfaces etc are existing and could be viewed, as automation.

------
LoSboccacc
because the real world sucks and it's full of chaos, exceptions and special
cases.

------
Chyzwar
This was possible in Smalltalk environments where everything was in one
"garden". Products like Cincom VisualWorks where doing this 20 years ago.

The web is not unified like that, the foundation is way too shaky. Visual UI
builders have failed idea because they cannot encode complex business
requirements.

------
Walf
I dunno, mate. Your proposed solution sounds fairly custom to me.

------
ilaksh
There are lots of tools that do that. But if a tool automatically programs for
you, then are you a programmer, or a user?

Programmers do not want to be accused of being users. So they stay away from
those tools.

(FYI I am a programmer.)

------
mrfusion
The Django admin comes pretty close.

------
thallukrish
because every data model is different, every process flow is different, every
UI is different.

------
alistproducer2
Humanity has ever been known for homogeneity. Different people think
differently about how to solve problems.

------
dreamdu5t
Because management is ignorant of technical costs. At the end of the day, the
person who cuts checks says “I want rounded corners with drop shadows, and I
want them pink and sparkly.” For example, we already have standard input
controls but it’s de facto industry practice to implement custom ones to
please those that have no understanding of these invisible costs.

------
jlebrech
because WYSIWYG went out of fashion.

also web frameworks are not honest about being framework for building what's
already out in the wild, they are flexible enough to build the next killer app
but not simple enough to create Yet Another Web App.

~~~
tonyedgecombe
It's interesting isn't it, we wouldn't dream of hand editing an image file or
CAD drawing yet we are happy to use a text editor to change the colour of some
text on a web page.

Personally I think web development has gone completely off the rails, I'm glad
I don't have to do very much of it.

~~~
jlebrech
I would like to quit web development and come back if a modern solution comes
along.

We need a cocoa of the web, there was cappucino but it never took off, but I
think with web assembly anything is possible, i'd rather use opengl and
shaders than html and css.

I even think there's a missing file in between html and css, there should be a
data structure that automatically becomes a user interface and another
language to for layout, so the the concerns are separated between developer
and designer.

~~~
tmzt
This is something I've long believed. A Data Style Sheet to go along with the
raw HTML and CSS.

You could even make it as designer-friendly as JQuery while still building
modern isometric SPAs as output.

For example:

    
    
        #users { from: store.users |where roles.includes('Admin')}

~~~
jlebrech
Cascading Data Sheet? that it exactly what i'd want. I saw yaml based
templating like slim or haml but then thought it was such a shame to see 'div'
or 'b', etc in there.

~~~
tmzt
Yep, it would even interpret the designer's dummy data as a repeating
template. If it couldn't figure out the mapping CDS could give hints as
appropriate.

The best part is it could be compiled into a component like JSX but wouldn't
prevent the page from being previewed with no programming implemented at all.

The template would basically be an HTML mockup.

~~~
jlebrech
yep, a fully designed dummy just gets manipulated without any code being added
to it at all.

then there's no chance to get in each other's way, as long as the designer
names the classes correctly.

~~~
tmzt
As long as they name them consistently really, you would just need to provide
custom transform/pattern rules if they could not be detected.

I might work out a prototype of this once I get my framework off the ground.

------
dozzie
> Why Isn't the Construction of CRUD Web UI's 90% Automated?

My guess is because web coders have very, very short memory and couldn't be
bothered with learning whatever programmers were doing in '90s and '00, both
on server side and on desktop side.

> There have of course been hundreds of UI builders. Why aren't they used?

There was this Borland Delphi thing, and these different GUI toolkits like
Motif, Tk, Qt, GTK+, wxWidgets, or Java Swing, but then desktop software
became mostly irrelevant, replaced with web. Somehow very few people cared to
port good ideas from desktops.

> Behavior should be mostly auto generated config from a standardized format
> such as json schema or a db schema.

There you go with learning history. There were attempts on desktops at doing
such things, but they died off. They weren't that good of idea.

~~~
davidjnelson
Thanks :-)

> There you go with learning history. There were attempts on desktops at doing
> such things, but they died off. They weren't that good of idea.

What are some examples of tools that did this and what were the issues?

~~~
raarts
I programmed in a DOS tool called 'Magic'. It basically was a screen designer
which could work on tables. All code was held in the database, all screens
were datadriven (declarative). It ran on the Novell Btrieve database. It was
from an Israelian company.

It worked perfectly. Even my brother, who wasn't a programmer at all, was able
to write his business software with it. It was reasonably fast. Downsides:
theming wasn't possible so all applications looked the same, and Btrieve
wasn't as reliable as it needed to be.

But otherwise it was great. I never understood why such a program doesn't
exist these days. Tempted to write one myself....

Edit: they still exist: magicsoftware.com.

~~~
demosthenex
I've love to see more character cell intefaces. Not everyone wants to run a
web/GUI stack for a simple CRUD form. TUIs are often fast, and low
requirements. I've considered the same myself, as no modern languages include
a real TUI library (no, curses support != a TUI).

~~~
copperx
There ought to be an open-source Linux-compatible Borland Turbo Vision clone.

Your clients could be $10 Raspberry Pi Zeros.

~~~
demosthenex
I think that's what the web community misses. We have 50 years of Moore's Law
to benefit from, yet we are making slower applications than ever. The larger
these codebases, the more complex they are to maintain, secure, and debug.
They need larger hardware to provide the same relative performance.

I want to see more lean, tiny, fast applications. Low TOC, low investment
because they aren't complex. Low end hardware that can be made reliable,
small, and maintainable.

I think it's hideous that most business applications I see (CRUD interfaces)
are 90+% text, and yet they are built on layer and layers of GUI and web
interfaces.

Your Raspberry Pi example would be lean and easy to maintain. No virus
scanners, no 20GB OS footprint to maintain. No worries about your user
visiting Facebook all day instead of working with your business application.

I want applications that are so incredibly dull that they will be taken for
granted as much as office telephone.

