This is something I wish could mash with Figma in some way, so Figma edits could be reflected back into the application in an intelligent way.
I really like this. I think some folks have correctly identified that it may be incorrectly used (my opinion) as a low-code editor. It very well could be however I see it living in a different space:
There has long been attempts at getting tools like Figma to produce assets that work with engineers. What I haven't seen until Codux is a tool that takes my work as an engineer and (mostly) correctly makes it editable and "design ready" for designers.
Thats the niche I see this living in, and is one I'd like to use it for, is to take the React components created for our design system and give designers the ability to run with it to create mock ups etc. This would cut alot of translation overhead and boilerplate significantly while keeping design and engineering on the same "page" because it reflects the changes correctly based on the source and available props, bringing things closer to usable.
What a great comment! You’ve perfectly identified a big value point of Codux and have described it even better than I would :) (I’m Omer from Codux Product team). Our designers are already using Codux to manage styles and component structures, as we’re obviously building Codux within Codux.
Regarding some kind of a mash with Figma - even though we are looking at some possible ways of better synch between the tools in the future, the short answer is ‘not yet’. Even though design tools’ capabilities are getting highly advanced, they still have (and probably always have) unbridged gaps from real front-end development concerns, as you describe here.
You can obviously keep Figma in your process while still working with Codux, but we’re here to help you build & maintain front-end code visually, in collaboration with designers, but on top of the real thing.
It depends on how extensive the edits/created components are that you want to allow the non-developer to make.
https://plasmic.app experimented with bringing together design+code in this way, but we found it didn't take hold outside of small visual tweaks. We ended up taking a different approach to this specific problem - letting you build screens out of React components from your codebase (and have the screens rendered back into your app). This has worked out much better for us, as the surface area for coordination between the developer and non-developer is much narrower and less brittle as a workflow (and at the same time doesn't put an IDE in front of the non-developer).
I was kind of shocked to see that I was presented with a Wix logo and had to sign in using my Wix account (odd for a 103MB download I thought). Then, it did not detect node or git on my system and there was no way to specify where it is on my system (as far as I could tell). I hit the exit button and that was the end of my journey with Codux.
Interesting that this is by Wix. Although, I'm a little chafed that they claim its the "first visual IDE" for React when things like Henosia [0] already exist.
I had a very quick look at the demos of both Codux and Henosia.
The Henosia demo has all data hardcoded. To me that seems not a real world example. In my world the data are all variables, which usually effect the design considerably.
The Codux demo seems to work with actual code and variables for the backend developer, while at the same time the designer sees data. So that makes it more interesting.
Yes, you're right, the 1½ minute video on our website is merely hardcoded data. That's because the main purpose of that video is to show that we're able to read AND write code, and able to push to AND pull from GitHub. Obviously we work with dynamic data as well, anything else would be a missed opportunity.
If the creators are hanging out, what does "first visual IDE for React" mean when there have been other visual IDEs for React (and React frameworks like Next.js)?
This is the first visual IDE to edit React Typescript code. Even code you created outside of it.
You can run it on an existing project, and start creating pull requests to your existing code.
as long as the project fits our supported technologies.
The other tools you mentioned create code, but cannot edit existing code.
This becomes a real problem when a developer changes this exported code, which causes conflicts when someone edits it in the editor.
We edit the code directly, with visual changes translated into code changes, letting developers and designers collaborate on code and through pull requests.
> This is the first visual IDE to edit React Typescript code. Even code you created outside of it.
tbh I find this to be misleading then. Me, and I am sure many others interested in web dev, have seen products that focus on react with a visual IDE, maybe this product is way better, but it seems like a poor first impression when I immediately think "that's bullshit" about the first thing I see.
Also how does this handle complex project setups? Like lets say i have a constant that gets injected by my bundler (e.g. webpack) that produces different results based on the environment, or middlewares? How does it display individual components when it might need to load a bunch of dependencies?
> This is the first visual IDE to edit React Typescript code. Even code you created outside of it.
Utopia had two-way sync, but that project may be in a coma. Henosia I just learned about today. It's a tough-but-important problem to solve — best of luck building a successful solution!
Worse, I think they meant to say "It's only tested in Chromium based browsers, beware" and they should let you pass anyways.
I tried opening https://codux-demos.com/blueprint-css-webapp/ in Firefox but changed my User-Agent to Chrome on Windows. Everything works fine as far as I can tell. But all the network requests are slow as hell (probably HN-hug? Confirmed to be slow with cURL as well, so not because of Firefox).
Reminds me of Visual Studio drag and drop to generate UIs for Windows apps, or Xcode's storyboard for drag and drop UIs. Interestingly, Apple is transitioning to SwiftUI which is declarative. Nice to see an increase in drag and drop UI options for web apps!
Maybe it’s just me but I always found the storyboards to be a nightmare. When it works it is ok, but I would argue no faster than just writing the code. When it doesn’t work and you have to attempt to debug an issue, hoo boy. I know how to code, just let me code the UI.
Indeed, I recall Storyboards were nice for a first layout, but constraints were iffy on the Storyboard, and in the end, a lot of more complex UIs just had to be written programatically.
I remember around maybe 2013?, there was a UI component that was all the hype; the sliding options menu (where you hit the hamburger at the top and the menu would cover half the screen). I wanted to remake it and tried to do it with Storyboards and imperative code, but it never worked just quite right. When I got rid of the sliding menu UIView on the Storyboard and just wrote the UI programmatically via UIKit, it was hard to learn but the final product was a finely, tunable sliding options menu view :-)
I get a vaguely MS Access/Windows Forms feel from this, "Now you too can build Frontend Website design and not have to spend so much on developers!"
I also have to wonder if you still have to hack the code and what not how does this make it so much different from just using hot reloading features to see things?
Codux isn't meant to replace developers, we made it for them (including ourselves). And sure, it gives you a hot-reloading experience, but also much more, like the ability to visually edit your components on stage in the same place you're viewing them.
It's a shame, too, because I'm a professional React dev, and I was really excited to try this!
But there's some sort of thermocline-of-trust issue with a self-identified manufacturer of software engineering tools can't correctly detect or name my OS, nor presumably understand why this makes me wary of trusting my development loads to a tool that is packaged in this way. https://twitter.com/garius/status/1588115310124539904
Suggestion to Wix: Go take a look at how another closed-source app with excellent cross-platform support is packaged -- say, https://reaper.fm.
This website lets me pick from several different flavours of Linux in an unobtrustive, practical way.
(I mention 'practical' because I know that the idea of supporting more than one flavour of an OS is seen by newcomers as 'impractical', but that's just how we do business in Linuxville, and since we've been doing it for a while, we've got lots of examples of doing it successfully, practically, and sustainably. Welcome! Sorry about the mess!)
Instead of assuming everyone is on .deb, here are some alternatives:
Once it's possible for anyone to use the Flatpak, say, it makes sense to begin producing artifacts for common platforms like .deb for ubuntu x64 etc. Put your CI/CD on it.
But don't start there. Start with flatpak. Start with appImage. Start, if you must, with a docker image and `localhost:3000`. But whatever you do, don't equate linux with Ubuntu or even Debian, it makes everyone feel weird
Probably they're a small team that was focused on getting this working, not thinking through OS compatibility stuff except as an afterthought. Good thing that's easy to fix after the fact?
After messing around with the tutorial project I think that this is a great tool that has a lot of potential.
As developers are very particular and tend to customize their IDEs with a lot of extensions, I don't think this will replace the tools we have.
But I do think that we should be able to customize a lot more
The code editor especially should be able to receive most of the common settings such as font, theme, ...
I would also like to see some support for common utilities such as prettier and eslint. This will not replace the primary IDE but when I need to use it I expect it to do a proper job.
A lot of what you're suggesting here (prettier, eslint) is on our list, and even in the works - and I hope would reach users soon. Until we improve the experience around the built-in code editor (and perhaps even after), we've found that it's most comfortable for us to work side-by-side with Codux and our IDE of choice.
This reminded me of Storybook, and someone mentioned it on the blog post's comments
> Both in Codux and Storybook you isolate your components and render them, but this is where the similarities end :) . Now within Codux you can drill into every internal part of your component and visually edit it! you can change prop values, edit styles, and add/remove JSX elements all within the app. Every change you make results in actual source code change that you can later commit and push through git just as if you've done them in your IDE.
During the beta phase Codux is free for use, and open source projects will always have free access. In regards to open sourcing the actual project and code, we plan on releasing some of its parts back to the community, other parts will remain closed.
It works on react Typescript projects. Editing the code like a developer would. We use it side by side with vscode editing visually when it makes sense and in the IDE when it doesn't
This is awesome. I think developers would appreciate it if you include some projectional editing for the DOM tree. E.g. a toggle to switch between text-based projectional editing of the DOM and the view you have right now.
> The issues with most of design tool to React, is they don't understand how to generate CSS in responsive manner. Most of css styles unit is in pixel !
I really like this. I think some folks have correctly identified that it may be incorrectly used (my opinion) as a low-code editor. It very well could be however I see it living in a different space:
There has long been attempts at getting tools like Figma to produce assets that work with engineers. What I haven't seen until Codux is a tool that takes my work as an engineer and (mostly) correctly makes it editable and "design ready" for designers.
Thats the niche I see this living in, and is one I'd like to use it for, is to take the React components created for our design system and give designers the ability to run with it to create mock ups etc. This would cut alot of translation overhead and boilerplate significantly while keeping design and engineering on the same "page" because it reflects the changes correctly based on the source and available props, bringing things closer to usable.
Regarding some kind of a mash with Figma - even though we are looking at some possible ways of better synch between the tools in the future, the short answer is ‘not yet’. Even though design tools’ capabilities are getting highly advanced, they still have (and probably always have) unbridged gaps from real front-end development concerns, as you describe here. You can obviously keep Figma in your process while still working with Codux, but we’re here to help you build & maintain front-end code visually, in collaboration with designers, but on top of the real thing.
No thats great! I think its the perfect direction to move this!
https://plasmic.app experimented with bringing together design+code in this way, but we found it didn't take hold outside of small visual tweaks. We ended up taking a different approach to this specific problem - letting you build screens out of React components from your codebase (and have the screens rendered back into your app). This has worked out much better for us, as the surface area for coordination between the developer and non-developer is much narrower and less brittle as a workflow (and at the same time doesn't put an IDE in front of the non-developer).
How many engineers would prefer fumbling through Figma output instead of just writing it themselves?
I guess the answer to that depends on the quality of the Figma output, which is probably measured in maintainability?
0. https://henosia.com/
The Henosia demo has all data hardcoded. To me that seems not a real world example. In my world the data are all variables, which usually effect the design considerably.
The Codux demo seems to work with actual code and variables for the backend developer, while at the same time the designer sees data. So that makes it more interesting.
You can run it on an existing project, and start creating pull requests to your existing code. as long as the project fits our supported technologies.
The other tools you mentioned create code, but cannot edit existing code.
This becomes a real problem when a developer changes this exported code, which causes conflicts when someone edits it in the editor.
We edit the code directly, with visual changes translated into code changes, letting developers and designers collaborate on code and through pull requests.
tbh I find this to be misleading then. Me, and I am sure many others interested in web dev, have seen products that focus on react with a visual IDE, maybe this product is way better, but it seems like a poor first impression when I immediately think "that's bullshit" about the first thing I see.
Also how does this handle complex project setups? Like lets say i have a constant that gets injected by my bundler (e.g. webpack) that produces different results based on the environment, or middlewares? How does it display individual components when it might need to load a bunch of dependencies?
Utopia had two-way sync, but that project may be in a coma. Henosia I just learned about today. It's a tough-but-important problem to solve — best of luck building a successful solution!
An IDE should have the text in the forefront, enable all the things an IDE normally does, as well as have a preview mode where you can visually edit.
A Dreamweaver for React.
In their defense it looks like they expect you to focus on the text part in your normal editor.
But at that point they should make this a VSCode extension or something.
Having your source being modified from two programs is... silly.
BOO :( back button.
I tried opening https://codux-demos.com/blueprint-css-webapp/ in Firefox but changed my User-Agent to Chrome on Windows. Everything works fine as far as I can tell. But all the network requests are slow as hell (probably HN-hug? Confirmed to be slow with cURL as well, so not because of Firefox).
Can't say I'm suprised.
Can't say I'm surprised either.
I remember around maybe 2013?, there was a UI component that was all the hype; the sliding options menu (where you hit the hamburger at the top and the menu would cover half the screen). I wanted to remake it and tried to do it with Storyboards and imperative code, but it never worked just quite right. When I got rid of the sliding menu UIView on the Storyboard and just wrote the UI programmatically via UIKit, it was hard to learn but the final product was a finely, tunable sliding options menu view :-)
I also have to wonder if you still have to hack the code and what not how does this make it so much different from just using hot reloading features to see things?
https://www.nubuilder.com
If you go to https://www.codux.com/download on Chrome on NixOS, you are offered a .deb when you click a button named 'Linux'.
Ubuntu != Linux. Debian != Linux.
But there's some sort of thermocline-of-trust issue with a self-identified manufacturer of software engineering tools can't correctly detect or name my OS, nor presumably understand why this makes me wary of trusting my development loads to a tool that is packaged in this way. https://twitter.com/garius/status/1588115310124539904
Suggestion to Wix: Go take a look at how another closed-source app with excellent cross-platform support is packaged -- say, https://reaper.fm.
This website lets me pick from several different flavours of Linux in an unobtrustive, practical way.
(I mention 'practical' because I know that the idea of supporting more than one flavour of an OS is seen by newcomers as 'impractical', but that's just how we do business in Linuxville, and since we've been doing it for a while, we've got lots of examples of doing it successfully, practically, and sustainably. Welcome! Sorry about the mess!)
Instead of assuming everyone is on .deb, here are some alternatives:
- Flatpak (most preferred) - AppImage - Docker image - Snap (least perferred)
Once it's possible for anyone to use the Flatpak, say, it makes sense to begin producing artifacts for common platforms like .deb for ubuntu x64 etc. Put your CI/CD on it.
But don't start there. Start with flatpak. Start with appImage. Start, if you must, with a docker image and `localhost:3000`. But whatever you do, don't equate linux with Ubuntu or even Debian, it makes everyone feel weird
As developers are very particular and tend to customize their IDEs with a lot of extensions, I don't think this will replace the tools we have.
But I do think that we should be able to customize a lot more
The code editor especially should be able to receive most of the common settings such as font, theme, ...
I would also like to see some support for common utilities such as prettier and eslint. This will not replace the primary IDE but when I need to use it I expect it to do a proper job.
A lot of what you're suggesting here (prettier, eslint) is on our list, and even in the works - and I hope would reach users soon. Until we improve the experience around the built-in code editor (and perhaps even after), we've found that it's most comfortable for us to work side-by-side with Codux and our IDE of choice.
> Both in Codux and Storybook you isolate your components and render them, but this is where the similarities end :) . Now within Codux you can drill into every internal part of your component and visually edit it! you can change prop values, edit styles, and add/remove JSX elements all within the app. Every change you make results in actual source code change that you can later commit and push through git just as if you've done them in your IDE.
During the beta phase Codux is free for use, and open source projects will always have free access. In regards to open sourcing the actual project and code, we plan on releasing some of its parts back to the community, other parts will remain closed.
If you'd like something more code/dev-oriented and open-source, check out https://impulse.dev/
> Is there a (react) visual IDE that works in absolute space (like figma?) instead of enforcing responsive css rules?
https://www.hackerneue.com/item?id=33884900
> The issues with most of design tool to React, is they don't understand how to generate CSS in responsive manner. Most of css styles unit is in pixel !
https://www.hackerneue.com/item?id=33885705