dev.aspect.app
I (mostly) jest, but yeah, this is marvelous. I'm developing a small React app this weekend, I'll use this and make sure to report any bugs or issues along the way.
Thanks a lot for making something that makes other people (me!) excited!
tbf, building a ui with an absolutely-positioned, pixel-bound presentation engine was AWFUL without a designer. anyone work with Win32 APIs back in the day? 60 lines of code just to open a window without even drawing anything on it!
building a ui in code is a lot easier with flow layout and a good component library
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.
I spent years of my life on the problem of generating useful multi-platform code from a GUI tool and integrating it into designer and developer workflows. Before giving up I made React Studio (https://reactstudio.com) which is owned by my co-founders now.
It's insanely difficult. Nobody's needs are exactly the same, and nobody can agree even on the basics of how a web app is structured: where does CSS go, how do you update your global data, etc.
The abstractions I had to build to handle that then increased the learning curve to such levels that it became more like a CAD tool where you'd practically need to train teams into a new way of thinking for them to become productive. Having traction with a few customers never seemed to translate into something scalable. (Maybe with an actual sales team an enterprise strategy could have worked.)
My original version of the product was a mobile-only UI tool that generated native code for iOS and Android. In retrospect that was a better product than trying to expand into full-blown web apps. In native, a button is a button and a tab bar is a tab bar (with small differences between UIKit and Android); in web anything can be anything, and it's a point of pride to reinvent the basics constantly, so a tool must somehow adapt to the shifting tides of how CSS must look this year.
Two more random thoughts on this topic...
I've long felt there's an important role missing in our industry. Architects don't draw a bunch of façade sketches, ask people if they look good, and then send them to construction engineers to figure out what the beige box in the drawing might actually mean. But that's how a lot of software is made. The problem is that we only have designers and programmers. The construction industry has many kind of design engineering roles in the middle, and they have specialized tools.
In my mind, the missing role is something like an interaction architect. Someone who emphatically is not a graphic designer nor a front-end developer, but an expert on the structure of applications, how UX affordances translate into maintainable and accessible UI structures, etc. (This is the kind of role I hoped to enable with React Studio, but it was a failure and I'm too burned out from the experience to ever try again, probably.)
The second thing I wanted to note is a warning example. I worked a couple of years at Facebook, and they had an internal React GUI design tool that was one of the best I've ever seen. Yet it was discontinued last year. The replacement was basically "We'll somehow make Figma do this eventually", which disappointed the people who had come to depend on the internal tool.
Facebook/Meta is known for having some of the best internal tools in the industry, and spending a lot of resources to make those tools better. Why didn't it work out? My guess is that the team required to build this complexity was too large and projected usage was too low to justify development... But it's a worrying sign that even Facebook couldn't make this kind of tooling work. There was a captive audience of users who could have been required to adopt the software if the benefits were large enough. But it just didn't seem to cross the treshold from "interesting, very cool achievement" to "compelling, we'll fall behind if we don't use this."
You mean a UX Designer? I see that role a lot
+1. Most devs would keep building but really sales is the right move. Product looks great! GL finding your customer and early revenue.
I have no better words than Mike Markkula's point 3 of Apple's marketing philosophy for you:
Point No. 3: Impute
“People DO judge a book by its cover. We may have the best product, the highest quality, the most useful software etc.; if we present them in a slipshod manner, they will be perceived as slipshod; if we present them in a creative, professional manner, we will impute the desired qualities.”
You have a stellar product - spend every waking moment polishing it. You already nailed point 1 and 2, that's why they're not included!
That is extremely impressive.
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.
{ "error": { "code": 402, "message": "Quota has been exceeded for this project. Please visit the Firebase pricing page to learn more." } }
PS, I know the software might have some little issues but I'm going to update it soon ;)
> 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.
(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.)
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.
Awesome work and well done!
These days I just prefer writing plain code as I feel the generated code is not what I want.
Some of the more popular existing ones Framer-X (funny landing page copy claiming it is entirely unique) and Modulz:
As some people pointed out, web developer demands are pretty specific and vary from person to person. To fulfill most of them would mean immense efforts.
In contrast to that, I think your idea could thrive as a `boiler plate` component generator. Add an export button that just hands you the component code and you got me hooked for some quick components.
I don't mind tools, such as low code platforms, that simplify the dev process for simple tasks - like Budibase for example. But I think these tools need purpose and an understanding of their capabilities - it would be good to know what aspect is best at.
Keep up the good work - maybe jetbrains will buy / fund you!
Thanks!
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.
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?).
Is this the Metacode that got YC funding?
Most people use dev tools as a part of their jobs. Employers buy tools for their employees. It's a good idea to make great software for developers and then to charge money for it so that you can keep shipping.
I have no problem with paid tools, I do have an issue with Stallmanism, gaslighting micro-ISV as evil, while telling OSS devs to suck it up and ask for donations to fund their widely used work.
You could arguably remediate the former issue with a good plugin API. Then again this program may not be aimed at developers, but more at designers, which may care a bit less about extensibility and covering special use cases.
I really hate React, though. Throwing logic into HTML and JSX... just feels so hackish. Like, if I want to alter states on a thing in the DOM, I want all that logic in the JS in one neat class, not mixed with control flow in a template somewhere else. /rant
Still, I think a front-end like this could actually make it a lot friendlier for newbs and also save a ton of time for people who have to work in what I consider a nightmare of a stack... either way it looks like a samurai level piece of code that will be appreciated.
Vue isn't perfect but I much prefer how it still lets you separate out various concerns. If it had half (or even 1/3) the community React does I think it could surpass React.
I think React (and Vue) are popular and successful because they meet 80% of the needs 80% of the time, and that's what you want and need from frameworks that are trying to do everything for everybody. They also make it a lot easier to go from a 6-month course into a low level coding job, and corporations are happier because the parts are more replaceable. In my mind, they're rather limited and hard to work with if you want to do anything outside the box, but there are always going to be frameworks because they solve the most common problems quickly.
A component could represent a discrete entity or thing you'd like to alter the state of. You might be able to handle that all locally in that component but beyond this limited case don't try to shoehorn state management into a view library.
I highly recommend spending a few minutes getting to know MobX which I think maps very well to the concept of business logic and state encapsulated (in one class if you'd like) and seperated from the view layer.
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.
BUT, a Vscode plugin that visualizes self-contained components with all its styles intact would be nice: like I open MyComponent.tsx and in the right pane I see it visually, without running the actual webpage or server.
It's early days and you might find that Preview.js can be a little difficult to set up in a large, complex project (working on improving that now) but please send through any feedback on the GitHub repo or Discord server, much appreciated!
SwiftUI and Jetpack Compose also support individual component previews in their respective IDEs. (https://developer.apple.com/documentation/swiftui/previews-i..., https://developer.android.com/jetpack/compose/tooling#previe...)
But nobody uses it because the industry moved to more efficient software after seeing there are better ways to solve the problem.
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.
Surely there is some kind of React component that won't work well with this, the unsuspecting will discover this too late.