|
I really also have to question the attitude of the founders. I found a lot of the quotes out there about this product insulting. "Building the backend, however, is like stacking wine glasses: it’s not that hard, but if you make a mistake it’s a bigger issue to deal with." If building a back-end is not hard, then why do I need your product? It should just be easy as long as I test it and do a lot of checking to make sure the wine glasses don't fall. What makes me think that the founders of all people are the ones I should trust to make these decisions when the pitch for the product is insulting the people who actually build solid back-ends? I've built a lot of back-ends that people actually use and not once has it been an easy task. Even the jobs that took me less than a day I would never say were easy; perhaps I simply discovered humility and actually lived long enough to see what happens to systems 10+ years after they are used by real people. I would also apply the above to front-ends - they are never just "easy." But front-ends you can mess up and fix them without too much catastrophe beyond perhaps annoyed/lost users/etc. When back-ends fail or are designed badly, we lose data, ability to gain insight into our business, can't satisfy company/client requirements, and so on. These are much more serious consequences than your app not being responsive or shiny, or looking like it came from a wannabe Craigslist fan. Both are important to success, but let's not pretend that our apps could be the next Google if we could only sweep away that pesky back-end. It seems on some level the founders agree here that back-ends going wrong are really a problem, but why does this start-up suddenly guarantee success here? Just the fact of using node.js + <insert db> does not make a back-end good. Using things the community generates also does not make something good. Back-ends are anything but one size fits all, or even one size fits more than a few people. Producing a good back-end is actually very hard for anything beyond a prototype and an often misunderstood art form. I don't get this notion I see a lot that xyz programmer is a "front-end" developer and abc programmer is a "back-end" developer. You are not a developer at all if you can't learn anything you put the time and effort into I would argue. At best, you are a beginning programmer who knows a few libraries that are focused on one or more aspects of a system. In practice, you don't always get to work in jobs in all roles, but you still have to know about all of them to be an effective developer. I would never hire someone for my team beyond a junior-level that was not strong in all areas. There are of course specialists as well, but these are more for things like crypto/security, embedded programming, and so-on rather than your general application code. Simply put, if you can't learn front or back-end development to meet the requirements of your development tasks, you have no business doing them. As a corollary, it is important to know your strengths and hand-off to people who might be more artistic or more familiar with a language, but it does not absolve you of learning about the other parts of your system. So I also ask, what part of this protects a programmer who is inexperienced, clueless, or otherwise too busy to care about the back-end to not structure or combine otherwise solid parts (for the sake of argument) of this tool from creating a back-end that is a complete disaster because of the sum of its parts? I think this app discounts the close relationship of a system as a whole between the front and back-end. A few things were mentioned already like syncing data offline, but I have additional concerns. Note for example that caching, data modeling, and asynchronous programming for example are all very closely related to both databases/working with data and building user interfaces. I cannot tell you how many times I have had to build little tricks to makeup for technology or real-world issues that involved doing things like encoding some bits of information in a database key, field, whatever to make something more cacheable, O(1) lookup, or whatever to ensure the front-end experience was better, or even just deal with deficiencies from other parts of the code. I think the notion of all parts of the system needing to work with a consistent approach, philosophy, and quality is highly demonstrated by the current approaches in Clojure using ClojureScript, React, and Datomic for example where the notion of using immutable data makes it both easier to cache information nearly indefinitely, and to create UI that renders quickly due to the ability to use deltas and caching as bi-products of immutable data. There are many other systems and frameworks that share this view of "turtles all the way down." Another problem with the product here is I don't see a good story of how someone can legitimately develop a solid back-end with this tool. The problem is not necessarily the tooling, but the customer that presumably uses this already lacks the skills to create a back-end. What about the product being visual suddenly mitigates this? It seems from the literature available that the implication is that a lot of back-ends are super simple and require merely basic CRUD operations. In my experience, this is anything but for most people. Business users for better or worse like to throw tons of rules, conditionals, corner cases, and so-on when developing a system. It is your responsibility if you are a developer to stop this, but I hardly think the customer here is one of those people who knows enough to do this correctly or at all. The tool looks like it can give you the ability to add all these rules to be something more than super simple CRUD, but the problem is not the rules working or not, but the fact that adding them and using them usually causes countless bugs and severe consequences without someone who knows what they are doing actually checking with proper thought. Assuming you are building a CRUD app with none of the aforementioned complexity, I hardly see why someone would not just use something that is either stupidly simple or closely matches their domain to do this like Salesforce, Sugar CRM, Excel, whatever. This product seems to give no immediate value proposition over a naive CRUD app over existing tools, and takes away just enough power to not make it something that can compete with a more complicated solution like existing web or app frameworks. Additionally, I have encountered the truth is that there are few things in an application that matter more than data. One could argue the end-user functionality is king and while this is often true, you can still get away with not the greatest user experience and product but be successful. Judging the front-end is very subjective at times, but the back-end is rarely anything but subjective. I have seen countless front-ends that made millions for companies based on nothing more than Access, Excel, FoxPro, VB, Salesforce, Drupal, Wordpress, whatever. One thing they would all tell you though is their data (and even logic) was super important to them. Another reality is a lot of these people already have the data in abc form and need to transform it to xyz form(s) to take the next step. This solution does not seem to have any obvious story here. That seems to discount a lot of people with existing businesses and products. Doing ETL or any sort of transformations is exceedingly complex, and the person using this tool would hardly be the person to do it. I just can't imagine everyone else doing the heavy lifting of getting existing data into a form to use with this tool, then stop the heavy lifting to use an unknown quantity in an online visual builder. I have many more concerns and arguments here, but to cut a long rant slightly shorter, putting everything else I said aside, what about the tree structure itself? Trees in web browsers seem like an awful fit. They are even a particularly awful fit in desktop UI beyond a few levels. Programming "back-ends" is notorious for deeply nested logic and complicated flows. I don't see how modeling this in a tree is a good fit. A DAG is a bit better, but my real issue here is that it is so visually literal. I can already imagine being driven crazy with identation. Undoubtedly I am sure there is some work-around, solution, whatever just like in normal programming of hiding the nesting complexity by naming sub-trees, collapsing things, etc in the way we collapse things into files, classes, objects, namespaces, etc. This though seems to work a lot better in a text editor with some visual capabilities rather than in a purely visual editor. I've seen structural editors with Lisp that try to do fun things here too, but that's another topic. Anyway, my point is that the UI itself seems like it won't scale well and introduce complexity in groking the code it is supposed to simplify. Generally, the problem with this product and most in the same space is that as you take away control from what someone can do here, you get diminishing returns. The reason some things work with bad back-ends is because they are super simple. This looks anything but simple and I have no nice way of saying this, but it seems targeted at an odd group. Are you going after high school - early 20 year olds beginning programming? If so, did it occur to you that these people are often fickle with spending money in this area, and often don't have the money anyway? Who is your real customer beyond what is mentioned in the article. Sorry, but I don't see a future for this tool and I can't see why any logical person would invest the time and money to couple themselves to it. Shame on YC for investing in this one as well, you've been duped I think. |