Just to be clear, porting a drag-n-drop interface to VS Code is not meeting developers where they are.
Interesting point. Personal opinion here - I do not think that drag and drop is only for non-developers. A great example of this is the gaming industry in Unity/Unreal engine. These tools are effectively low-code but also incorporate drag and drop to allow developers to build whatever they can imagine but faster. Drag and drop should be an extension to the developer’s arsenal, not be the only way a developer can interact with the system.
* what I want now is a little more and a product I plan to move from prototype to production soon (tm)
As I said in a peer comment, I get the game engine analogy, it's close, but there are enough differences that it doesn't carry enough weight to make it a point of justification. They've also had over a decade plus to develop and get lots of complaints. But note, there are 2-4 options in the game dev space, because it is so hard to build a compelling experience. Low code. / drag-n-drop is littered with shitty products and race to the bottom competitors. Also, my statements can generalize to DnD based solutions for more than frontend, to things like node red, iffft, zapier et al
Since Excel is on the front of HN, I'm reminded that Excel is the OG and most successful low code product in history
As a backend focused dev who's very interested in low code, I've tried them all and they fall short after the honeymoon. Most recently Plasmic.app, had (has) great promise once their product matures. They nailed the developer facing workflow. The problem is twofold, (1) that the UI is big, slow, and buggy (2) the code that comes out the other side is super heavy. A blank component added 50% to my bytes shipped.
The hard question to answer is what does that interaction point look like? Why is the backend dev even tasked with doing the frontend?
You'll face a point where you will have to decide who your paid product is for, and every drag-n-drop for developers has pivoted to non-developers, because getting something that most developers actually love has proved impossible to date.
We think our market area is wildly similar to the early days of gaming engines, echoing what pbardea commented earlier. We are providing the game-engine or the "tool-engine" if you will.
The reason backend developers are often tasked with building frontends on internal tools is because the frontend developers are often allocated fully to the core revenue-generating customer facing product.
As of today, we don't solve every use case pure code can. But over time we think there is a path to becoming the default and standard for this category of software, especially if we can nail the programmability aspect to win over developers.
I get the game engine analogy, used it myself, but it's a little apples and oranges. Very different personas, if you only have one persona for developers or even backend devs, you haven't narrowed down enough yet.
Re: "super heavy" output: A blank component should result in one corresponding div. Maybe you're weighing the API client library? You can codegen pure React modules if you don't want the loader library itself.
If you have any specific feedback on the UI, would love to listen. Thank you!
An unhydrated card like the testimonial example was 28k via code gen.
I put tons of feedback in that video, if your teams are not watching it, you are missing out immensely
Despite not pulling a lot of punches in my stream, I still think Plasmic is closest of all I have tried to a developer friendly, maybe lovable in time, product
It will definitely be easier to sit through