Show HN: SVG 3D Builder – Build 3D Models with SVG
github.com
github.com
SVG (and to a lesser extent Canvas) are trainwrecks in terms of performance. It's really a sad story that HTML5 has been evangelized so strongly, yet even ten years later it can't hold a candle to Flash in many regards.
This could be an interesting "worst case" polyfill.
Show me the library using WASM/WebGL that loads as quickly as SVG or Canvas content.
619KB in total, 362KB wasm binary
Edit: Three.js is such a library with qualities you described:
I'm aware of minimalist things that can put stuff on-screen instantly, but not of something that's a fleshed out solution like SVG or Canvas that still loads instantly (like SVG or Canvas).
Edit: I'm sorry, my brain was still in 2d/Canvas/SVG/Flash land, you were talking about 3D stuff all along. You're right threejs stuff can load quickly, shaders can become a bottleneck though. I was thinking of a library that basically does "Flash Lite" with good performance and yet remains competitive with Canvas/SVG content in terms of load time. I'm not aware of such a solution, but I'd be glad to learn whether it now exists.
The canvas can be quite fast if used right, but again, it's not the right tool for every job.
WebGL doesn't have very good support, especially on mobile. That's why one would choose to use SVG.
Also, just to get it to do something requires a lot more expertise and code.
Would this project have worked out better on Canvas? Yes, most certainly, but some people have to find out the hard way.
It all depends on the GPU and its drivers, browsers have blacklists of GPUs, but even if your device is not blacklisted, it may simply screw up, especially on mobile.
I got recently asked to do a project in WegGL and the target audience has the latest gadgets so it will fly on mobile as well. A transaction will cost around $50k so it's a safe assumption, but I'll do more research.
This statement isn't even vaguely true. SVG support is quite incomplete and inconsistent across all browsers (both desktop and mobile), while Webgl has been comparatively well supported on mobile for many years (Android 4.4 lacked support; Android 9 is now out).
The only issues you might have with most common webgl applications on mobile is performance & battery drain but that's equally true of SVG.
How much actual WebGL vs. SVG development have you done? How many devices have you tested?
First of all, that's a pretty condescending thing to say and you're obviously not speaking for everyone. I wouldn't mention that if you weren't tone-policing me.
I'm telling you that if you make technical decisions based on "feature support" charts, you're going to fall flat on your face with WebGL. That's pretty useful information unless you never have to do any actual work with that technology, but then your opinion is also irrelevant.
> Knee-jerk disagreeing and suspecting everyone to have less experience than you will just get you downvoted everywhere.
Nobody who has experience with WebGL and SVG will say WebGL is better supported across the board. You'll have to take that at face value, there's no scientific study for it and I'm not going to just give out more information than I'm comfortable with.
I'm getting downvoted across the board here, presumably for using "bad" words like "terrible" to describe everyone's favorite Web technology they never really used. Or if they have used it, they don't know how poorly it compares to something "evil" like Flash. People want "the good guys" to win, which means "free and open source" and "standard". It makes them upset when somebody criticizes that harshly, but it's the reality.
I got some upvotes initially, by the way. Not that I care either way, I'm not paid in upvotes.
You obviously have experience in this area that is great to share in a way people can learn from. But first it's necessary to be civil, as all users need to be here.
Having said that, iOS isn't that bad.
When done right (for example: http://awards.paris/new-micra-experience/ ) 3D in the browser can be impressive.
Although maybe that's just a result of computing power and GPU progress..
Also WebGL has been around at least that long, if not longer..
With SVG, you will easily run into the same performance issues with any kind of dynamic content, 3D or not.
With Canvas, you may or may not run into them, depending on how much content you have.
In either case, performance is terrible compared to what you can do in a native application.
> It's really a sad story that HTML5 has been evangelized so strongly, yet even ten years later it can't hold a candle to Flash in many regards.
Not sad at all. It needs to be evangelized more since it's clear that other solutions did not work. By other solutions I mean a private company design something and forces it on the world. (Flash, Java applets, Real Player, Shockwave...)
We have all the features flash had now (and had it for many years now)
It probably could have been, pre-Oracle.
Netscape also had Jonathan Gay and his brother stop by to try to sell FutureSplash (what became Flash) to us post IPO, but so many companies were crowding the door, and the marketing guy vetting them was harsh, so they went to Macromedia. That was for the best: Netscape would not have built the great tools that Macromedia did.
So two "what if" near-misses re: early canvas-for-HTML. Sad but true!
Transcript: https://devchat.cachefly.net/javascriptjabber/transcript-124...
Find "Andrew Myers"
You have absolutely no idea what you are talking about, yet you're evangelizing HTML5, that's the problem.
Talk to somebody who tried to bring Video or 2D(!) animated content over from Flash to the Web. It was (and remains) a total clusterfuck. Not just because of performance but because of compatibility. Flash just worked. Web video or (god forbid) WebRTC are still problematic.
That's not to say that I want Flash back, but ignoring that it was proprietary, it was the better technology.
Web video was "fixed" in the dying years of Flash. I remember cursing on HMTL5 video, but it was suddenly got performing really well and switched YouTube to it and never looked back. Just pick a graphics library and you'll be fine if you want to move vector stuff around. If you miss the flash IDE, then it still exists and can export to HTML5 standards.
Being proprietary was just part of the problem. I'm glad it showed us the way but it needed to be gone.
You followed other people doing the development at great expense. You're in no position to evangelize anything.
> Just pick a graphics library and you'll be fine if you want to move vector stuff around. If you miss the flash IDE, then it still exists and can export to HTML5 standards.
Hahahaha, yeah please use it. Please, I beg you. Use it and then come back and tell me it's just as good.
> I'm glad it showed us the way but it needed to be gone.
If it showed the way, people didn't quite see it, they went ahead with nonsense like SVG, which didn't work, so other people created Canvas, which still was massively slower than Flash. Just literally copying Flash would've been better.
I did use many graphics libraries before, thanks, they are fine.
You say things like "just export to HTML5 from Adobe Animate/Flash", but if you had actually used that, you would probably tell people to stay away from it, or at least acknowledge the caveats.
1) The HTML spec at the time flash rose could do nothing of what it could today. Flash, applets delivered - relatively speaking. They didn't 100% hit the one code base that works the same everywhere promise, but came close. Maybe webassembly will lick that problem.
2) HTML interpretation has be ever been consistent between browsers. Respectfully, ie6 was smooth sailing. I'd advise studying life around ie3-4.
3) When Flash fell out of favor thanks to Steve Jobs, Flash Lite ran already, just fine on a lot of phones. It was used on a lot of devices quietly and may very well have been the android of its day. It was just a personal move. Steve Jobs also locked down the iPhone around that time (no app store) at the time.
The "future", html5 was not ready at that time. The web was held back and suffered for a number of years while there wasn't a viable alternative to flash and HTML5/JS still needed to mature and be ready to go.
The dangerous thing about saying html has successfully replaced the past is, we're doomed to repeat the past if we don't understand it due to hubris.
4) Every tech has contributed something valuable. Flash caused me more grief than I ever care to get into.
Flash type browser plugins helped deliver experiences that nothing else could for a very long time, and frankly when the html spec didn't have the foresight, or the capabilities in browsers.
5) Flash saw the value of basing their entire scripting language on actionscript, which is ECMAscript, which is Javascript... more than a decade before anyone thought of using Javascript for building apps.
6) Today's practice of building apps in Javascript in part is inspired outright from what Flash could let a developer do.
IE3-4 was probably nightmare to work with :)
> The dangerous thing about saying html has successfully replaced the past is, we're doomed to repeat the past if we don't understand it due to hubris.
I feel we will repeat some of the mistakes thanks to webassembly, but I'm not saying it shouldn't be the direction we are heading to. Luckily thanks to the open nature of developing these specs the process is more balanced between parties than ever.
The same can't be said for the design, interpretation or implementation of the html spec.
Open standards can also fall to paralysis of design by committee. Still, open is good (AV1 is also cause for optimism).
When open standards aren't possible or happening, innovation is undertaken by private companies.
I like wasm, but this unabashed overstatement completely ignores smaller browsers. Best of luck getting elinks to commit to wasm support.
The major browsers in marketshare.. being Safari, Chrome, Firefox and Microsoft are all on board with wasm.
Is there another thing you can find they agreed on to this degree relative to market share?
The wording of your comment makes me wonder if you know a bit more about wasm, particularly with smaller browsers (I am a fan of Opera too), so please feel free to share the smaller browser perspective.
Unfortunately not. We still can't measure text without putting it into the DOM and waiting for update, nor can we have weak references. And SVG is miles behind the performance that Flash's scenegraph had 10 years ago.
SVG is not a part of HTML 5, it is older, while Canvas actually is, and Canvas is as fast as the now defunct Flash. Maybe applying the right technology to a problem would solve the speed issue...
Maybe not formally, but making that distinction makes no difference to my point.
> Canvas is as fast as the now defunct Flash
...not even close.
https://html.spec.whatwg.org/multipage/embedded-content-othe... begs to differ.
You have to compare it to non-Web technology to get an idea of how bad it really is. Compared to SVG/HTML, it's of course massively faster.
Mostly the notion of treating your entire app as a simulation, just like games do. VRML-97's event loop, warts and all, made things a lot easier.
VRML-97 also had a true prototype/instance class system, way more like David Unger's Self language than what we have today. (Ironically, JavaScript is moving away from prototypes and more towards classes each iteration. Too bad.)
Scene graphs, of course. Really just a DSL for describing object graphs. Very succinct & powerful.
A few things deflected VRML-97.
Sun placed their bets on Java3D and ignored OpenGL. In addition to scene graphs, Java3D had the notion of live (active) objects, sending messages to each other. It was the 90s, people still bought into OO. It was an idea worth exploring that didn't pan out. No shame in trying.
The bigger mistake was the VRML steering committee went all in for XML and switched to Web3D. Completely stopped all the hard earned momentum. Classic example of Joel Spolsky's "Don't Rewrite" rule. This idea was not worth exploring.
Source: Implemented VRML-97 browser, wrote some games and authoring tools, coauthored the original JavaGL bindings with "Alligator Descartes", lobbied Sun & SGI for years to drop Java3D and promote JavaGL (which they eventually did, but too late).
You can get your Amiga performance with canvas; and you can get way better with WebGL. This is just a case of wrong-tool-for-wrong-job.
Did you know that drawing paths requires a ton of pretty expensive Javascript calls or alternatively passing "a series of text strings"? Maybe the string way is actually faster, I haven't tested it because it isn't supported everywhere.
Were you aware that vector rendering is not usually done on GPUs, mainly because of the high overhead of state changes when using a graphics API, especially one like WebGL?
I guess you could do all your rendering in software in Javascript (which for these purposes is nowhere close to what you can get with C/C++) to a byte buffer and then do the final transfer to Canvas. Even in that case, you might be surprised how much overhead that final transfer has...
But it's actually worse than that, isn't it? It's not only that I can't render a complex SVG path on the GPU, but I can't even apply a GPU accelerated transform on existing child nodes of an SVG.
Why is it that <div> can get a GPU-accelerated transform but <g> can't?
Something that could either be called laziness or difficulty, depending on your perspective.
And SolveSpace will let you export a CAD model to an html file with a built-in three.js viewer.
I had almost the exact same math in there and it performed about the same until I showed it to an old-school guy I worked with who used to do game programming at sega. He goes "try this" and proceeds to replace a couple screens of trig with:
d = 0.001;
x = x + d * y;
y = y - d * x;
It took me a lot longer than I'd care to admit to understand why that works, but it does. Maybe this will help you. I also tried doing solid models, but the layering was difficult enough that I lost interest and focused on wireframes. If you'd like I can try to find my old source for this.