Building apps in minutes, not months

Let me share a small fun story (of making an application in an hour, not months).<p>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.<p>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.<p>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.<p>Rather than present slides and extol virtues of Elasticsearch, I decided to <i>WRITE THE APPLICATION DURING THE MEETING, FROM SCRATCH</i>.<p>And that&#x27;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.<p>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.<p>I used JHipster to generate 90% of the service and the rest was just tiny bit of well thought glue code.<p>Unfortunately, this did not sit well with couple of people whom I made complete mockery of. I had to leave soon after.

There&#x27;s an excellent talk by Rich Hickey (I believe it&#x27;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.<p>While it&#x27;s very intuitive to see the appeal in low barrier to entry, there&#x27;s something to be said about tools that optimize for the long-term. Instruments aren&#x27;t made for beginners, they&#x27;re made for people who know how to play them.<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=MCZ3YgeEUPg" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=MCZ3YgeEUPg</a>

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, &quot;Production Ready&quot; as used by this author is <i>very</i> different than what &quot;production ready&quot; 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 &quot;Production Ready&quot; should sufficiently demonstrate that.<p>And that&#x27;s okay! It doesn&#x27;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.<p>To be more specific, he has the &quot;Source&quot; and &quot;Detail&quot; 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&#x27;d be completely lost. Did anyone else understand how the data actually flows across these pieces?

Ugh, is it that time again?<p>You can&#x27;t just magically disappear the complexity that is inherent to building actual applications. Synchronizing data based on unique IDs isn&#x27;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.<p>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.<p>Pony up some source code and actual details and then we can talk. Until then, as far as I&#x27;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&#x27;s similar to a project I&#x27;ve been dedicating most of my personal time to for the past 4 years [0].<p>It&#x27;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].<p>I think a tool like this is the future of web development: create the interface and boom, you&#x27;re app is already working. That kind of instant validation of your work is addictive.<p>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&#x27;s connected to other users&#x27; data. But I think these issues can be solved either with reactive hooks or some of the innovations coming out of the GraphQL space.<p>I think you can get pretty far with a system like this:<p><pre><code> * User accounts * Automatic data syncing * Collaboration * Deployment &amp; hosting * Payments * Form submissions </code></pre> 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.<p>And these features, if done well, are all that 90% of businesses need to create value for their customers and become profitable.<p>I&#x27;m really excited about this space. My email is in my profile if anyone wants to talk about it further.<p>[0] <a href="https:&#x2F;&#x2F;remaketheweb.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;remaketheweb.com&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;www.meteor.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.meteor.com&#x2F;</a>

That&#x27;s a great demo, I really like how you built up the layers as you went through it. It&#x27;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&#x27;m not sure how you&#x27;re solving that?<p>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&#x27;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&#x27;ve been using the free, open-source React Admin <a href="https:&#x2F;&#x2F;marmelab.com&#x2F;react-admin&#x2F;" rel="nofollow">https:&#x2F;&#x2F;marmelab.com&#x2F;react-admin&#x2F;</a> 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).<p>There are some other low-code tools that have similar premises and offer things like ETL tools. We evaluated one called Retool <a href="https:&#x2F;&#x2F;retool.com" rel="nofollow">https:&#x2F;&#x2F;retool.com</a> and it seemed pretty cool, but because it&#x27;s a per-user pricing model, the costs can be pretty substantial when you have a lot of people using the tool.

I&#x27;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.<p>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 &quot;itemId&quot; just becomes a property in a big JSON file and the framework knows what to update and how to update it because the &quot;schema&quot; is just controlled by the shape of the component tree and the type of component. That probably works for some use cases, but it&#x27;s not something that scales IMO.

Very cool. I feel like this is the early version of a &quot;programmable Notion[1]&quot; in some ways which is built on similar building blocks that are customizable.<p>[1] <a href="https:&#x2F;&#x2F;notion.so&#x2F;" rel="nofollow">https:&#x2F;&#x2F;notion.so&#x2F;</a>

My critique is this tool seems like you&#x27;ll hit walls as soon as the framework can&#x27;t do exactly what you need. Oh, you need a sortable to-do list? Just use the &quot;DatasetSortable&quot; React component instead of the normal &quot;Dataset&quot;. What if the framework doesn&#x27;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&#x27;t realistically see how this grows beyond the trivial, unless the framework solved your concrete need.

As nice as this looks, I&#x27;ve been working on something similar and immediately see tons of limitations.<p>Things like:<p>- batch editing: what if you don&#x27;t want your edits to save immediately, but instead as a group?<p>- item creation and joins: what if some fields create items that have ids that other fields require for update or their own creation?<p>- discarding edits: what if you want to throw away your changes?<p>- front-end auth: how do you verify that a field is editable before creating a text box for it?<p>- front-end validation: how do you make custom field validators?<p>- 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?<p>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&#x27;s no way around building real production apps starting from the UI. Design has to begin with data model. It&#x27;s like building a House not from the foundations but from the facade.

I&#x27;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&#x27;m sure that is also the case for Spring, Rails, or other &quot;older&quot; frameworks.<p>I still haven&#x27;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<p>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:<p>a) I’ve been working o a similar thing…<p>b) Look at this other more mature project that solves the same problem…<p>There’s nothing wrong with a modern take on an old problem, but a <i>naive</i> take on an old problem that doesn’t either learn from issues with past attempts or offer anything novel…<p>This is a hard problem; How do you scale with easy quick prototyping and robustness for production quality.<p>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.<p>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&#x27;t realize is the ubiquity of these types of custom-application-platform systems.<p>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&#x27;t care to name...<p>My point is that it&#x27;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?<p>To the author: I applaud your efforts. One question though - how can we try it out?<p>EDIT: I can also mention Arc, PG&#x27;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&#x27;s the case, is it more difficult to learn this new thing, or just prototype something in React? I&#x27;m guessing the former.

A simple trick I use to validate any full-stack framework is &quot;Can I build an ERP system with this framework&quot; ?<p>It&#x27;s not perfect, but ERP systems have everything that modern apps do<p>#1 authentication<p>#2 role based authorizations<p>#3 Data entry forms<p>#4 Pages to show information from data<p>#5 Reports<p>How well does this one fit to that benchmark?

So not GitHub Repo with the framework?<p>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 &quot;Todo: The hard parts&quot;[1] where I started discussing how syncing the data planes of frontend apps are much more complex than they seem.<p>This looks really cool. I like the idea behind the Source&#x2F;Dataset&#x2F;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.<p>[1] <a href="https:&#x2F;&#x2F;synth.app&#x2F;blog&#x2F;todos-the-hard-parts-part-1" rel="nofollow">https:&#x2F;&#x2F;synth.app&#x2F;blog&#x2F;todos-the-hard-parts-part-1</a>

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?<p>Shameless plug. We also built a platform - Lowdefy - to develop web apps in minutes &#x2F; days by only writing yaml or JSON. So far we find that it really empowers any developer to develop a web app (Especially backend &#x2F; data dev who not feel like learning CSS &#x2F; react &#x2F; webpack etc)<p>Check it out <a href="https:&#x2F;&#x2F;github.com&#x2F;lowdefy&#x2F;lowdefy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lowdefy&#x2F;lowdefy</a>

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&#x27;s the reason tools like Blitz [0] exist in the first place.<p>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 &#x27;Production App&#x27; rather than a quick prototype.<p>[0] <a href="https:&#x2F;&#x2F;blitzjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blitzjs.com&#x2F;</a>

&gt;These Lab Notes document my research in progress. My research area is in the future of personal computing.<p>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 &#x2F; column?

I have implemented a much more flexible URAD tool, completed a large scale project with it and then used it in other projects.<p>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.<p>1-The way we store data can be completely different from the way we present it to user<p>2-In only a tiny fraction of apps each user can only see their own data<p>3-When load (data volume&#x2F;request per second, etc) increases, we often need fine control over the entire product<p>4-Change management can be tricky, especially when if changes shape of data store<p>For all these reasons, I don&#x27;t expect these extreme rapid tools to gain huge success. More modest claims, like retool&#x27;s (A great internal data administration tool) are more realistic.<p>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&#x27;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 &quot;production&quot; 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 &quot;saved&quot; data just disappeared. It feels like alot of the magic of the syncing to the db is relying on the ID&#x27;s derived from specifics of the UI fields. I&#x27;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 &quot;production-ready&quot;, 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.<p>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.<p>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.<p>(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&#x27;s app doesn&#x27;t.)<p>[1] <a href="https:&#x2F;&#x2F;easylists.app" rel="nofollow">https:&#x2F;&#x2F;easylists.app</a>

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.<p>The harder subjects seem like the design of complex schemas and algorithms, complex UIs, scaling, and systems-level integration.<p>Perhaps the easy&#x2F;edge pieces will fall to automation, leaving the middle and low-level work to engineers and designers.

Interesting and very mysterious.<p>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): <a href="https:&#x2F;&#x2F;github.com&#x2F;intelix&#x2F;reactiveservices" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;intelix&#x2F;reactiveservices</a> some runnable examples are here: <a href="https:&#x2F;&#x2F;github.com&#x2F;intelix&#x2F;reactiveservices-examples" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;intelix&#x2F;reactiveservices-examples</a><p>And the screenshot is the early version of the real app built on it<p>Conceptually it&#x27;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.<p>It was built, first of all, for the application in forex trading, so there are some &quot;specific&quot; 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.<p>How it works is described (in rather over-simplified way) on the github page. There&#x27;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.<p>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.<p>Latest version uses latest react features, hooks based, and the server side has seen significant changes as well.<p>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&#x27;s still nothing like this is available. GraphQL with subscriptions probably is the closes, but not good enough.<p>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.

This is useful in the same way that throwing cards up in the air and hoping that a standing structure will emerge for a few of them is useful. Yes, it&#x27;s faster and easier than building a card house by hand, but you lose most ability to manage business-complexity logic.<p>Most senior devs can code something from scratch that will automagically create a crud form in a couple hours. The reason we don&#x27;t do it is that it&#x27;s not useful.

This reminds me a lot of <a href="https:&#x2F;&#x2F;lamdera.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lamdera.com&#x2F;</a>, though more React and less Elm. Lamdera has the added benefit that changes are deployed in real time instead of having to reload, including in production. This means the user doesn&#x27;t get those annoying popups saying something like &quot;there are new features, refresh your page&quot;.

So it&#x27;s a declarative display-oriented language with late binding embedded into HTML? It&#x27;s... a web-native form of a FileMaker Pro app?

i think we have a different idea of &quot;production ready&quot;. but its a cool utility for rapid prototyping, definitely. reminds me of xforms.

Went from 0 to App Store and Google Play in one month with a react-native app with a webview to a rails&#x2F;stimulus&#x2F;react app

While stuffs like these are laudable, it still merits a lot of consideration that for these to be impactful to companies &#x2F; business &#x2F; people that would adopt them, they need to have that domain expertise and knowledge of what needs to be built. Too many times, a lot of products are built trying to find a solution it was conceived for.

I agree with the philosophy even if I&#x27;m not totally understanding how you are getting there. I talked about my process which has similar elements like reusing components to build fast here: <a href="https:&#x2F;&#x2F;www.hackyexperiments.com&#x2F;process" rel="nofollow">https:&#x2F;&#x2F;www.hackyexperiments.com&#x2F;process</a>

Nothing new. I have used code generators most of my career to automate things. They are a massive productivity booster. But I also learned that each code generator needs to be tailored to the project or class of projects you are working on to be useful.

Generally from my measly experience developing apps, it’s not coding them that takes the time

The thing is that building an app or building a product is not really about “building” it. So the months you spend are not about creating CRUD interfaces, but about planning and all the small things, all the details you need to figure out.

I would like to know more about how this works on the internals, mainly in terms of security. Of course, if the author says to me that is only for prototyping I&#x27;ll say nothing :)

Sound interesting, I have been planning to do something like this for a while. In the end, app development is so standardised that I don’t get why tooling is so terrible.

Just want to say that DatasetSortable is awesome - I once implemented the same functionality (saving the state of sortable checkboxes) and it was a nightmare.

So, where&#x27;s the Github link for Conductor Framework?

“Writing books in minutes not months”<p>Who else is excited to read it?

Or just use Django

Great post. This is a reality that a number of no-code and low-code tools bring to the table, including Budibase - an open source alt to retool, mendix, outsystems.<p>If you are interested, check out the repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;Budibase&#x2F;budibase" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Budibase&#x2F;budibase</a><p>It&#x27;s used at Amazon, IBM, F1, Deloitte, NHS, and more.<p>I&#x27;m the co-founder of the project and I hope you don&#x27;t mind me posting - it felt relevant.

This wouldn&#x27;t work for apps with moderate depth but for simple surface-level stuff, this would work great. It always feels like stuff like this would solve many people&#x27;s problems if only they knew they could use this instead of hiring six nerds to build their simple app. I&#x27;m still blown away by how many people don&#x27;t realize stuff like this and Wix&#x2F;Squarespace + AWS would fulfill their business needs for basically free.

Browsers should supported a rich set of UI components, optimized so that AI can compose interactions between them.

Are we going to see a version of Visual Basic being reconstructed with javascript soon?

So... would 128 Gb ram be enough for one of these apps?

I wonder since when started calling basic pages apps.

Anybody else bothered by the 105 uncommitted files?

Building prototypes in minutes, apps in months.