Replies: 6 comments 5 replies
-
There is always of the option of running our own fork, but there would be a lot of work in untangling the core 3d logic from the web-app implementation, But with all the features I'd like to build into CadHub, I personally can't justify doing that work right now, I would be happy to include a new fork if someone else got that working. |
Beta Was this translation helpful? Give feedback.
-
First I would like to say that I'm not that good of a programmer, I can read code and understand most of it but writing code is still difficult for me and I have trouble staying focused on long programs, so I'm not sure in what measure my opinion is worth to you but I'm giving it anyway... I think you are doing a great job trying to build an online editor/hub. To be able to program online is a different thing but for a lot of people a very important one, at least for me it is. What is happening in the background is for a lot of people not that important I think as long as it is clear that it is working, without to many lag and that it is possible to save and export their work. Online making 3d objects is for me the way to go, making it possible to work on the same project at home and at work. Just some of my thoughts... |
Beta Was this translation helpful? Give feedback.
-
Dropping support for CascadeStudio would be a loss for CADHub in my opinion. The interesting concept of CascadeStudio is that it contains the potential to a real alternative to larger packages like FreeCAD and it can draw new and young users to coding in Javascript. I wonder whether it is really necessary to integrate the modelling tools into CADhub or whether CADhub should just bring together the users of these tools to learn from each other and to stand on each others shoulders. That way it would not matter if the tool is integrated or whether the site can unite users to exchange ideas and concepts. This can only work if all users allow a liberal license on their work. People that do not want to share their work should not use this hub but start a company. There is nothing wrong with earning money for your work, but only taking and not giving feels wrong. |
Beta Was this translation helpful? Give feedback.
-
An email went out today (the 2nd of July) to all users of CadHub confirming this deprecation. Sad, but onto the next chapter. |
Beta Was this translation helpful? Give feedback.
-
Sad to see the two projects part ways, but I understand that there are deeper reasons. I am not sure which of the two to choose, so will follow both for the time being. :-) |
Beta Was this translation helpful? Give feedback.
-
Oh no, I just read this post now. Sad to see that your project is leaving CascadeStudio (and therefore, OpenCascade.js). I feel like the type of bundler used by either project shouldn't be so much of a deal breaker, but I can understand that in reality it sometimes is. In case you ever think of changing your mind and coming back, let me know 🙂. Especially, since some of the major pain points with OpenCascade.js are finally getting resolved (startup times, memory consumption, reference types, default parameters, improved performance + multi threading). And with WASM64 support on the horizon, the 4GB memory limit will hopefully be a problem of the past. I will definitely keep a closer eye on your project going forward. And I wish you great success! Let's keep in touch. PS: I'm downloading all the CascadeStudio projects now 🙂 so that I can maybe eventually make them into test cases for OpenCascade.js. Hope that's OK with you. |
Beta Was this translation helpful? Give feedback.
-
This is long because I want to give full context for why we're dropping support for CascadeStudio, but the short story is:
CascadeStudio parts are being removed from CadHub. You will need to save any code you want to keep separately from CadHub. The parts will be removed no sooner than the 15th of July 2021.
The reason for the deprecation is that the integration we have with CascadeStudio is messy and hard to maintain due to a misalignment in architecture between the two projects. At this early point in CadHub's journey we've decided it's best to deprecate it so we can focus on the rest of the app and the other integrations.
More Context:
I owe a lot to CascadeStudio. It was finding the project that finally kicked me into gear to start work on CadHub (an idea I had been sitting on for some time). I always assumed that OpenSCAD was going to be hard to integrate into the web, so seeing an awesome new project, based on a BRep kernel was the inspiration I needed, and the fact that it ran in the browser meant it would be easy to integrate (at least that was the theory).
When I started building I realised how the way I was building CadHub and how CascadeStudio was made, were two very different styles. I was leaning on complex frameworks and mature compilation tools like webpack. CascadeStudio was using core web-tech with code that could run directly in the browser with no compilation step. When I then tried to mix the two, things got messy. I saw in a CascadeStudio issue there was some discussion about modules and webpack and I got the impression that a conversion to webpack would be a desired outcome and it would also make my integration easier so I set-out to convert the whole project to webpack. Even though this conversion had not been merged into CascadeStudio I went ahead starting using the branch for the Cadhub repo because it immediately solved some race-condition bugs I had been unable to fix. After some discussion it was decided that the webpack conversion was not right for CascadeStudio.
This left the Cadhub integration in a position where it will both be hard to keep up with changes to the CascadeStudio repo, but also hard to contribute back. on top of this the integration is far from perfect. we're more or less putting the entire CascadeStudio app onto the page, which means it hard to control properly, making consistency with future integrations problematic. We could continue to support CascadeStudio doing some refactoring to make it more CadHub friendly, but by that point we would have departed so much from the original project that we'll be fully supporting our own CodeCAD package, which is not a bad thing necessarily, but not something I think should be a priority right now.
One other important point is that we are effectively making a bet with any integrations that we put into CadHub, a bet that the package will be successful and users will want to share their projects using that package on Cadhub. That's why I think an OpenSCAD integration in particular is a smart move because it has a proven track record. While I think CascadeStudio has a lot of potential in some ways it's too early to tell. So dropping CascadeStudio will allow us to focus on a clean integrations with OpenSCAD and CadQuery, then prepare the path for future integrations. That's why the deprecation is the right move for us.
Thank you Johnathon Selstad (https://github.com/zalo), There wouldn't be a CadHub without his project.
What's the current state of CadHub??
I'm really happy with how the two integrations with OpenSCAD and CadQuery is coming along, we've been making incremental improvements and @franknoirot on the Core team is putting together some excellent designs ✨ for the IDE (https://www.figma.com/file/VUh53RdncjZ7NuFYj0RGB9/CadHub?node-id=633%3A0).
My focus right now is to continue improving our IDE, as well as enable saving of parts with the new integrations (OpenSCAD & CadQuery), which is why your getting this email because we want a clean swap to the new projects.
How can you be more involved in CadHub's progression?
Oooff, if you made it this far I appreciate you taking that all in. We're building CadHub for like minded folks like you so do be sure to get involved, we can't do it without your input.
Thanks,
Kurt
Beta Was this translation helpful? Give feedback.
All reactions