CAD stuff is such a nightmare. Attempting to navigate the mixture of poorly/undocumented file formats (AutoCAD, as a perfect example) is a massive pain. Attempting to get any form of generic viewer in the browser, or convert the files from one format to a common format is nearly non existent. This is just for 2D, don't even get me started on the clusterfuck which is 3D. AutoCAD have a "solution" which is just to use their cloud platform...because that's what everyone wants, right? To upload their most sensitive drawings to a US based company's servers, somewhere.
We've ended up using several hacks around link removed' C# implementation, which seems to be one of the few tools in this space which you can programatically interact with. If i have the opportunity to say one thing directly to the AutoCAD/AutoDesk guys, please, God, allow some form of offline SDK, and clarify your incredibly confusing, hard to navigate website, and expensive and lackluster offerings. All I want is a web based DWG/DXF viewer, which i can load files into from a (java or C#) stream, no cloud/SaaS nonsense, and works well. Apologies for the rant.
All of this is done on purpose to maintain locktivitiy of your Designers into a platform. If it was commercially beneficial to make interoperable file formats between the big commercial CAD packages they would do it tomorrow.
The best you can hope for is decent .STEP / .iges file export and then import to the system you want.
Many workflow in computer aided engineering analysis involve exporting CAD data using .STEP files.
This is exactly why I warn people about relying on Fusion 360 too heavily. Fusion 360 is a good piece of software and they let hobby users have it for free, but Autodesk loves vendor lock-in. If they decide to pull out the rug or fold you're left in a very bad spot. From what I understand, Adobe does the same thing with Photoshop's native format.
Just look at the history of their DXF format, which was hailed as their way of enabling interchange, but has perpetually been under-specified and lagged way behind the AutoCAD internal DWG format. It's not like that was an accident, they don't want you to be able to reliably take your drawings somewhere else. You need to be sure that any conversions of engineering drawings are perfect, so they make it 99% compatible to tout interchange, while the uncertainty from that last 1% of coverage makes it questionably useful in reality.
The CAD/CAM/engineering simulation industry in general is really bad - full of extreme vendor lock-in, onerous licenses and draconian DRM.
Disclaimer: I have never used this, and I am not sure it does what you want but I thought it might be relevant to your interests. I have used some of Aspose‘s other tools and they worked quite well, FWIW.
Thanks for the suggestion, but i can say with a firm authority, that the Apose suite of everything is absolutely horrible. Their Word/Office offerings, and their CAD stuff just don't work. Their marketing team, however, are absolutely brilliant (i'm not accusing you of being a marketer, just that their products are usually the number one result whenever you search for anything, their site design is great, as are their Q&A/forums). Their products are super slow (in part due to the huge amounts of obfuscation and licensing) and have some pretty horrible bugs and disparate features. I'll continue having a pipe dream of some true viewer. If i wasn't so busy with work at the moment i'd love to make an open source dwg/dxf viewer similar to what the great guys at openjscad (https://openjscad.org) are doing.
As someone who has been in the file format space for a very long time, I've always been impressed with Aspose. I was one of the founding members of https://poi.apache.org. Later, I went to work for a competitor of Aspose. At some later point, I used their products for work.
I can't speak about their CAD product but I haven't found anyone that comes even close to their support of the MS Office formats. Do you have an alternative suggestion?
i have almost zero knowledge of CAD, so can anyone comment on whether being able to run an industrial-strength CAD application inside a web browser is something that people want? What use cases are driving this massive effort?
It absolutely is something that companies want (not necessarily individual people).
After a certain scale the biggest problem in CAD is not the actual 2D or 3D drawing, its file and data management. Most of the CAD industry is actually more focused on this as a problem to solve, businesses will spend fortunes on it. In the product design world its called PLM (Product lifecycle management) and in the Architectural wold its called BIM (Building information management). You can think of it as being similar to a combination of software version control, documentation systems, bug databases, specification systems, and even continuous integration systems. Almost every CAD package has its own PLM/BIM system and some are very powerful.
The move to browser-based CAD enables you to build PLM and BIM systems that aren't file based, but are backed by a database and have versioning inherently built in. CAD parts or drawings are no longer discreet files but objects in a DB.
My background is in product design and SolidWorks (dating from the 90's) and Creo (can be traced back to the 80s as Pro/E). Both of these feel very dated now. The new kids on the block are AutoDesk Fusion 360 (cloud-based, using a DB, but with a native front end) and OnShape (Fully Cloud/Browser based, original Solidworks team, https://www.onshape.com/). Take a look at OnShape if you want to be amazed at what is possible in the browser! The 3D rendering is all done client side but with a live WebSocket connection to their servers for the Parametric Kernal and Constraint Solving, it's very clever.
Someone using a PLM system may not need to view every detail of the design, so being able to create lightweight clients in a browser is helpful.
I have been involved in STEP [1] for quite a long time, there has always been the expectation that it could be implemented as a database. I'm currently on the fringes of the work to map the PLM standards onto RDF/OWL/SKOS.
Thanks, thats an aspect that didn't occur to me. I have some experience with EDA (Electronic Design Automation) systems at the hobbyist level, and managing/versioning even simple design artefacts can be a pain. I can see how pro-level CAD would present considerable challenges.
That said, there is obvious scope for vendor lock-in when designs are cloud hosted.
There is unfortunatly vendor lock in with all “pro” cad. It’s a bit like Photoshop, you can take the output jpeg or bmp, even the layers and use it else where but no other software has full comparability with the psd format.
Vendor lock-in is just the cost of doing business.
Industrial CAD for cars and planes is CATIA, and that isn't AutoCAD. It uses too much memory to fit in a browser except as a remote desktop type application.
AutoCAD, which is architectural CAD, has been in flash (AutoCAD WS) for more than 6 years so if flash can handle it, WebAssembly can handle it.
OnShape is mechanical CAD has been pretty successful in pure JavaScript in the browser: https://onshape.com
SolidWorks is coming to the browser soon I understand as well.
AutoCAD is not just the Autocad Architectural product. That may be the most dominant niche, but they produce most of the other CAD tools as well.
AutoCAD Electrical is huge for industrial controls work - it's hard to say, IMO, whether architectural or electrical AutoCAD is more dominant in its field. Other products are used for PCB design, but for any discrete wires in machines, buildings, etc. it's almost universally AutoCAD. Solidworks doesn't even have a product. And Autocad Electrical is ideal for low-powered browser work, because it's just 2D line drawings with an occasional component wireframe.
They also produce Autocad Inventor (and Fusion 360), which are mechanical CAD packages. Inventor is definitely a contender with Solidworks, CATIA, Pro-E, and other mechanical CAD.
A car's sheet metal may have 80% probability to be designed in CATIA, but the press that forms it has (pulling numbers out of a hat) a 20% chance to be modeled in AutoCAD Inventor, a 90% chance to be wired to an AutoCAD Electrical schematic, and a 95% chance to be located in a building blueprinted with AutoCAD Architectural.
AutoCAD didn't start out as an Architectural product, it was just the first CAD system that could run on a microcomputer, it was originally marketed as a mechanical design system for smaller companies. It was also available a long time before people had even thought of a Building Information Model.
What I am trying to say is that Autodesk Inventor, Autodesk Fusion 360, and many of the other products he mentions are not technically AutoCAD. I was differentiating, as I thought others were, between Autodesk the company and AutoCAD the specific product.
What I'd really like is an open-source program with equivalent capabilities to those of SolidWorks 2005. It was sufficient for our needs then and would be sufficient for our needs now, had licenses not expired.
Browser-based apps tend to disappear or change, and we need to reference/alter drawings and assemblies on decadal timescales.
Dabbled in CAD in school and shadowed a mechanical engineer in the late 90s. From what I saw some CAD users only need basic drawings with a few hundred or thousand lines. Even for modeling in 3D the games I was playing and modeling for looked more complex.
Maybe it's different today or in certain industries.
This is so sad. Everything gets transformed into gigabytes of steaming JavaScript. Soon our computers won't have a CPU because it's being remotely emulated in JS.
JavaScript is taking over because that is all they teach now a days at these code bootcamps. Once webassembly gets off the ground javascript will die, but we need to get back to native client software. The web was never meant to handle this.
Hi! I’m the tech lead on AutoCAD web. The engine is C++ which is compiled to Web Assembly, our core team doesn’t actually work in JavaScript day to day.
The browsers are doing a really good job making this a possibility today.
The problem is the reliance on the browser. If we look at the mobile market for one, you could do the same thing, but people still want native apps since they are more responsive, lower memory and cpu usage etc …. With web assembly all you are doing is adding more complexity. Keeping things native is preferred.
I would argue that the web is less complex than native, and by quite a bit. You need a client that runs on Windows, Linux (distributed through multiple package managers), and MacOS. Possibly iOS if you want to support the iPad, and particularly the iPad Pro, in any sort of capacity. And if you want to reliably touch Chrome OS, you're looking at web either way. Not everyone computes the same way they did 10 years ago and we have to start accepting that.
Though, using Waze to find the quickest way to work this morning really make my commute much nicer. There was also a new album I'd been meaning to listen to and streaming it on spotify was nice.
For now. I guess management is not doing it for fun but to explore profitability and sustainability of this approach. If it works for them, web version might be the only one that gets distributed. We already saw in Adobe how "cloud" is pushed everywhere even if it makes zero sense from the product point of view (uploading a single RAW file from a top-end camera to cloud takes ages and benefit is nearly zero), but makes super sense from economical standpoint.
> If it works for them, web version might be the only one that gets distributed.
How could it work for them? Most decent sized projects would promptly run out of available memory and have nothing to do about it. And before that they have to deal with the ever longer list of restrictions put on web applications because of the trust model.
I assume they are doing it mainly to avoid distribution costs; they simply push a web-app update via a single, well-standardized channel allowing DRM and trusted remote code injection (to prevent pirates from running it), and they don't need to maintain multiple internal tools to do that with multiple attack vectors. So this IMO might be an experiment in this fashion; they are working closely with Google, probably assuming they can't compete with them so it's best if Google's brightest figure out proper ways, and they can focus on their core business.
This is a 35-year-old multi-million-line codebase working in a browser.
Yup. I don't know what to say - I'm impressed by the amount of effort not spent on other things (for your infinite pick of other things).
The future will tell but in the meantime I don't see the problem that was solved by this fix (except for the problem of not running the app in Chrome).
The WASM group spec just added this in the official 1.0 spec. Non-web: https://webassembly.org/docs/non-web/ So this is how you get around cross-platform issues.
I think WASM is the saving grace here, really. It would be hard to pull of a performant CAD application in JS alone, but with WASM on the rise I don't see why this couldn't work.
Hi, what will you do if one nice day Sundarajan Pichai will, for god knows what reason, order web assembly axed out of Chrome and lobby to bury it in W3C?
> Once webassembly gets off the ground javascript will die
I've seen this sentiment floated around and it's delusional. "Once [better tech] gets off the ground, [lesser tech with decades of headstart] will die" has never been true on its own grounds.
JS's death will be slow, gradual, and we'll see it coming from two decades away. Just look at Java to see what a popular language on the decline looks like. It's extremely slow, and that's nothing compared to JS.
JavaScript is also taking over because it's a way to deliver cross-platform GUIs painlessly. The alternatives are much slower to develop with, not necessarily that much less bloated, and have questionable future support.
Not only that but once you develop a native app you must ship a native app. Words cannot describe the pain and suffering that is shipping native code on Windows (installers) or Linux (dependency and distro hell). Mac is better due to uniformity and app bundles but if you want the App Store you have to deal with that bureaucratic nightmare, and you never know if Apple will just arbitrarily destroy your business one day.
The web just works. Things that "just work" always win over superior alternatives that have a higher level of friction. Here's a rule of thumb: every installation step roughly halves adoption. So a 5-step setup or deploy process takes the number of initial impressions and reduces adoption to (I/2^5).
"[P]ainlessly." "The web just works." "Cross platform." "Mac is better."
These are all just not accurate. The last is objectively not true in the context you use it (Macs account for a tiny fraction of all desktop and laptop computers in use, the vast majority of which run Windows or Linux in the case of servers).
There are a number of web "applications" which only work on one or a small number of browsers, which have complete features on just one browser (e.g. Slack and calls, which work on Chrome, not Firefox on Mac), and many if not most such "applications" have a lot of very complicated, poorly conceived JavaScript code backing them.
You're missing the point. If a web application is well written it does "just work" from most users' perspective. Whether or not the code behind it is a mess is not relevant to the user. They don't see it. They just go to a URL and they're in business.
A superior native app requires a download and an install. That's 2-3 more steps. In a corporate environment that may require an IT support ticket and an argument with a sighing grumbling IT person about supporting "more software" that will "break your machine" and "has it been scanned for malware?"
I know that I am very picky about what I install on my computer. That's because I need my computer to work and I've had broken apps and junky installers wreck machines or introduce instability. Even if they don't wreck machines they leave clutter everywhere and are sometimes a pain to uninstall. Then there's the security surface area issue.
So there's many reasons users resist native apps: hassle, security, system integrity, etc.
It's a tough problem. Mobile OSes made a serious attempt to solve it and made a lot of headway there, but even that has collapsed. Look at the security/privacy nightmare that is mobile today. I am now very resistant to installing mobile apps because I assume they'll be reporting my location to advertisers, sucking down all my contacts, etc., so I only install them if I really need them. I prefer the web for most things because the web is a VM that strongly limits access and when I close the browser the app is gone.
I'm not missing the point. I've just been around a while and have seen this fat client/thin client, "painless" cross platform, and other related buzzword soup discussion time and again. Too many times to be suckered by the modern incarnation.
I tried Xamarin forms. After an hour I could not get a project started. It was painful in the extreme. Visual Studio crashed once during the install. I tried to create a project and got several non-descript errors that looked like vomit from Visual Studio internals.
When I encounter such things I toss them in the trash... not because I can't figure them out but because I no longer have any patience for it. If you can't be bothered to make your software installable / on-ramp-able then I can't be bothered to use it.
I also see it as indicative of how the whole experience is going to go. If installing a development stack is painful then debugging, shipping, upgrading, etc. are also going to be painful.
>There are still significant gaps between the browser-based version of AutoCAD and its desktop-based sibling – 3D being a prime example – but these gaps will reduce, over time. It will also be much easier for the AutoCAD team to build new features that work across the range of AutoCAD’s platforms.
They are heading into the abyss. They will never ever reach a feature and experience parity as JS and Web platform was and is perpetually flawed. And those flaws are barely of technical nature. The root cause are the people who define the "Web platform" and who they are.
Apple's former CEO was smart enough to see that through and do a hard U-turn while the company was still able to do so.
IMO that sounds like one of the worst management decisions Ive ever heard.
You know what AutoCAD needs? It needs to work on Apple.
I have never seen an Apple computer at any company Ive worked at.
Have a team spend multiple years working on cross compatibility instead of automation in 2018? This sounds like someone in management saw that 10% of computers are apple and wants that market share. Whoever made this decision was not a designer.
According to the article it was the port to Mac that made the web port possible. Once they had nice portable code paid for by the Apple porting effort they then used it for web assembly too. I really doubt that creating the portable code just for web assembly would ever have been justified.
This seems like its going to be more limiting than anything.
For basic apps, cross platform is needed. For AutoCAD you dont casually buy it. You probably knew weeks or months in advanced you would need AutoCAD. You have the infrastructure or are planning to buy it.
What designers need is features and automation, not web/apple access.
I only imagine that having a web app and cross platform capabilities is going to mean updates/new features take more manpower, more time, and are limited by conflicts.
They appear to be using the new code in Windows too.
I suspect that it's now a lot faster to do updates and new features because they've rewritten using modern techniques rather than a mish-mash of code accumulated over the last 35! years.
