Building apps in minutes, not months

Let me share a small fun story (of making an application in an hour, not months).

At one large insurance company in my role as an architect I have tried to convince people we need Elasticsearch to speed up free-form queries to our database containing information about hundreds of millions of people and their contracts. That database was Oracle and so not really amenable to completely arbitrary queries.

I was immediately shot down that the project will take huge amount of time and effort to complete and so is completely off the table.

So I came up with fun plan. I set up an hour-long meeting which was supposed to be my last chance to pitch the project.

Rather than present slides and extol virtues of Elasticsearch, I decided to WRITE THE APPLICATION DURING THE MEETING, FROM SCRATCH.

And that's what I did. I came to the meeting, set my laptop, connected projector, put some music on, and I wrote the entire service from scratch and had time to spare to present how it works.

I cheated a little bit, of course. That 1h meeting was well rehearsed. I spent entire week preparing, finding better ways to do stuff and retrying entire process dozens of times.

I used JHipster to generate 90% of the service and the rest was just tiny bit of well thought glue code.

Unfortunately, this did not sit well with couple of people whom I made complete mockery of. I had to leave soon after.

There's an excellent talk by Rich Hickey (I believe it's this one[1]) where he points out an obsession with how quick something is to understand immediately and be productive in—he gives the example of building websites in a single day, and contrasts it to musicians learning and mastering instruments over much longer periods of time.

While it's very intuitive to see the appeal in low barrier to entry, there's something to be said about tools that optimize for the long-term. Instruments aren't made for beginners, they're made for people who know how to play them.

[1] https://www.youtube.com/watch?v=MCZ3YgeEUPg

This is a UI prototyping tool, and a potentially good one at that. It does not develop what a HN audience would call production ready applications. That being said, "Production Ready" as used by this author is very different than what "production ready" as used by the HN audience means, a look at the end of the linked video where he claims a checklist with drag and drop support and cookie-derived sessions next to is "Production Ready" should sufficiently demonstrate that.

And that's okay! It doesn't need to have replaced the entire Web Developer career field, it can just be a cool UI prototyping tool. But I might suggest to the author to reduce the scope of their claims a touch, as it would engender more positive discussion.

The components used here seem like theyre very specific to the needs of the application that was built. I have no idea how this type of framework would be used to build anything else.

To be more specific, he has the "Source" and "Detail" elements, but theres no apparent way of what piece of data is being synced across them or how theyre connected. Therefore, if I wanted to change any of that, I'd be completely lost. Did anyone else understand how the data actually flows across these pieces?

Ugh, is it that time again?

You can't just magically disappear the complexity that is inherent to building actual applications. Synchronizing data based on unique IDs isn't special. At best this is an interesting prototyping tool and at worst this is a huge red flag for your understanding of actual web development.

Of course there is no source code, but we get to bear witness to the great development habits of this author: 105 changed files in his repo.

Pony up some source code and actual details and then we can talk. Until then, as far as I'm concerned, you just demonstrated ready-made components that are talking to firebase or whatever.

This is incredible work and very close to my heart because it's similar to a project I've been dedicating most of my personal time to for the past 4 years [0].

It's amazing how much work you can skip when you treat the front-end of your app as a pretty interface for your database. I think a lot devs were inspired to go down this road by Meteor.js back in 2012 when it was released [1].

I think a tool like this is the future of web development: create the interface and boom, you're app is already working. That kind of instant validation of your work is addictive.

The problems arise when you want to change how data is processed behind the scenes before displaying it or after the user edits it. Or how it's connected to other users' data. But I think these issues can be solved either with reactive hooks or some of the innovations coming out of the GraphQL space.

I think you can get pretty far with a system like this:

  * User accounts
  * Automatic data syncing
  * Collaboration
  * Deployment & hosting
  * Payments
  * Form submissions

All of this is pretty trivial to get working out-of-the-box with very little effort from a dev. So no one has to reinvent the wheel.

And these features, if done well, are all that 90% of businesses need to create value for their customers and become profitable.

I'm really excited about this space. My email is in my profile if anyone wants to talk about it further.

[0] https://remaketheweb.com/

[1] https://www.meteor.com/

That's a great demo, I really like how you built up the layers as you went through it. It's really easy to see how you can keep composing and building up more and more impressive apps using these building blocks. My main question would be around authentication, you mention it both on the website and in the video but I'm not sure how you're solving that?

Also how generic is your ID-based sync mechanism? Can you attach it to any react component and sync whatever it has in useState hooks? Or is there magic going on in the prebuilt components that you demoed?

I'm not sure how this id-based data syncing mechanism solves things like authentication, business logic, and testing that I usually spend the most time on. I need a concrete example maybe?

I've been using the free, open-source React Admin https://marmelab.com/react-admin/ framework for this use case, and I really like how it works and how little code I need to write. I used it to quickly build an internal CMS, and it handles relational stuff well. For instance, if I have pieces of content, each of which can have multiple tags, it handles all the tag lookups using typical REST API calls. Also integrates well with our existing auth system (AWS Cognito).

There are some other low-code tools that have similar premises and offer things like ETL tools. We evaluated one called Retool https://retool.com and it seemed pretty cool, but because it's a per-user pricing model, the costs can be pretty substantial when you have a lot of people using the tool.

I'm working on a project with a somewhat related concept (dynamically generated PWA built from configuration generated by a simple UI) and I can appreciate some of the complexities involved in building a a framework and composable component library.

From what is shown in the video, I think the biggest limitation is that this approach would only work if the data model is stored in a document store. Each new "itemId" just becomes a property in a big JSON file and the framework knows what to update and how to update it because the "schema" is just controlled by the shape of the component tree and the type of component. That probably works for some use cases, but it's not something that scales IMO.

Very cool. I feel like this is the early version of a "programmable Notion[1]" in some ways which is built on similar building blocks that are customizable.

[1] https://notion.so/

My critique is this tool seems like you'll hit walls as soon as the framework can't do exactly what you need. Oh, you need a sortable to-do list? Just use the "DatasetSortable" React component instead of the normal "Dataset". What if the framework doesn't have a say, filterable, dataset component? What if you need access control? What if you want to share your todo list with others? I don't realistically see how this grows beyond the trivial, unless the framework solved your concrete need.

As nice as this looks, I've been working on something similar and immediately see tons of limitations.

Things like:

- batch editing: what if you don't want your edits to save immediately, but instead as a group?

- item creation and joins: what if some fields create items that have ids that other fields require for update or their own creation?

- discarding edits: what if you want to throw away your changes?

- front-end auth: how do you verify that a field is editable before creating a text box for it?

- front-end validation: how do you make custom field validators?

- mid-edit derivative values: if you change something without yet saving it, will the other parts of the ui using that value also show updates?

Solving all these issues has been a tough project. I started off wanting to be able to just pass a rowId, tablename, and columnname, but pretending things are that easy only works for very, very flat Databases. (no joins)

IMO there's no way around building real production apps starting from the UI. Design has to begin with data model. It's like building a House not from the foundations but from the facade.

I've been noticing that a lot of work in web development is boilerplate. For me Django has made that almost magic, with Generic views, automatic form and view generation and almost self generating APIs. Add to that a lot of community resources and templates (like cookiecutter), and you get an almost fully ready app in a matter of hours. I'm sure that is also the case for Spring, Rails, or other "older" frameworks.

I still haven't found tools that match those for SPA or PWA (React or other), and it seems that this is almost what the author is trying to go for.

Is it just me, or is this ASP.NET ViewState from 15 years ago?

Cool, but I could do it in the same time with Rails

If I did it with a Rails template such as JumpStart I’d also have a tonne of extra features such as user authentication, payments, styling etc. out of the bag

You should try Microsoft WebForms. Build apps in seconds!

There’s something in the number of comments here along the lines of either:

a) I’ve been working o a similar thing…

b) Look at this other more mature project that solves the same problem…

There’s nothing wrong with a modern take on an old problem, but a naive take on an old problem that doesn’t either learn from issues with past attempts or offer anything novel…

This is a hard problem; How do you scale with easy quick prototyping and robustness for production quality.

Projects like unreal that solve this well are few and far between, and usually marked for “version 5” or “version 7”, where they’ve gotten past the early stumbling blocks of bad decisions and leaning too heavily towards no-code and complexity.

This is a cute side project; maybe it has something novel to offer (I don’t see it, but perhaps), but it’s very naive, and it’s … a fair way off from something anyone else probably has a use for.

What some people don't realize is the ubiquity of these types of custom-application-platform systems.

Emacs is one of them. Linux is one of them. The web browser is another. VSCode and most IDEs are another. Rails. Flash. React. The C programming language. Of course, many unsuccessful ones too which I don't care to name...

My point is that it's good to have competition in this space. Who knows at what point the world will be ready for another higher level of coding? Even if this system fails, how many failures does this author need to accumulate before they discover something that is good?

To the author: I applaud your efforts. One question though - how can we try it out?

EDIT: I can also mention Arc, PG's custom Lisp dialect for building web applications including this very site.

Pretty neat, but like all these very similar tools, they seem built around TODO apps. These are only suitable for PoC apps. If that's the case, is it more difficult to learn this new thing, or just prototype something in React? I'm guessing the former.

A simple trick I use to validate any full-stack framework is "Can I build an ERP system with this framework" ?

It's not perfect, but ERP systems have everything that modern apps do

#1 authentication

#2 role based authorizations

#3 Data entry forms

#4 Pages to show information from data

#5 Reports

How well does this one fit to that benchmark?

So not GitHub Repo with the framework?

His blog is very interesting. Great ideas but the realized products are very similar to the competition...

Funny enough, I wrote a blog post yesterday titled "Todo: The hard parts"[1] where I started discussing how syncing the data planes of frontend apps are much more complex than they seem.

This looks really cool. I like the idea behind the Source/Dataset/Detail components. I wonder how they work in practice. My first attempt at a component based rendering system (with render cbs and such) felt super clunky as soon as things got a tad complex.

[1] https://synth.app/blog/todos-the-hard-parts-part-1

Kudos on this! Interesting approach. What variety of apps can be built with this? Do you plan to focus towards a specific category of apps?

Shameless plug. We also built a platform - Lowdefy - to develop web apps in minutes / days by only writing yaml or JSON. So far we find that it really empowers any developer to develop a web app (Especially backend / data dev who not feel like learning CSS / react / webpack etc)

Check it out https://github.com/lowdefy/lowdefy

Ruby-on-Rails with some magical gems(devise, simpleform etc.) can do this even faster and probably better looking.

This is a valid use case and it's the reason tools like Blitz [0] exist in the first place.

Plumbing UI, Forms, API and db is pretty much the same for a lot of MVPs and anything that can get you to a faster prototype is welcome. The difference between what the author shows and Blitz is that the latter is similar to Rails in the sense that it scales to a proper 'Production App' rather than a quick prototype.

[0] https://blitzjs.com/

>These Lab Notes document my research in progress. My research area is in the future of personal computing.

This is a classic web log. What blogs really should be about.

I wonder how it deals with any migrations? What if I decide to connect different components later? Or add a new attribute / column?

I have implemented a much more flexible URAD tool, completed a large scale project with it and then used it in other projects.

The huge amount of possibilities in software development will usually beat the tool and eventually what helped you get a fast start, ends up dragging you behind.

1-The way we store data can be completely different from the way we present it to user

2-In only a tiny fraction of apps each user can only see their own data

3-When load (data volume/request per second, etc) increases, we often need fine control over the entire product

4-Change management can be tricky, especially when if changes shape of data store

For all these reasons, I don't expect these extreme rapid tools to gain huge success. More modest claims, like retool's (A great internal data administration tool) are more realistic.

Eventually, I think that extremely flexible and extremely rapid tools will emerge, but my expectation is that they need great vision, great execution, and when trade-offs need to be made, it's better to err on the side of flexibility rather than super fast demos.

This looks like an amazing tool for prototyping or a hackathon, but I struggle to see how I might use it to deploy to "production" as is mentioned in the post. What stuck out to me was that any time we made a somewhat-large change to the UI, all of our previously "saved" data just disappeared. It feels like alot of the magic of the syncing to the db is relying on the ID's derived from specifics of the UI fields. I've found that even with full control of the framework, data migrations like these can be tricky -- I would be interested in seeing some more detail on this in the demo. Otherwise the set of things I could see myself using this for is very limited and certainly does not reach "production-ready", unless I intend never to touch the code again.

These tools are incredible and inspiring. Terse, intuitive and functional. Beautifully elegant code meant to optimize for time over flexibility.

It is hard to put into words how pleasing it is see a balance struck between code and data and how constructing the right abstraction can make solving a specific set of problems incredibly simple through the right language of expression.

I love when I solve a problem and the domain language offers me the expressiveness to solve it in a single line - even if the concept is complex, or that line fires off a hundred perfectly calibrated decisions under the covers - it tells me the universe, my problem domain, and my tools are in alignment.

Great. Now we can all build a shopping list or to-do list application in minutes.

I actually built the exact same app [1] in React. It took me longer than minutes but definitely less than months. I am interested in seeing the follow up videos for more complex applications.

(My feature set does not include storing on a server. It purposefully only stores on local storage. It also does not allow rearranging the lists or items - which again was a design decision. It does allow you to delete lists which Alexander's app doesn't.)

[1] https://easylists.app

Between techniques like this, no-code, capable component libraries, and ML-driven synthesis, I could see a lot of easy application programming going away. Especially if the resulting output is literate, self-documenting, and easily amenable to later human editing.

The harder subjects seem like the design of complex schemas and algorithms, complex UIs, scaling, and systems-level integration.

Perhaps the easy/edge pieces will fall to automation, leaving the middle and low-level work to engineers and designers.

Interesting and very mysterious.

How does the data syncing work? Can the developer hook into changes to execute business logic? How are changes to the same data point from different users handled?

An idea very similar to what we have developed some years ago. A much older version of it is still publicly available however not maintained (moved to private repo, more on this in a second): https://github.com/intelix/reactiveservices some runnable examples are here: https://github.com/intelix/reactiveservices-examples

And the screenshot is the early version of the real app built on it

Conceptually it's the same to what described in conductor, however you are in full control how the data is synced, how and to what you subscribe etc.

It was built, first of all, for the application in forex trading, so there are some "specific" features, such as optimised binary stream with delta-only updates, priority on the data streams, demand-based backpressure, subscription based on the visibility of the data, very low latency, cross-dc clusters and many more.

How it works is described (in rather over-simplified way) on the github page. There's a choice of scala or java on the back end, and react on the client side. Websocket only. Like I mentioned, the currently exposed source code is not maintained and based on the very old version of react (there are still mixins in the example) and libs, and has some vulnerabilities.

The latest version of the framework is maintained in the private repo, and we have built a number of solutions on it over the years, and not only in the forex space. It is well suited for most Single-page apps.

Latest version uses latest react features, hooks based, and the server side has seen significant changes as well.

Why we decided to keep it private? We thought world already have enough web frameworks, and since, we thought, our framework and approach was such a niche, we just kept using it for our clients and our own projects. But since then we have been surprised how easily it could be applied to other fields, and yet there's still nothing like this is available. GraphQL with subscriptions probably is the closes, but not good enough.

Is there any interest in something like this in the community? If so, we can definitely make large parts of the framework, which is now 6yo, public.