23 ms·

Building apps in minutes, not months

460 points by stevekrouse 5y ago

fouc 5y ago
>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.
- boomskats 5y ago
  Yeah - the claims in the title are a little contentious (at least on first glance), but the Lab Notes section of the site is a gem. And it's a _beautiful_ site. Really. It might just be a netlify theme or whatever, but I'm really enjoying reading it.
vinaygaba 5y ago
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/ https://notion.so/
jimbob45 5y ago
This wouldn'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's problems if only they knew they could use this instead of hiring six nerds to build their simple app. I'm still blown away by how many people don't realize stuff like this and Wix/Squarespace + AWS would fulfill their business needs for basically free.
mattnewton 5y ago
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?
- tiborsaas 5y ago
  You still need to spend those months, but the prototype will be up real fast :) But the title is not wrong, a month consists of weeks, days and minutes :)
  - tracyhenry 5y ago
    It's not wrong, but it's clickbait.
- olah_1 5y ago
  Yeah two-way data binding isn’t exactly new. What I would like to see more of is “no backend” type solutions that allow you to just write front ends that leverage existing auth, databases, etc eg. Sia, Gun, Dfinity, etc
  - cabalamat 5y ago
    > What I would like to see more of is “no backend” type solutions that allow you to just write front ends that leverage existing auth, databases, etc I did the opposite of that, since I see the data structures are the "real" thing and the layout of the web pages as merely froth on the top. My Frambozen[1] framework is all backend, in that you define your database schema, and then it builds parts or all of the front end (the web pages) for you. (It's written in Python and uses the MongoDB database). So for example, you might define a table like this: class Foo(MonDoc): name = StrField() description = TextAreaField(monospaced=True) aNumber = IntField(minValue=0, maxValue=100) minSpeed = FloatField(title="Minimum Speed, mph", minValue=0.0) maxSpeed = FloatField(title="Maximim Speed, mph", minValue=0.0) favouriteDrink = ChoiceField(choices=DRINK_CHOICES, showNull=True, allowNull=True) fruitsLiked = MultiChoiceField(choices=FRUIT_CHOICES, desc="tick all fruits this person likes") tickyBox = BoolField() aDate = DateField() lastSaved = DateTimeField(desc="when this foo was last saved", readOnly=True) aDateTime = DateTimeField(title="A Date and Time") anything = ObjectField(desc="can contain anything", default=["any", "thing"]) favouriteBook = FK(models.Book, allowNull=True, showNull=True) And then it can auto-generate a page to view / edit / create a single record in the table, and another page to listr all the records in the table. 1: https://github.com/cabalamat/frambozenapp https://github.com/cabalamat/frambozenapp
mcintyre1994 5y ago
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?
Lapsa 5y ago
You should try Microsoft WebForms. Build apps in seconds!
- deleted 5y ago
  [deleted]
echelon 5y ago
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.
- qsort 5y ago
  > Especially if the resulting output is literate, self-documenting, and easily amenable to later human editing. Big 'if' right there. I can see 'solved' problems being increasingly automated away (how many times do we need to write basic auth systems?), but in order to automate the entire pipeline you would need: - a specification language so detailed that it's basically a programming language - assumptions so strong they're liable to be subtly wrong ML can help, but we've all seen codex... we aren't there yet.
- gumby 5y ago
  A “MySpace for Apps”. Many would consider that a condemnation, and probably a well deserved one too. But I mean it in a positive sense: the democratization of development, the way DTP democratized printed expression (back when that was a thing). Also hopefully means programmers can spend their time on more interesting and value-adding effort rather than having to take the time to simply put a button on the screen. Of course the dream of rapid development goes back to FORTRAN.
  - cabalamat 5y ago
    > the democratization of development Like HyperCard, back in the day.
    - gumby 5y ago
      One of the few successful examples.
gmaster1440 5y ago
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 https://www.youtube.com/watch?v=MCZ3YgeEUPg
- PaulDavisThe1st 5y ago
  Ditto for both power- and hand-tools used for most craft.
- eof 5y ago
  Some instruments are made for beginners. I think the same correlations would be easy to find in software productivity. C++ :: Saxaphone Wix :: Recorder; or something
  - zwieback 5y ago
    I know C++, played some sax in my youth and recorder as a child. If only I knew Wix, then I could connect the two dots in a 2D graph!
  - RcouF1uZ4gsC 5y ago
    > I think C++ is more like the French Horn Excerpts from https://houghtonhorns.com/why-is-the-french-horn-so-hard-to-play/ https://houghtonhorns.com/why-is-the-french-horn-so-hard-to-... The French horn is widely considered to be the most difficult brass instrument to play. The modern-day double French horn is actually a combination of two horns (F, Bb) that share a common mouthpipe and bell. Because the partials (available notes in the harmonic series) are so close together in the third octave, the horn’s most comfortable range, it is fairly easy to miss or “crack” a note. Conversely, the partials that occur in the trumpet’s most comfortable range are comparatively more spread out, allowing for a bit better accuracy and more control. Another reason for the horn being difficult to play lies in the fact that it has the widest range of all the brass instruments: nearly as high as a trumpet and almost as low as a tuba. Additionally, the horn mouthpiece is small and deep, requiring fine muscle control and embouchure development. The mouthpipe is long and slender, creating more resistance for the player to overcome. Because the horn faces backwards–as opposed to the other wind instruments–the horn player must work extra hard to balance and blend with the other members of the wind instrument family.
matchbok 5y ago
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.
hermannj314 5y ago
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.
- growt 5y ago
  GPT3, is that you?
  - hermannj314 5y ago
    Sorry, I am just a developer. I'm not sure if I am supposed to be insulted by that comment or not.
    - ctenb 5y ago
      Definitely not GPT3
    - abj 5y ago
      I wonder if this is something GPT-3 would say. Am I GPT-3?
      - hermannj314 5y ago
        This entire exchange made me think of Blade Runner. Maybe I am not even human after all. How would I know...
        growt 5y ago
        Sorry, it wasn't my intention to insult you! Just one more question: Suppose you're in the desert and you see a tortoise turned on its back. What do you do?
jawns 5y ago
I've been using the free, open-source React Admin https://marmelab.com/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 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.
- cpursley 5y ago
  React Admin works really well with Hasura: https://github.com/hasura/ra-data-hasura https://github.com/hasura/ra-data-hasura
- arey_abhishek 5y ago
  Since you mentioned Retool and react admin, take a look at Appsmith. It's an open source low code tool similar to Retool. https://github.com/appsmithorg/appsmith https://github.com/appsmithorg/appsmith I'm a co-founder of the project and we started this because there was no open source project that made it easy to build highly custom admin panels and internal tools.
- topspin 5y ago
  I've done three production apps with React Admin and its predecessor ng-admin. They do what they say on the tin. Integrating custom components with React Admin works well and is a tremendous affordance.
- gervwyk 5y ago
  Check out https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy which is open-source. We created Lowdefy (co-founder here) to built web apps fast and it is really working well for us and our customers. We’ve already rolled out a few enterprise level apps in record time and the platform really scales well as apps evolve and get really complicated. Even developing apps as a team is a breeze since you are working with yaml / json which is easy to code review, copy, paste, find and replace. l
heavyarms 5y ago
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.
- stevenpetryk 5y ago
  Seems pretty clear to me that this isn't designed to build scalable apps. And that's okay—it's still a very thought-provoking exploration into a different paradigm of persistence.
- gervwyk 5y ago
  We went with the JSON / YAML approach and we are able to build some really complicated apps fast using Lowdefy - so it can scale, but only if you implement some sort of DSL to express logic. Check out https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy
chacham15 5y ago
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?
- oh-4-fucks-sake 5y ago
  Exactly. Just wait until you have to auth with a 3rd party API, fetch the request async, do a transformation on the response, load it into a 3rd party UI grid, add custom styling to the grid, and then add sorting and filtering on top. And this isn't anything particularly exotic--it's a wash-rinse-'n'-repeat you find over and over in products--and it'd be a royal PITA to build it in a framework that's basically a thin layer on top of HTML.
- aaronblohowiak 5y ago
  they are linked through the "target" attribute which has a default value. since there is only one source and one destination in the demo, it can be omitted entirely. (5:03 in the video)
- cabalamat 5y ago
  > Did anyone else understand how the data actually flows across these pieces? I'm guessing it goes into a database somewhere. But I'm not sure how, what the database's schema is, or how easy it would be to interact with it from an external program.
- csomar 5y ago
  I hate to be that guy but what the guy is doing is adding "complexity"; he did not create zero-cost patterns or abstractions that reduce 10 lines of code to 1 while allowing for fine-grained customization of any step. As someone who builds apps for a living, the 90% of the time is spent on the "last minute" customization and fighting the stack. This is why I pick widely used stacks. They might not be better but I have higher chances of finding someone else who had a similar issue. Also I'd never use something that hides what is pushing/pulling from the server let alone configure the database structure for me. That would be really fun as I already spend 1/2 my time debugging what went wrong and finding it. Working with a black box is not going to help in any of that. There is a reason why people steer to React/Redux. The world is not a Todo list app, and most of the time you need some creative work and you need something agnostic that can be programmed. Coupled with GraphQl, you can have a nice separation between your front and back ends and test them appropriately.
AngeloAnolin 5y ago
While stuffs like these are laudable, it still merits a lot of consideration that for these to be impactful to companies / business / 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.
peterthehacker 5y ago
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?
- nickthemagicman 5y ago
  > You don’t have to worry about piping data around your app, syncing, binding state to interface components, etc. You just construct your app. Apparently, you just construct your app.
  - peterthehacker 5y ago
    I meant how the implementation works behind the scenes. Like what’s the persistence layer? How are changes subscribed to and persisted? ACID transactions? ect. Looks like we’ll have to wait and see what the author publishes later.
jack_riminton 5y 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
- goingindi 5y ago
  Could you tell us more about jumpstart? Is it well supported, who provides it, are there similar templates that don’t work as well and why?
  - jack_riminton 5y ago
    https://jumpstartrails.com/ https://jumpstartrails.com/ There are a few other Rails template frameworks but I think this is the most popular. It basically has a lot of the boilerplate stuff that you need to do for setting up a SaaS product. Of course because it’s rails a lot of the stuff is supplied in gems
    - hdjjhhvvhga 5y ago
      Over $700/year if you want to develop more than one website seems a bit too much to me.
      - jack_riminton 5y ago
        Works out pretty well if you think of it in dev time spent imo
ollerac 5y ago
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/ https://remaketheweb.com/ [1] https://www.meteor.com/ https://www.meteor.com/
- deleted 5y ago
  [deleted]
- foobarbecue 5y ago
  +1 for referencing meteor. I'm still flummoxed every time I try a new web framework and it can't do what meteor did without mountains of boilerplate. I starred your repo and will give it a try soon.
  - taylorwc 5y ago
    I’m 100% convinced I would never have learned to code without Meteor… it made so many things simpler. You should check out wasp[0], which has a lot of philosophy in common. Disclosure: I am investor in the company behind the project. [0] https://wasp-lang.dev https://wasp-lang.dev
et1337 5y ago
Is it just me, or is this ASP.NET ViewState from 15 years ago?
- RyanGoosling 5y ago
  No you’re right. This guy is blowing gas
sergioisidoro 5y ago
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.
- goingindi 5y ago
  Could you elaborate on the cookiecutter template?
  - nsomaru 5y ago
    https://github.com/pydanny/cookiecutter-django https://github.com/pydanny/cookiecutter-django
daneel_w 5y ago
Great. Now we can all build a shopping list or to-do list application in minutes.
parhamn 5y ago
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 https://synth.app/blog/todos-the-hard-parts-part-1
- WA 5y ago
  Good read, because it’s true. Yes, we can have more abstraction. They are called libraries and frameworks. React being one in the JS world so that nobody has to write document.querySelector all the time. But programming is about edge cases and thus, many, many rules how things should behave in every imaginable scenario.
midrus 5y ago
Or just use Django
meetups323 5y ago
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.
- bdcravens 5y ago
  I suspect that many of the apps we all have deployed to production isn't what we would consider "production ready" when looking at someone else's app.
- kashkhan 5y ago
  Who isn't looking forward to 99% of front end developers being out of jobs if apps can be built in minutes instead of months.
  - radus 5y ago
    Definitely not looking forward to 99% of any group being out of jobs.
    - deleted 5y ago
      [deleted]
    - rahimnathwani 5y ago
      Hit men?
      - pietrovismara 5y ago
        Billionaires.
troysk 5y ago
Ruby-on-Rails with some magical gems(devise, simpleform etc.) can do this even faster and probably better looking.
georyb 5y ago
I wonder how it deals with any migrations? What if I decide to connect different components later? Or add a new attribute / column?
- ukd1 5y ago
  Came here to ask this; it's essential to have this, as likely you'll do something like was demo'd in the video - start with a single list, maybe move to multiple. Note, the items disappeared.
deleted 5y ago
[deleted]
supermatt 5y ago
i think we have a different idea of "production ready". but its a cool utility for rapid prototyping, definitely. reminds me of xforms.
npilk 5y ago
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.
pftburger 5y ago
Generally from my measly experience developing apps, it’s not coding them that takes the time
ste-up 5y ago
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 https://easylists.app
bilater 5y ago
I agree with the philosophy even if I'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: https://www.hackyexperiments.com/process https://www.hackyexperiments.com/process
brian_herman 5y ago
Are we going to see a version of Visual Basic being reconstructed with javascript soon?
lewisjoe 5y ago
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?
- MK_Dev 5y ago
  What are your top frameworks that satisfy all of these (assuming developer productivity is a factor)?
- krishvs 5y ago
  This is an excellent framework to validate a low-code/ full-stack frameworks as ERPs are complex beasts. I would like to also add( especially for opensource low-code frameworks ): #6 Can it generate pdf and excel reports #7 Does it support scheduled jobs/tasks #8 Can you choose to execute logic in the backend ( this does not seem to be the case for retool etc which only support frontend js ) #9 Can I extend with my own js, css and backend libraries #10 Is it horizontally scalable and stateless #11 Drag and drop ui builder that is not hard-coded to a single css framework and that generates code that can be modified. I have not yet found any low-code framework that fits into these benchmarks
  - kinj28 5y ago
    Check Dronahq.com it does most of the things you highlighted 1) frontend app building (responsive) 2) backend logic builder with automation and BPM 3) pdf gen 4) add your own js, build your own controls Disclaimer - I work at DronHQ
Wronnay 5y ago
So not GitHub Repo with the framework? His blog is very interesting. Great ideas but the realized products are very similar to the competition...
- kenan7 5y ago
  Indeed. Worth to read.
tmpz22 5y ago
“Writing books in minutes not months” Who else is excited to read it?
seph-reed 5y ago
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)
- cestith 5y ago
  What if I need a dependency tree on my tasks? What if I need to share the list with others - does this attach data to a session cookie or something? What if I need to subtask an item. What if I need to time track the start to finish? What if I need to estimate that? What if I need a title and description for each task, and a way to associate blocking, duplicates, etc? A TODO list is one thing, but this isn't going to replace Mattermost or Jira tomorrow.
dukeofdoom 5y ago
Browsers should supported a rich set of UI components, optimized so that AI can compose interactions between them.
- gervwyk 5y ago
  This would be great. Would save so much cost if there was a standard for component, for a lot of apps especially internal business applications, building and maintaining component libs just adds so much cost over and over. At some point the web should ask how many component libs is really necessary. We’ve been working on Lowdefy [1] which might be useful if you are looking to build apps by just focusing on the interaction / data binding of the application. [1] - https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy
nottorp 5y ago
So... would 128 Gb ram be enough for one of these apps?
88913527 5y ago
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.
MisterBastahrd 5y ago
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's faster and easier than building a card house by hand, but you lose most ability to manage business-complexity logic. Most senior devs can code something from scratch that will automagically create a crud form in a couple hours. The reason we don't do it is that it's not useful.
cestith 5y ago
So it's a declarative display-oriented language with late binding embedded into HTML? It's... a web-native form of a FileMaker Pro app?
- TheCowboy 5y ago
  FileMaker flies under the radar and most people haven't even heard of it. It seems like it was neglected over the years as well. They also took some strategic directions that weakened the utility such as lack of interoperability, but it seems like they've improved. The only reason I even know it exists is because I was brought in to one company to try to untangle a mess of business logic and UIs that had accumulated into an insane mountain of technical debt. That said, I do appreciate what it is trying to do and the power it gives users. There are a lot of niche products trying to "reinvent" aspects of FileMaker, but no real general replacement exists that I'm aware of.
  - cestith 5y ago
    I've worked places where the main app driving the business office was written in A5 or FileMaker Pro. One was an ISP that ran ISP management from some ISV and it charged us per maximum active subscriptions. I forget the name. I made a decent chunk of my living for a time taking custom small business apps in QuickBasic or similar systems and plugging them into a graphical interface. My method was sometimes more complex, but often it was translating to OOBasic and using Open Office forms for the interface. One could get auto-saved updates white a database breaking it, and even trigger an update in the UI if someone changed data in the DB from another connection. It's not surprising someone else thought of such a system. It's just surprising they don't acknowledge any awareness of existing solutions. Our industry is often blind to its own history which is fairly said since we're the ones who facilitate massive data storage and archival.
gervwyk 5y ago
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 https://github.com/lowdefy/lowdefy
deleted 5y ago
[deleted]
benoror 5y ago
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.
- eurasiantiger 5y ago
  Agreed. Design needs to be driven by the data model, and the data model needs to be driven by business entities. Any top-down approach is nonsensical, exactly as you describe.
- gervwyk 5y ago
  Totally agree with this!
dgdosen 5y ago
So, where's the Github link for Conductor Framework?
deleted 5y ago
[deleted]
foxbee 5y ago
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. If you are interested, check out the repo: https://github.com/Budibase/budibase https://github.com/Budibase/budibase It's used at Amazon, IBM, F1, Deloitte, NHS, and more. I'm the co-founder of the project and I hope you don't mind me posting - it felt relevant.
dorianmariefr 5y ago
Went from 0 to App Store and Google Play in one month with a react-native app with a webview to a rails/stimulus/react app
javajosh 5y ago
Building prototypes in minutes, apps in months.
jbellizzi 5y ago
Anybody else bothered by the 105 uncommitted files?
deleted 5y ago
[deleted]
IceDane 5y ago
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.
- omgitsabird 5y ago
  > 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. Are you implying they are a sub-par developer because they haven't committed changes to 105 touched files? That doesn't seem like a great metric to judge someone by.
- cloogshicer 5y ago
  Your negativity is detrimental to this thread. Please check your tone, this is not the quality people writing on HN should strive for.
  - iio7 5y ago
    What are you talking about? His tone is fine as is the critical points he is making. He's right.
    - cloogshicer 5y ago
      I actually agree with most of the criticism they wrote but that's beside the point I was trying to make. This tone is not how you should talk to another human being.
      - 127 5y ago
        Tone policing is also how truth and justice are buried in the name of fitting in.
system2 5y ago
I wonder since when started calling basic pages apps.
srcreigh 5y ago
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.
lmilcin 5y ago
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.
- digitalsin 5y ago
  I like this story.
  - deanCommie 5y ago
    You shouldn't. It's a terrible story in burning bridges, losing trust with leadership, and basically optimizing for being RIGHT over actually fixing any problems or enacting change. If you find yourself considering doing anything of the sort, you should just quit. And you might say what's the difference - he ended up quitting anyway. Yeah, but he also did so by ruining his reputation with a bunch of people who you might say you don't care about their opinion, but they'll talk to other people whose opinion you DO Care about, and they won't tell a charitable version of this incident. They'll just say that you weren't a team player, that you don't know how to collaborate with others, and to not hire you. What he should have done is spent a week writing a document to senior leadership preparing an executive overview explaining the process he would follow, tools to use, and a detailed breakdown of the estimate of building this system (by someone else mind you) - in a timeframe that he understood the leadership would accept as reasonable - but longer than 1 hour. Then he should have presented the document to them.
lanevorockz 5y ago
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.
aljgz 5y ago
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.
intelix 5y ago
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 https://github.com/intelix/reactiveservices some runnable examples are here: https://github.com/intelix/reactiveservices-examples 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.
sevensunsets 5y ago
You still aren't building apps in minutes. It will still take weeks or months. Sick of types of these articles.
aphroz 5y ago
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.
deleted 5y ago
[deleted]
wokwokwok 5y ago
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.
rsanek 5y ago
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.
wolfadex 5y ago
This reminds me a lot of https://lamdera.com/ https://lamdera.com/, 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't get those annoying popups saying something like "there are new features, refresh your page".
frankiesardo 5y ago
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/ https://blitzjs.com/
mbrodersen 5y ago
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.
gil0mendes 5y ago
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'll say nothing :)

460 points by stevekrouse 5y ago

fouc 5y ago

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

boomskats 5y ago
Yeah - the claims in the title are a little contentious (at least on first glance), but the Lab Notes section of the site is a gem. And it's a _beautiful_ site. Really. It might just be a netlify theme or whatever, but I'm really enjoying reading it.

vinaygaba 5y ago

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/ https://notion.so/

jimbob45 5y ago

This wouldn'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's problems if only they knew they could use this instead of hiring six nerds to build their simple app. I'm still blown away by how many people don't realize stuff like this and Wix/Squarespace + AWS would fulfill their business needs for basically free.

mattnewton 5y ago

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?

tiborsaas 5y ago
You still need to spend those months, but the prototype will be up real fast :) But the title is not wrong, a month consists of weeks, days and minutes :)
- tracyhenry 5y ago
  It's not wrong, but it's clickbait.
olah_1 5y ago
Yeah two-way data binding isn’t exactly new. What I would like to see more of is “no backend” type solutions that allow you to just write front ends that leverage existing auth, databases, etc eg. Sia, Gun, Dfinity, etc
- cabalamat 5y ago
  > What I would like to see more of is “no backend” type solutions that allow you to just write front ends that leverage existing auth, databases, etc I did the opposite of that, since I see the data structures are the "real" thing and the layout of the web pages as merely froth on the top. My Frambozen[1] framework is all backend, in that you define your database schema, and then it builds parts or all of the front end (the web pages) for you. (It's written in Python and uses the MongoDB database). So for example, you might define a table like this: class Foo(MonDoc): name = StrField() description = TextAreaField(monospaced=True) aNumber = IntField(minValue=0, maxValue=100) minSpeed = FloatField(title="Minimum Speed, mph", minValue=0.0) maxSpeed = FloatField(title="Maximim Speed, mph", minValue=0.0) favouriteDrink = ChoiceField(choices=DRINK_CHOICES, showNull=True, allowNull=True) fruitsLiked = MultiChoiceField(choices=FRUIT_CHOICES, desc="tick all fruits this person likes") tickyBox = BoolField() aDate = DateField() lastSaved = DateTimeField(desc="when this foo was last saved", readOnly=True) aDateTime = DateTimeField(title="A Date and Time") anything = ObjectField(desc="can contain anything", default=["any", "thing"]) favouriteBook = FK(models.Book, allowNull=True, showNull=True) And then it can auto-generate a page to view / edit / create a single record in the table, and another page to listr all the records in the table. 1: https://github.com/cabalamat/frambozenapp https://github.com/cabalamat/frambozenapp

mcintyre1994 5y ago

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?

Lapsa 5y ago

You should try Microsoft WebForms. Build apps in seconds!

deleted 5y ago
[deleted]

echelon 5y ago

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.

qsort 5y ago
> Especially if the resulting output is literate, self-documenting, and easily amenable to later human editing. Big 'if' right there. I can see 'solved' problems being increasingly automated away (how many times do we need to write basic auth systems?), but in order to automate the entire pipeline you would need: - a specification language so detailed that it's basically a programming language - assumptions so strong they're liable to be subtly wrong ML can help, but we've all seen codex... we aren't there yet.
gumby 5y ago
A “MySpace for Apps”. Many would consider that a condemnation, and probably a well deserved one too. But I mean it in a positive sense: the democratization of development, the way DTP democratized printed expression (back when that was a thing). Also hopefully means programmers can spend their time on more interesting and value-adding effort rather than having to take the time to simply put a button on the screen. Of course the dream of rapid development goes back to FORTRAN.
- cabalamat 5y ago
  > the democratization of development Like HyperCard, back in the day.
  - gumby 5y ago
    One of the few successful examples.

gmaster1440 5y ago

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 https://www.youtube.com/watch?v=MCZ3YgeEUPg

PaulDavisThe1st 5y ago
Ditto for both power- and hand-tools used for most craft.
eof 5y ago
Some instruments are made for beginners. I think the same correlations would be easy to find in software productivity. C++ :: Saxaphone Wix :: Recorder; or something
- zwieback 5y ago
  I know C++, played some sax in my youth and recorder as a child. If only I knew Wix, then I could connect the two dots in a 2D graph!
- RcouF1uZ4gsC 5y ago
  > I think C++ is more like the French Horn Excerpts from https://houghtonhorns.com/why-is-the-french-horn-so-hard-to-play/ https://houghtonhorns.com/why-is-the-french-horn-so-hard-to-... The French horn is widely considered to be the most difficult brass instrument to play. The modern-day double French horn is actually a combination of two horns (F, Bb) that share a common mouthpipe and bell. Because the partials (available notes in the harmonic series) are so close together in the third octave, the horn’s most comfortable range, it is fairly easy to miss or “crack” a note. Conversely, the partials that occur in the trumpet’s most comfortable range are comparatively more spread out, allowing for a bit better accuracy and more control. Another reason for the horn being difficult to play lies in the fact that it has the widest range of all the brass instruments: nearly as high as a trumpet and almost as low as a tuba. Additionally, the horn mouthpiece is small and deep, requiring fine muscle control and embouchure development. The mouthpipe is long and slender, creating more resistance for the player to overcome. Because the horn faces backwards–as opposed to the other wind instruments–the horn player must work extra hard to balance and blend with the other members of the wind instrument family.

matchbok 5y ago

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.

hermannj314 5y ago

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.

growt 5y ago
GPT3, is that you?
- hermannj314 5y ago
  Sorry, I am just a developer. I'm not sure if I am supposed to be insulted by that comment or not.
  - ctenb 5y ago
    Definitely not GPT3
  - abj 5y ago
    I wonder if this is something GPT-3 would say. Am I GPT-3?
    - hermannj314 5y ago
      This entire exchange made me think of Blade Runner. Maybe I am not even human after all. How would I know...
      - growt 5y ago
        Sorry, it wasn't my intention to insult you! Just one more question: Suppose you're in the desert and you see a tortoise turned on its back. What do you do?

jawns 5y ago

I've been using the free, open-source React Admin https://marmelab.com/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 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.

cpursley 5y ago
React Admin works really well with Hasura: https://github.com/hasura/ra-data-hasura https://github.com/hasura/ra-data-hasura
arey_abhishek 5y ago
Since you mentioned Retool and react admin, take a look at Appsmith. It's an open source low code tool similar to Retool. https://github.com/appsmithorg/appsmith https://github.com/appsmithorg/appsmith I'm a co-founder of the project and we started this because there was no open source project that made it easy to build highly custom admin panels and internal tools.
topspin 5y ago
I've done three production apps with React Admin and its predecessor ng-admin. They do what they say on the tin. Integrating custom components with React Admin works well and is a tremendous affordance.
gervwyk 5y ago
Check out https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy which is open-source. We created Lowdefy (co-founder here) to built web apps fast and it is really working well for us and our customers. We’ve already rolled out a few enterprise level apps in record time and the platform really scales well as apps evolve and get really complicated. Even developing apps as a team is a breeze since you are working with yaml / json which is easy to code review, copy, paste, find and replace. l

heavyarms 5y ago

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.

stevenpetryk 5y ago
Seems pretty clear to me that this isn't designed to build scalable apps. And that's okay—it's still a very thought-provoking exploration into a different paradigm of persistence.
gervwyk 5y ago
We went with the JSON / YAML approach and we are able to build some really complicated apps fast using Lowdefy - so it can scale, but only if you implement some sort of DSL to express logic. Check out https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy

chacham15 5y ago

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?

oh-4-fucks-sake 5y ago
Exactly. Just wait until you have to auth with a 3rd party API, fetch the request async, do a transformation on the response, load it into a 3rd party UI grid, add custom styling to the grid, and then add sorting and filtering on top. And this isn't anything particularly exotic--it's a wash-rinse-'n'-repeat you find over and over in products--and it'd be a royal PITA to build it in a framework that's basically a thin layer on top of HTML.
aaronblohowiak 5y ago
they are linked through the "target" attribute which has a default value. since there is only one source and one destination in the demo, it can be omitted entirely. (5:03 in the video)
cabalamat 5y ago
> Did anyone else understand how the data actually flows across these pieces? I'm guessing it goes into a database somewhere. But I'm not sure how, what the database's schema is, or how easy it would be to interact with it from an external program.
csomar 5y ago
I hate to be that guy but what the guy is doing is adding "complexity"; he did not create zero-cost patterns or abstractions that reduce 10 lines of code to 1 while allowing for fine-grained customization of any step. As someone who builds apps for a living, the 90% of the time is spent on the "last minute" customization and fighting the stack. This is why I pick widely used stacks. They might not be better but I have higher chances of finding someone else who had a similar issue. Also I'd never use something that hides what is pushing/pulling from the server let alone configure the database structure for me. That would be really fun as I already spend 1/2 my time debugging what went wrong and finding it. Working with a black box is not going to help in any of that. There is a reason why people steer to React/Redux. The world is not a Todo list app, and most of the time you need some creative work and you need something agnostic that can be programmed. Coupled with GraphQl, you can have a nice separation between your front and back ends and test them appropriately.

AngeloAnolin 5y ago

While stuffs like these are laudable, it still merits a lot of consideration that for these to be impactful to companies / business / 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.

peterthehacker 5y ago

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?

nickthemagicman 5y ago
> You don’t have to worry about piping data around your app, syncing, binding state to interface components, etc. You just construct your app. Apparently, you just construct your app.
- peterthehacker 5y ago
  I meant how the implementation works behind the scenes. Like what’s the persistence layer? How are changes subscribed to and persisted? ACID transactions? ect. Looks like we’ll have to wait and see what the author publishes later.

jack_riminton 5y 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

goingindi 5y ago
Could you tell us more about jumpstart? Is it well supported, who provides it, are there similar templates that don’t work as well and why?
- jack_riminton 5y ago
  https://jumpstartrails.com/ https://jumpstartrails.com/ There are a few other Rails template frameworks but I think this is the most popular. It basically has a lot of the boilerplate stuff that you need to do for setting up a SaaS product. Of course because it’s rails a lot of the stuff is supplied in gems
  - hdjjhhvvhga 5y ago
    Over $700/year if you want to develop more than one website seems a bit too much to me.
    - jack_riminton 5y ago
      Works out pretty well if you think of it in dev time spent imo

ollerac 5y ago

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/ https://remaketheweb.com/ [1] https://www.meteor.com/ https://www.meteor.com/

deleted 5y ago
[deleted]
foobarbecue 5y ago
+1 for referencing meteor. I'm still flummoxed every time I try a new web framework and it can't do what meteor did without mountains of boilerplate. I starred your repo and will give it a try soon.
- taylorwc 5y ago
  I’m 100% convinced I would never have learned to code without Meteor… it made so many things simpler. You should check out wasp[0], which has a lot of philosophy in common. Disclosure: I am investor in the company behind the project. [0] https://wasp-lang.dev https://wasp-lang.dev

et1337 5y ago

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

RyanGoosling 5y ago
No you’re right. This guy is blowing gas

sergioisidoro 5y ago

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.

goingindi 5y ago
Could you elaborate on the cookiecutter template?
- nsomaru 5y ago
  https://github.com/pydanny/cookiecutter-django https://github.com/pydanny/cookiecutter-django

daneel_w 5y ago

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

parhamn 5y ago

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 https://synth.app/blog/todos-the-hard-parts-part-1

WA 5y ago
Good read, because it’s true. Yes, we can have more abstraction. They are called libraries and frameworks. React being one in the JS world so that nobody has to write document.querySelector all the time. But programming is about edge cases and thus, many, many rules how things should behave in every imaginable scenario.

midrus 5y ago

Or just use Django

meetups323 5y ago

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.

bdcravens 5y ago
I suspect that many of the apps we all have deployed to production isn't what we would consider "production ready" when looking at someone else's app.
kashkhan 5y ago
Who isn't looking forward to 99% of front end developers being out of jobs if apps can be built in minutes instead of months.
- radus 5y ago
  Definitely not looking forward to 99% of any group being out of jobs.
  - deleted 5y ago
    [deleted]
  - rahimnathwani 5y ago
    Hit men?
    - pietrovismara 5y ago
      Billionaires.

troysk 5y ago

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

georyb 5y ago

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

ukd1 5y ago
Came here to ask this; it's essential to have this, as likely you'll do something like was demo'd in the video - start with a single list, maybe move to multiple. Note, the items disappeared.

deleted 5y ago

[deleted]

supermatt 5y ago

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

npilk 5y ago

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.

pftburger 5y ago

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

ste-up 5y ago

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 https://easylists.app

bilater 5y ago

I agree with the philosophy even if I'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: https://www.hackyexperiments.com/process https://www.hackyexperiments.com/process

brian_herman 5y ago

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

lewisjoe 5y ago

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?

MK_Dev 5y ago
What are your top frameworks that satisfy all of these (assuming developer productivity is a factor)?
krishvs 5y ago
This is an excellent framework to validate a low-code/ full-stack frameworks as ERPs are complex beasts. I would like to also add( especially for opensource low-code frameworks ): #6 Can it generate pdf and excel reports #7 Does it support scheduled jobs/tasks #8 Can you choose to execute logic in the backend ( this does not seem to be the case for retool etc which only support frontend js ) #9 Can I extend with my own js, css and backend libraries #10 Is it horizontally scalable and stateless #11 Drag and drop ui builder that is not hard-coded to a single css framework and that generates code that can be modified. I have not yet found any low-code framework that fits into these benchmarks
- kinj28 5y ago
  Check Dronahq.com it does most of the things you highlighted 1) frontend app building (responsive) 2) backend logic builder with automation and BPM 3) pdf gen 4) add your own js, build your own controls Disclaimer - I work at DronHQ

Wronnay 5y ago

So not GitHub Repo with the framework? His blog is very interesting. Great ideas but the realized products are very similar to the competition...

kenan7 5y ago
Indeed. Worth to read.

tmpz22 5y ago

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

seph-reed 5y ago

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)

cestith 5y ago
What if I need a dependency tree on my tasks? What if I need to share the list with others - does this attach data to a session cookie or something? What if I need to subtask an item. What if I need to time track the start to finish? What if I need to estimate that? What if I need a title and description for each task, and a way to associate blocking, duplicates, etc? A TODO list is one thing, but this isn't going to replace Mattermost or Jira tomorrow.

dukeofdoom 5y ago

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

gervwyk 5y ago
This would be great. Would save so much cost if there was a standard for component, for a lot of apps especially internal business applications, building and maintaining component libs just adds so much cost over and over. At some point the web should ask how many component libs is really necessary. We’ve been working on Lowdefy [1] which might be useful if you are looking to build apps by just focusing on the interaction / data binding of the application. [1] - https://github.com/lowdefy/lowdefy https://github.com/lowdefy/lowdefy

nottorp 5y ago

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

88913527 5y ago

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.

MisterBastahrd 5y ago

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's faster and easier than building a card house by hand, but you lose most ability to manage business-complexity logic. Most senior devs can code something from scratch that will automagically create a crud form in a couple hours. The reason we don't do it is that it's not useful.

cestith 5y ago

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

TheCowboy 5y ago
FileMaker flies under the radar and most people haven't even heard of it. It seems like it was neglected over the years as well. They also took some strategic directions that weakened the utility such as lack of interoperability, but it seems like they've improved. The only reason I even know it exists is because I was brought in to one company to try to untangle a mess of business logic and UIs that had accumulated into an insane mountain of technical debt. That said, I do appreciate what it is trying to do and the power it gives users. There are a lot of niche products trying to "reinvent" aspects of FileMaker, but no real general replacement exists that I'm aware of.
- cestith 5y ago
  I've worked places where the main app driving the business office was written in A5 or FileMaker Pro. One was an ISP that ran ISP management from some ISV and it charged us per maximum active subscriptions. I forget the name. I made a decent chunk of my living for a time taking custom small business apps in QuickBasic or similar systems and plugging them into a graphical interface. My method was sometimes more complex, but often it was translating to OOBasic and using Open Office forms for the interface. One could get auto-saved updates white a database breaking it, and even trigger an update in the UI if someone changed data in the DB from another connection. It's not surprising someone else thought of such a system. It's just surprising they don't acknowledge any awareness of existing solutions. Our industry is often blind to its own history which is fairly said since we're the ones who facilitate massive data storage and archival.

gervwyk 5y ago

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 https://github.com/lowdefy/lowdefy

deleted 5y ago

[deleted]

benoror 5y ago

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.

eurasiantiger 5y ago
Agreed. Design needs to be driven by the data model, and the data model needs to be driven by business entities. Any top-down approach is nonsensical, exactly as you describe.
gervwyk 5y ago
Totally agree with this!

dgdosen 5y ago

So, where's the Github link for Conductor Framework?

deleted 5y ago

[deleted]

foxbee 5y ago

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. If you are interested, check out the repo: https://github.com/Budibase/budibase https://github.com/Budibase/budibase It's used at Amazon, IBM, F1, Deloitte, NHS, and more. I'm the co-founder of the project and I hope you don't mind me posting - it felt relevant.

dorianmariefr 5y ago

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

javajosh 5y ago

Building prototypes in minutes, apps in months.

jbellizzi 5y ago

Anybody else bothered by the 105 uncommitted files?

deleted 5y ago

[deleted]

IceDane 5y ago

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.

omgitsabird 5y ago
> 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. Are you implying they are a sub-par developer because they haven't committed changes to 105 touched files? That doesn't seem like a great metric to judge someone by.
cloogshicer 5y ago
Your negativity is detrimental to this thread. Please check your tone, this is not the quality people writing on HN should strive for.
- iio7 5y ago
  What are you talking about? His tone is fine as is the critical points he is making. He's right.
  - cloogshicer 5y ago
    I actually agree with most of the criticism they wrote but that's beside the point I was trying to make. This tone is not how you should talk to another human being.
    - 127 5y ago
      Tone policing is also how truth and justice are buried in the name of fitting in.

system2 5y ago

I wonder since when started calling basic pages apps.

srcreigh 5y ago

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.

lmilcin 5y ago

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.

digitalsin 5y ago
I like this story.
- deanCommie 5y ago
  You shouldn't. It's a terrible story in burning bridges, losing trust with leadership, and basically optimizing for being RIGHT over actually fixing any problems or enacting change. If you find yourself considering doing anything of the sort, you should just quit. And you might say what's the difference - he ended up quitting anyway. Yeah, but he also did so by ruining his reputation with a bunch of people who you might say you don't care about their opinion, but they'll talk to other people whose opinion you DO Care about, and they won't tell a charitable version of this incident. They'll just say that you weren't a team player, that you don't know how to collaborate with others, and to not hire you. What he should have done is spent a week writing a document to senior leadership preparing an executive overview explaining the process he would follow, tools to use, and a detailed breakdown of the estimate of building this system (by someone else mind you) - in a timeframe that he understood the leadership would accept as reasonable - but longer than 1 hour. Then he should have presented the document to them.

lanevorockz 5y ago

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.

aljgz 5y ago

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.

intelix 5y ago

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 https://github.com/intelix/reactiveservices some runnable examples are here: https://github.com/intelix/reactiveservices-examples 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.

sevensunsets 5y ago

You still aren't building apps in minutes. It will still take weeks or months. Sick of types of these articles.

aphroz 5y ago

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.

deleted 5y ago

[deleted]

wokwokwok 5y ago

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.

rsanek 5y ago

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.

wolfadex 5y ago

This reminds me a lot of https://lamdera.com/ https://lamdera.com/, 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't get those annoying popups saying something like "there are new features, refresh your page".

frankiesardo 5y ago

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/ https://blitzjs.com/

mbrodersen 5y ago

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.

gil0mendes 5y ago

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'll say nothing :)