Again? Can this end with anything other than failure? It'd be nice if it could, but that seems outside the realm of possibility.<p>Aside from this never having worked, and being, so far as we can all tell, incompatible with the level of fine-tuning to everything from the backend to the pixel positions of the UI that people want, there are very serious problems with the business model (or absence thereof)<p>Some telling snippets from the article:<p>"Everything you build on Dry.io right now is stuck there."<p>“Later on, we’re going to be making on-premise stuff, so if you want to run it on a local server or something like that,” Cassimatis promises. “But for now, yeah, stuck on our platform.”<p>"Dry.io also has no business model, yet."
> Cassimatis believes that Dry.io doesn’t have any competitors.<p>There is a huge category of providers that do this:<p><a href="https://www.gartner.com/doc/3695317/magic-quadrant-enterprise-highproductivity-application" rel="nofollow">https://www.gartner.com/doc/3695317/magic-quadrant-enterpris...</a><p><a href="https://www.g2crowd.com/categories/low-code-development-platforms" rel="nofollow">https://www.g2crowd.com/categories/low-code-development-plat...</a><p>I wish tech journalists would do their research.
Cool, regardless of other commenters' advice, I think you should go forward with this. I run a dev shop and I have done this with Rails and boy, does it save you a lot of time (and thus, money). But, you should ensure there isn't a learning curve for your platform. It should be in a UI that's familiar to someone who is familiar with building their apps manually. Otherwise, it defeats the purpose. As for worrying about pixel perfect designs, don't worry about those, they're the easy part. The difficult part will be the parts that contain the majority of value for a business - the backend. Frontend is as simple us throwing in a nice UI framework and mixing and matching color themes. It is good enough and works well for <i>most</i> clients. The ones that require pixel perfection probably aren't your target audience as it has a lot to do with the frontend than the backend.<p>Contrary to popular belief, there is a lot of money in this. I sincerely wish you luck and hope you succeed.
I'm trying to understand how this would actually work. A lot of app development for a mid-size CRUD app is around encoding business logic and handling edge cases.<p>Let's take a specific example. Say I'm writing a software to help manage weekly CSA (box of veggies) deliveries. Sometimes a driver will miss a delivery, and in that case, you want three options:<p>(1) Fully refund the customer for that week<p>(2) Let them another receive another delivery the next day<p>(3) Give them company credit<p>If (2) happens, the driver component needs to receive a notification for the next day delivery.<p>Is this in scope of dry.io? If it handles this kind of thing, how?
In what sense is this AI? You can of course call any computer technology AI in that it is "artificial" and "intelligent" but this looks a lot like a domain specific language for describing web apps and not anything that has to do with any sort of inference.
I read the article but didn't watch the video but isn't this essentially code generation/metaprogramming that we already have? In rails you don't have to write a fraction of the code that actually runs because its generated for you.<p>Also the AI part is very worrying. To me this sounds like a programming language where no one exactly knows what the rules are and every update to the training model could break everything. Imagine trying to debug an issue when there is no documentation or any knowledge on what is going on.
I understand the use of AI is mandatory this days for any startups, but basically this is Microsoft Access 2019 if it was online.
Access once solved the problem of creating small inhouse applications for departmental use. Since then a magnitude of online services offered the same solutions, so you don't need to create anything from scratch now.<p>I'm sure there is a market for Dry.io solution, just can't estimate how big it really is.
You have a lot of buzzwords in that headline. I’m not planning to read TA because the buzzwords made my eyes glaze over.<p>No offense intended, but I thought someone might appreciate knowing.
There are a couple points to be made on this.<p>1. This is less of a "AI" issue, more of a UI/UX for specialized tools issue. Dreamweaver comes to mind especially; the moment you are trying to get something that can be flexible and accommodate different needs it is mostly about learning the tools. Often, the result is that learning the tool itself is almost harder than learning to code.<p>2. Any code that you generate via AI will most probably be crap. A huge part of coding is making it understandable and easy to touch later on; how can you do this without AI that has a proper understanding of the worlds (probably on the level of a AGI).
An interesting difference between this and "traditional compilers" is that since it's targeted to user-facing applications and the output is intentionally hands-off, there are incentives for dry to subvert developers. Imagine inserting unrequested ads or silently reselling end-user analytics for extra money. The developer might never even know, let alone be able to fix it.
Despite the (predictable) skepticism, there are some real enterprise use-cases for something like this being served by similar "self-serve" tools. I'd be willing to take a look.