[HN Gopher] Show HN: A Visual IDE for React
___________________________________________________________________
Show HN: A Visual IDE for React
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!
Author : tscepo
Score : 418 points
Date : 2022-05-13 06:30 UTC (16 hours ago)
(HTM) web link (dev.aspect.app)
(TXT) w3m dump (dev.aspect.app)
| 91edec wrote:
| Congrats on shipping.
| PhillyG wrote:
| Would this make learning React easier?
| tuyiown wrote:
| No design principle, no explicit constraints on code base, no
| explicit supported scope.
|
| Surely there is some kind of React component that won't work well
| with this, the unsuspecting will discover this too late.
| [deleted]
| can16358p wrote:
| I don't believe we need an IDE for React, it will end up dead
| like Dreamweaver or FrontPage.
|
| 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.
| basisword wrote:
| Dreamweaver has existed for 25 years and it's still around.
| can16358p wrote:
| Well MS-DOS is still around.
|
| But nobody uses it because the industry moved to more
| efficient software after seeing there are better ways to
| solve the problem.
| macray wrote:
| https://previewjs.com/ does that
| trenchgun wrote:
| Looks great!
| Kyro38 wrote:
| It's there some kind of equivalent for Angular components ?
| fwouts wrote:
| Hey! Author of Preview.js here :)
|
| 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!
| tscepo wrote:
| Been thinking about this a lot the past few days. The main
| reason this isn't yet integrated into vscode is to allow
| designers to edit, like in webflow.
| realharo wrote:
| Something like https://storybook.js.org/? Not a VS Code plugin,
| but similar idea (though it does a lot more).
|
| 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...)
| [deleted]
| rylandking wrote:
| Similar is https://stackbit.com/. I've used it to make my React
| website visually editable so my marketers could have a WYSIWYG.
| ramraj07 wrote:
| I've deployed serviceable small websites for my family and
| friends when I was a kid with Dreamweaver and Frontpage. As
| long as they support the marquee tag what are you complaining?
| noso wrote:
| Watched the "get stated" video to the end and gave a great
| overview of how helpful the tool can be while building react
| apps.
|
| Awesome work and well done!
| sktrdie wrote:
| https://utopia.app/ also does this
| hobofan wrote:
| Utopia doesn't "also" do this, they are doing something far
| more useful (bidirectional visual editing of the code) that
| could actually end up making its way into many people's
| workflow (it's just a shame that they don't support Typescript
| yet).
|
| 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.
| BillSaysThis wrote:
| Can I bring my own component library? And CSS variable files?
| qwerty456127 wrote:
| I agree 10000%. A way to design browser-based GUIs the visual RAD
| way makes me drool. I hope it grows and flourishes.
| the_other wrote:
| Hey, well done for getting something functional working and in
| the public eye.
|
| > 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.
| kristiandupont wrote:
| > I strongly dislike Tailwind and similar tools because they
| prevent this kind of coding/debugging
|
| 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.
| bzxcvbn wrote:
| What are the advantages, really? I used to use tailwind for
| my site, but then I realized I was essentially writing plain
| CSS in some DSL. Writing the plain CSS directly and using a
| few CSS variables for things like color and spacing
| simplified the whole thing greatly.
| diatone wrote:
| For personal projects it might be overkill depending on the
| scope. But if 2+ people are working on a constantly
| evolving system, shipping new features, and want
| consistency in the design system? It's a solid foundation.
| edwinyzh wrote:
| >> A similar tool got shown here on HN...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...
|
| 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.
| anonymouse008 wrote:
| Holy cannoli this is amazing!!
|
| 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!
| beshur wrote:
| Sorry, I could not go farther in the video after watching the
| narrator trying to accurately click on all those inputs,
| dropdowns etc. simultaneously saying "writing this in code would
| be annoying".
|
| In my opinion using mouse pointer to click things on screen is
| annoying when it comes to programming.
| noduerme wrote:
| Generally when I watch a code demo I appreciate if the
| demonstrator doesn't use keyboard shortcuts, because I'm trying
| to focus on the actions not the way you get to those actions.
| And having a mouse move around gives you a moment to think
| about the last thing they said and how it fits with your
| projects.
| danielvaughn wrote:
| I think it comes down to preference, but ultimately I agree
| with you. There are a lot of misconceptions about "code", and
| when people talk about how code is either slow, hard, annoying
| etc, they're speaking in the abstract and not being specific.
| At the end of the day, "code" is really just typing what you
| want instead of dragging around a mouse. It's like saying "I
| like to use my mouse to copy and paste instead of typing cmd+c
| cmd+v, it's faster". It doesn't make any sense.
| [deleted]
| mbreese wrote:
| I find mocking things up is better done visually. Whether
| that's pen/paper, Illustrator, or a GUI builder like this. I
| think they serve the same purpose. The only difference is that
| with this, you're closer to getting a final asset you can tweak
| with code. GUI builders have a long history. But the best of
| them produce code you can commit to git.
|
| 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.
| user3939382 wrote:
| FrontPage only has one thing to say to you in response to
| this insult:
| criley2 wrote:
| I find that mocking is best done by product/designers and not
| engineers, and that the skills to make a wonderful user
| experience are about as opposite from the skills of being a
| talented js/typescript/react/redux/devos etc engineer as can
| be.
|
| 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.
| solarkraft wrote:
| Visual editors are great! However closed source development tools
| tend to not do very well.
| runako wrote:
| One of the top dev tools in the world is Microsoft's Visual
| Studio (not VS Code). It's doing fine. Similarly, JetBrains
| makes an incredibly popular set of closed-source dev tools[1].
|
| 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.
|
| 1 - https://news.ycombinator.com/item?id=21796793
| upupandup wrote:
| Open source doesn't make software inherently better, more
| reliable or secure. Without a dedicated development direction
| that is supported financially, you are banking on the
| generosity of the github author.
|
| 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.
| solarkraft wrote:
| I don't have an issue with paid tools either. I have an issue
| with non-extensibility and relying on small companies that
| may go out of business at any moment.
|
| 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.
| lstamour wrote:
| Just a tip for the demo video - check out Descript.com for an
| easy way to edit out the "ums" in videos and screen recordings. I
| use it regularly to tighten up a recording quickly. I likely
| wouldn't edit or make videos in the first place if I didn't have
| Descript. No relationship to disclose, just a happy customer.
| math-dev wrote:
| Is it via class or functional components ?
|
| Keep up the good work - maybe jetbrains will buy / fund you!
| tscepo wrote:
| Right now we export class components, but the option to export
| functional components is coming soon. Will likely default to
| functional component export.
|
| Thanks!
| qwerki wrote:
| Disappointing to see the top comments are not encouraging of your
| efforts. This is not an easy undertaking and it's clear you've
| put a lot of time into it - you should be commended. I wish you
| the best of luck and look forward to seeing more of your work!
| TimMeade wrote:
| ditto. Looks like a lot of work. Nice.
| [deleted]
| [deleted]
| tscepo wrote:
| That means a lot, thanks!
| phtrivier wrote:
| This isn't shown in the video, but does your editor comes with
| pre-set "styles" or is it something that you would import
| yourself ?
|
| 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 !
| tscepo wrote:
| I set up super minimal preset styling, and yeah I think basic
| css import makes sense as a next feature. Hoping to avoid
| overly complex style inheritance.
|
| 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!
| dgritsko wrote:
| Tailwind support would be awesome. I often use Tailwind Play
| (https://play.tailwindcss.com/) when I'm "sketching out" the
| look of a new component since it's so quick to iterate and
| get immediate visual feedback, as you well know.
| danielvaughn wrote:
| I've been wondering whether it would be possible to leverage
| ML/AI to "infer" a layout from a visual mockup. So like if two
| elements have the same X position, they're assumed to be left
| aligned with one another. If three elements are the same width
| and sit side-by-side with the same distance between them,
| they're assumed to be a 3-grid column. Etc etc.
| tscepo wrote:
| We're actually in review on the Figma plugin store for
| exactly this. Should be out soon.
| danielvaughn wrote:
| Very nice. One pain point I've noticed with AutoLayout is
| that once a layout is set, it's very difficult to "just
| shift something around", which is what's so nice about a
| visual editing tool to begin with. The benefit of an
| automated layout inference tool is that it could
| theoretically let you toggle the layout off, do your quick
| and easy shifting, then turn it back on and let the tool
| infer the changes you made.
| your_challenger wrote:
| The video doesn't work
|
| { "error": { "code": 402, "message": "Quota has been exceeded for
| this project. Please visit the Firebase pricing page to learn
| more." } }
| epberry wrote:
| Best kind of error message.
| your_challenger wrote:
| Works now
| tscepo wrote:
| Ah thanks for the heads up, just fixed!
| etchalon wrote:
| This is an absolutely awesome thing. Great job!
| onion2k wrote:
| It reminds me of Visual Basic or early versions of Dreamweaver to
| an extent (which is a huge compliment). That enabled a massive
| number of people to make apps who wouldn't otherwise have been
| able to, but after using it for a long time most users abandon
| the visual UI builder in favor of the code editor.
|
| 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.
| Doches wrote:
| This, very much so. One of the (few) things I genuinely love
| about modern frontend web development is the speed of the edit
| loop with React and hot reloading. Look, I'm an engineer;
| _writing code_ is my jam, not clicking pretty widgets in a
| (nice!) UI. It's genuinely faster for me to turn an image in my
| head into a functioning component by just writing out
| Typescript or CSS; the abstractions are less leaky, and the
| escape hatches are literally at my fingertips rather than
| requiring an extra jump or two.
|
| Put another way: if I have to take my hands off the keyboard
| I've already lost.
| diatone wrote:
| Playing devil's advocate here: if this graphical interface
| could be manipulated without mouse clicks, you're still
| interested? Alternatively: if there were some high bandwidth,
| low latency feedback loop between you and this app, an order
| of magnitude faster than how you currently iterate on working
| with React, you'd consider it?
| [deleted]
| csmeyer wrote:
| This is a pretty slick app! One thing I notice is that there are
| a lot of options in things like the insert menu with tags that
| aren't super popular. Maybe prioritizing more commonly used
| options would help with the UX? Also once you're logged in,
| there's no way to get back to the landing page without logging
| out.
| tscepo wrote:
| Will make these changes in a few minutes, thanks for the heads
| up!
| csmeyer wrote:
| Also, is there a way to make more than one project/rename
| projects? Another UI thing, I think having those side panels
| expand on hover is a little distracting, maybe use a chevron
| to expand/collapse? If you have contact info on the page I'd
| be happy to give some more feedback, don't want to spam HN
| [deleted]
| bibinou wrote:
| > (c) Metacode, Inc. dba Aspect
|
| Is this the Metacode that got YC funding?
| tscepo wrote:
| Yes. I'm super passionate about software that creates software.
| Edmond wrote:
| Kindred spirits...I would like to get in touch, my email is
| in my profile.
| Karawebnetwork wrote:
| Out of topic, are you worried that Meta might target you at
| some point?
| edding4500 wrote:
| Cool project, congrats you finished it up to this point :)
|
| 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.
| Mappleton wrote:
| Look promising, but just logged in and poked around and couldn't
| figure out how to get elements on the canvas. Or do much of
| anything. Some of the interaction design seems quite odd and
| difficult to use (eg. all the sidebar accordions open on hover
| rather than on click. And clicking on elements in the "insert"
| dropdown doesn't insert them.).
|
| 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.
| tscepo wrote:
| I really appreciate the feedback, thanks! Talking to designer
| friends and updating UX as we speak, based on this.
| idkwhoiam wrote:
| This reminds me of the Ext Designer tool from many years ago that
| was very useful in building forms with the Ext.js framework.
| pavlov wrote:
| Good luck, looks great already!
|
| 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.
| [deleted]
| tscepo wrote:
| Yeah I can learn a lot from React Studio--I think a lot about
| keeping the learning curve down for growth, so I'm glad you
| pointed that out. I'm focusing on enterprise sales next and
| actively looking for people to help with that, so again I think
| you're right. Thanks for the feedback!
| ed wrote:
| > enterprise sales
|
| +1. Most devs would keep building but really sales is the
| right move. Product looks great! GL finding your customer and
| early revenue.
| pavlov wrote:
| You're welcome, and I hope you crack this -- the industry is
| stuck in a local maximum with tools based on what are
| essentially 1970s concepts (unstructured code-as-text and
| unstructured vector graphics).
|
| 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 facade 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."
| bmitc wrote:
| Seems interesting. As a note, I am not able to view the video on
| an iPad. (Not complaining. Just FYI.)
| lordofgibbons wrote:
| I'm seeing a MIME type not supported for the video on Android
| Firefox
| simonmorg wrote:
| The website does not tell me much. With this tool, what are the
| optimum use cases?
|
| 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.
| [deleted]
| echopom wrote:
| I'm a bit fed up with those "IDE" for web attempts.
|
| 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.
| pendar747 wrote:
| Despite your negative tone, I think you have a point. There are
| many project like this. I'm working on another one at the
| moment and I have compiled a long list of similar projects.
| There is definitely a need for a tool that can create UIs
| visually. IMO such a tool needs to have interoperability with
| code, as in changes to the code reflect in the tool and changes
| in the tool make reflect back in the code.
|
| 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.
| hutzlibu wrote:
| Do you also have concrete criticism of this project or just
| generic general complaints about the topic?
|
| 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.
| upupandup wrote:
| Think he's point was that GUI products in this space is
| extremely difficult to get it right due to the explosion of
| edge cases and general complexity.
|
| 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.
| polydevil wrote:
| Well, is says that the website itself was build by the tool.
| Non-semantic tags, divs instead of links, buttons instead of
| links, a lot of inline styles (which is a bad practice), deep
| nesting. So inline styles will make caching css impossible,
| so high load times, not good for performance. Deep nesting
| makes the problem even worse. So the result is a slow bloated
| inaccessible code, but the result may look ok. If all you
| want is a pretty picture - than yeah, it is a great tool.
|
| 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.
| tgv wrote:
| It's not just fatigue. I also have such a project. It allows
| you to build using bootstrap, but with expressions, loops,
| conditions and a data store. It would be pretty easy to make a
| Vue version of it. It's a structural editor though, but it
| offers a graphical preview with limited interaction. But it's
| not good enough for the general public, and I'm not going to
| finish it, only to see the project linger somewhere in a
| obscure corner of the internet, or -worse- attract some
| attention and get a bunch of idiots making demands and threats.
| thomasfromcdnjs wrote:
| I don't think the criticism is wrong.
|
| 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.
| robenkleene wrote:
| At face value this seems like it could apply to a bunch of
| different categories (e.g., another text editor, another todo
| list, another chat app, etc...)? Yes, most new software in
| every category fails, but every once in awhile one succeeds,
| and that's how we make progress. The failures along the way
| just seem like a necessary byproduct of progress.
| delhanty wrote:
| >Yes, most new software in every category fails, but every
| once in awhile one succeeds, and that's how we make progress.
|
| +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?
| echopom wrote:
| It was never my intention to be "shitting" on anyone.
|
| 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.
| delhanty wrote:
| > Just a feeling of exasperation when seeing the product.
|
| 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
| [deleted]
| lfkdev wrote:
| Where exactly is now your problem with IDE's for webs?
| edwinyzh wrote:
| First, congrats to your new project! Secondly, although it's not
| for react, but that's exactly the same reason why I have
| developed http://liveditor.com some years ago! The idea was that
| the css inspector/tweaker and the code editor should be combined
| together and working together seamlessly.
|
| PS, I know the software might have some little issues but I'm
| going to update it soon ;)
| ghostbrainalpha wrote:
| This feels like home to me, as I was once a Dreamweaver.
| dimgl wrote:
| I like the ambition. Great project. Best of luck to you. I see
| big things coming your way.
| varispeed wrote:
| These visual tools never clicked with me. There is always a point
| that you need to code something "manually" and then switching
| back and forth is just tedious (and if you are lucky that your
| code doesn't break the tool) to the point it makes no sense to
| use such a visual tool. Maybe this is different though. I wish it
| was possible to try without having to set up an account.
| claudiojulio wrote:
| Just because I don't like to do things in a way, it doesn't mean
| my way is the only right. Congratulations to the project creator.
| I wish you much success!
| _steady wrote:
| As someone who doesn't like to watch videos, i'd have loved some
| text content on this or any page explaining the proposition
| tscepo wrote:
| Got it, added some explanatory copy. Accompanying image
| examples following soon.
| DoctorOW wrote:
| This is a really cool idea. I'm not super into React, so take it
| with a grain of salt when i say I'm surprised I haven't seen
| something like this sooner. :)
| tscepo wrote:
| Thanks!
| animal_spirits wrote:
| This looks really interesting! I like seeing more domain specific
| IDEs coming out
| simon_000666 wrote:
| I want this - but mobile first.
|
| 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.
| jesushax wrote:
| Bravo. Soon, developing point-and-click, drag-and-drop apps will
| be almost as easy as it was in 1998 with Visual Basic 6.
|
| 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!
| code_witch_sam wrote:
| or winforms and C#!
|
| 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
| tmcw wrote:
| > "Aspect is built using Aspect"
|
| That is extremely impressive.
| spyremeown wrote:
| Agreed. Bootstrapping your code with your own code shows a lot
| of self-reliance and belief in the product.
| throwntoday wrote:
| Is it really that tough to Cmd+Tab then Cmd+R?
|
| All jokes aside, good job. Creating tools to solve problems is
| always fun.
| Xevi wrote:
| I even have the browser and code on the monitor at the same
| time. And with pretty much all modern web frameworks you have a
| dev server that automatically does hot module replacement, so
| you instantly see your changes without reloading anything
| yourself.
| nkozyra wrote:
| I've never seen a hot reload that worked fast enough to not
| be annoying.
|
| 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.
| randomsearch wrote:
| > I've never seen a hot reload that worked fast enough to
| not be annoying.
|
| Then you, my friend, have never used Vite.
| dmix wrote:
| I use a vue dev server daily (both with webpack previously
| and now with the way faster vite) and it's pretty much
| instant.
|
| 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?).
| FractalHQ wrote:
| As a Svelte developer, I can't remember the last time I had
| to work _without_ an instant HMR with optical state
| preservation. That sounds like a nightmare and a huge
| productivity killer.
| eurasiantiger wrote:
| The Web is a wide audience. How do you design visually for the
| people who cannot see? In other words, how does this tool ensure
| that a site built using it remains accessible at WCAG2.1 A or AA
| level?
| [deleted]
| foxbee wrote:
| This looks really neat. Your branding is awesome, and the website
| is clean, but requires a lot more content for me to take this
| product for a spin.
| cercatrova wrote:
| Any thoughts on Framer? They seem to do the design aspect as well
| as the site-building aspect.
|
| https://www.framer.com
|
| https://www.framer.com/sites
| NoXero wrote:
| I would like to start off by saying this is a very cool idea, and
| I can see the hard work and ingenuity that went into this effort.
| I think it is especially impressive if this is a solo endeavor.
| However, as someone who has quite a bit of experience with React,
| a tool like this I could see getting in my way. I don't see this
| being particularly helpful, maybe for prototyping for designers.
| It looks like a solution looking for a problem to me, honestly.
| Anyway, at least it is cool, and shows off your skill! Thanks for
| sharing.
| elanning wrote:
| Great idea. I think UI/UX designers would love a tool like this.
| Especially if they could import React components made by the
| development department.
| krono wrote:
| It is not a unique concept, but there's absolutely room for
| another implementation/offering.
|
| 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/
| schkolne wrote:
| Here are some other exciting products in the space:
| https://www.plasmic.app/ https://www.builder.io/
| https://clutch.io/ https://builderx.io/
| https://dynaboard.com/ Each one has a slightly different take
| on the problem, and some of these are turning out to be quite
| useful for teams. I'm very curious to see how things will
| shape up. I find Aspect to be particularly beautiful, a nice
| clean UI great work!
| dgb23 wrote:
| If the components are headless. Otherwise it makes more sense
| to do it the other way around. Designers write components that
| just render stuff, which then gets wired up by devs to be
| state/effectful.
| danielvaughn wrote:
| This is what I'm doing. I've been building a "programming
| language" for UI designers. The idea is that they just
| describe the visual behavior, and then devs can wire it up
| with business logic.
| noduerme wrote:
| This is super cool. If I worked in React I would love the ability
| to build most of an MVC through a GUI like this and avoid the
| waste of time.
|
| 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.
| tepitoperrito wrote:
| You might not hate react, you might just be holding it wrong.
|
| 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.
| noduerme wrote:
| I built my own "reactive" stack a decade ago and just keep
| refining it. I wanted to de-couple template HTML from visual
| logic, and visual logic from business logic. So I model
| everything on components within components, they all
| bootstrap whatever DOM templates they need and inherit the
| same basic methods, and it's all tied together with an event
| model that handles long polling and push updates but,
| crucially, does _not_ do anything in the basic HTML templates
| other than adding a couple attributes like "role='photo-
| button'" where you need them. Server updates cascade to each
| JS component which updates the things it thinks need to be
| updated at a given time. It's more hand-coded, but it's
| easier to read and a lot easier to micro-manage.
| pc86 wrote:
| Just a few days ago someone posted some snarky HN comments on
| React's initial release thread talking exactly about HTML and
| JSX being hackish, and all I could think was "well... it is."
| The popularity and success of a project doesn't mean that all
| its core assumptions/opinions are good, only that the project
| is popular and successful.
|
| 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.
| noduerme wrote:
| >>The popularity and success of a project
|
| 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.
| [deleted]
| [deleted]
| chunkyslink wrote:
| Thanks for submitting this it was interesting to see. Is this an
| old project because the video example uses React Classes rather
| than functional components and hooks.
| tscepo wrote:
| Ah I used React classes out of habit--will update the exporter
| to output hooks instead. Thanks for the heads up!
| Doches wrote:
| Since you already have an exporter that produces class-style
| React components, it seems like it would be nice to have the
| option of class or functional components. I've worked on
| projects with strictly class-based components, strictly
| functional components, and a mix of both. Would certainly be
| nice to be able to select between the two flavours of
| exported components, and would make it easier to sell the
| decision to use Aspect-designed components in more codebases!
|
| (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.)
| bananapear wrote:
| Would be nice to be able to try it out or see a demo without
| having to create an account and log in
| epberry wrote:
| I just want to say that I love Aspect. I have 3 projects on here,
| 2 of which are live: https://everettberry.com/ and
| https://prcvlabs.org/.
___________________________________________________________________
(page generated 2022-05-13 23:02 UTC)