Show HN: A Visual IDE for React (dev.aspect.app)
I made this because building UIs in a lexical medium like code is super annoying. I have to pre-render what I’m making in my head, and then jump between the browser and IDE to test. I was inspired by the developer console in chrome and safari since I end up editing css there because it’s ironically more convenient. Hope it’s useful!
147 comments
[ 2.8 ms ] story [ 173 ms ] thread(Our reasons for preferring one flavour or another usually depends on some combination of legacy-ness of the project (older -> prefer class components for consistency), complexity (simpler -> prefer functional components), and experience of the team (more junior -> prefer functional). YMMV, etc.)
{ "error": { "code": 402, "message": "Quota has been exceeded for this project. Please visit the Firebase pricing page to learn more." } }
All jokes aside, good job. Creating tools to solve problems is always fun.
React does it all quickly when all it's re processing is css but anything js related and it seems not to be able to treeshake down to bare minimum updates.
We're talking 750ms to 1.5s, and I admit it's still a marvel compared to things I used to have to deal with, but it's still enough to feel cludgy.
Flutter is another example of this. It's not _slow_ but if I'm sitting there waiting for even a bit I'm less likely to use the feature as an incremental tool rather than batch a bunch of things before looking or tabbing over.
Then you, my friend, have never used Vite.
These projects only recompile the code that changes, then via chunking the browser only reloads a tiny specific .js file that contained that one component matching the vue-route, so usually 10-30kb refresh (and it loads about ~10x small .js files per page), which happens before I can tab back or notice when widescreened.
Previously when I used the slower Webpack without chunking it started to take time when the project grew large. But that was long ago (3 years ago?).
Some of the more popular existing ones Framer-X (funny landing page copy claiming it is entirely unique) and Modulz:
https://designcode.io/framer-x
https://www.modulz.app/
My experience is that typing the code for components nesting inside components is not really the big hurdle when designing React views ; rather, it's getting the "layout" part of the css right.
The big value in the video seems to be the simple fact that you have a "Form" parent component where adding a child gives it roughly the right look.
But maybe I have Stokholm syndrome, and forgot how simple it was to hook up in GUI in VB3 back in the days !
Nice work !
I 100% agree, getting layout css right is the most annoying part of styling. I’m inspired by Apple’s stack views and Figma’s auto layout which make it a lot more intuitive so I think those can be the first “Aspect components” that will come out on next release.
Thanks for the feedback!
If you're a visually-driven person then this looks ace, but I think in the opposite way to the narrator. Rather than finding writing the code directly annoying and preferring an interactive way of editing components, I find visual interfaces to code really hard to work with. I suspect I think in abstractions too much for it to work for me.
Put another way: if I have to take my hands off the keyboard I've already lost.
Apologies for jumping to critical feedback! Rough prototypes are rough for good reason ;) Glad to see more of these GUI builders popping up and think this is a worthwhile avenue to explore. But might be worth spending a bit of time looking at interface design best practices. And/or getting a designer to come advise on the project.
Every 9 Month or so , we get a new attempt at fixing Web Dev lack of Visual Feedback and productivity issues.
The typical coder behind this type of project get "Mental Fatigue/ Coder Exhaust" after 6 Months as they generally ignore the complexity behind building such product and end up abandoning the project....
There is a google graveyard , but we should also build an "Front IDE / Webviewer" graveyard.
The only one I recall without googling anything : Deco[0] and PreVue[1]
[0]https://www.decoide.org/ [1]https://github.com/open-source-labs/PreVue
HN could you complete my comment with others "Front IDE / Webwiever" that have been abandoned ?
Pretty sure there is more than a dozen.
Yes, there are many attempts trying to fix the problem, that designing requires coding and yes, that is a very, very hard problem to do right.
But just shitting on something because you feel bitter about the topic (or whatever your motivation is) probably won't lead to anything interesting.
I prefer this approach - https://github.com/seek-oss/playroom Just create your components and add them to the sandbox and allow your designers to play with them.
There have been other React IDEs in the past, and they've faded off into obscurity because of factors I am not familiar with but one in which parent's comment is alluding to, the hidden rise of technical debt for last mile problems and custom requirements.
Think we are dealing really with RAD vs traditional waterfall coding approaches. Both have ups and downs but the big drawdown is the stockholm syndrome effect that comes with relying on some other party for RAD.
We haven't succeeded in creating an intuitive and robust enough tool that accomplishes this, but that doesn't mean that it's impossible. It's a technical challenge which can be overcome.
Though it would seem that something in this space will eventually attract a decent user base.
I'm basing that thought off the idea that Dreamweaver and others were once useful to different groups.
+100
Also, I'm rather uncomfortable when a "Show HN" gets dumped upon - furthermore with no actual specific criticism, let alone advice on how to improve.
What happened to that "Be kind. Don't be snarky." from the guidelines?
Just a feeling of exasperation when seeing the product.
Someone in the comments confirmed what I said
Created an equivalent for bootstrap but abandoned it for the reasons I have written.
Well maybe you're not the target market then? It looks like a no-code rather than low-code effort, and I'm hazarding a guess that you're a dev and so ...
> It was never my intention to be "shitting" on anyone.
I'm sure that you didn't.
Here's the thing: this is a "Show HN" - somebody has been brave enough to show their new thing to the community. People vary - some are much more sensitive than average, particularly in a community like this that self-identifies as not-average, and will take the mildest criticism very personally.
If something's not for you, there's always the option of not commenting, or at least starting out by saying something encouraging to soften the blow.
https://news.ycombinator.com/newsguidelines.html#comments
> I made this because building UIs in a lexical medium like code is super annoying. I have to pre-render what I’m making in my head
I'd call the pre-rendering in your head a benefit, tbh. Also.. watching your vid, the property editor being "far away" from the selected item renders this tool much less useful to me than writing code. My eyesight's bad, so I can't keep the editor and the selected object in focus at the same time. The head & eye switching is probably more annoying to someone in my position than switching apps because at least I know I'm changing context when I switch apps (although I admit, I've put up with that for 20 years so perhaps I just don't notice).
> I was inspired by the developer console in chrome and safari since I end up editing css there because it’s ironically more convenient.
Conversely, I agree with this entirely. I don't like having to bob my head around the screen when I edit CSS in the browser, but it's still MUCH faster and intuitive than doing it in a separate code editor. I strongly dislike Tailwind and similar tools because they prevent this kind of coding/debugging. A similar tool got shown here on HN recently, and the conversation circled the idea that a visual tool to edit CSS is a) so handy but b) really hard to build because it's not programmatically obvious which file to make updates too... it's still easier to keep the file hierarchy in your head (even though that's quite hard). I guess focusing on React components lets you assume the CSS is "beside" the given component.
No they don't? I use the inspector all the time to figure out what values to set. Granted, I then translate those to Tailwind in my head, so there is an extra step compared to directly copying the style but that's a very small price to pay for all the advantages that I get from Tailwind.
I mean… i know it’s hard. I’ve tried discussing patterns and our self-made “dialect”, and it’s a hard conversation. Using some 3rd party’s tooling makes it easier because you can all defer to the higher authority. But what if you actually agreed on some patterns and made that part of your process? To start with, it would feel like you were writing an overly prescriptive style guide and people would look at you funny… but what’s the difference between using using a 3rd party dialect and making up your own?
Can you point me to the post so that I can study more details? As mentioned about, the idea of my http://liveditor.com is not to edit the css for you but points you to the line of the css file so that you can edit the styles in the code editor and see the result instantly.
Keep up the good work - maybe jetbrains will buy / fund you!
Thanks!
Surely there is some kind of React component that won't work well with this, the unsuspecting will discover this too late.
Is this the Metacode that got YC funding?
PS, I know the software might have some little issues but I'm going to update it soon ;)
There are plenty of drag and drop visual React builders, but as long as they follow an unidirectional export-once workflow, they are about as useful as a Figma mockup.
Whenever I’m sitting on a bus or train for a short trip that doesn’t warrant bringing a laptop but there is a simple little tweak that could be made in 10 mins. I would like to use a tool like this designed to be used on a mobile device.
Also I think then people who only have mobile devices could also create their own software.
It grates on me that in order to build mobile web applications you need a laptop or desktop.
In my opinion using mouse pointer to click things on screen is annoying when it comes to programming.
But, I guess the real question of usefulness is how good (or sane) the generated code is.
To use an example from a different comment, if it is closer to Dreamweaver, that at least produced workable code. If it is closer to FrontPage… good luck.
When I get a feature to implement in react, I expect the mocks to completed. We do our design work in figma and it's already a wonderful tool for mocking up our react app.
The point of an 'all-in-one' mock and code tool seems strange. Is it to get rid of designers (which is bad because UX/accessibility/design is yet another skill to add ontop of the devops pile that will not be handled at a high level) or is it to get rid of the engineer (so that the product team can create a react app without an expensive coder, which is bad because shit is going to break and no one is going to know how to fix it).
Perhaps this is intended for very small companies (~single person shops) where like it or not you're doing everything so anything that simplifies the process is a value add.
The project looks very cool though, and he can definitely put together a form faster with this tool than I can writing it all out by hand. I wonder how the experience gets when you're in the weeds of custom components, hooks, props and all of the sauce that makes react complicated.