I’ve noticed that, when creating a large-ish number of parts. The performance of the diagram is noticably slower.
Have you done any benchmarking on any platforms?
PC - iPad, Android?
Obviously, it’s still in Beta, but are there any plans to do any performance tuning?
Regards,
Gary.
This is my first serious look into using HTML5. I naively<?: prefix = o ns = “urn:schemas-microsoft-com:office:office” /><o:p></o:p>
dared to question the performance of the GOJS toolset. What I should have done first, is evaluate the performance of Javascript in general. What I have discovered shocks me.
Developing for raw HTML + CSS is bad enough with all of the cross browser nuances. I had naively thought that Javascript would not be as bad. It turns out that while the language itself is pretty standard, the level of optimisation between each browser is completly different.
How on earth are professional developers supposed to build application where these is no level playing field?
The answer is simple … Just make do with what we have - and hope for the best.
What’s wrong with delivering compiled binary code to a web page. We could call it Silverlight or Air … hangon … I think there is something with a similar name … hangon … we can’t do that because “Apple” decided it was not good enough …
Rant rant rant …
Can’t wait for Web 3.0.
Keep up the good work Walter!
We certainly have plans for performance tuning. We have done a bit of it already, but we have postponed doing so until the functionality is mostly present and working properly.
Regarding JavaScript performance, I have had the opposite experience. I assumed that the performance would be abysmal, but have often been pleasantly surprised. I can see that there are limits to performance to which I expect all JavaScript and Canvas implementations will be constrained. But diagrams that people are expected to understand and possibly edit cannot be too large, so it often works out OK.
So I actually don’t think performance is the immediate limitation for developers. I think the “looseness” of JavaScript, and in particular the creation of properties just by setting them, limits the usefulness of compilers and other source-code analysis tools. This means that individuals can create reasonably small apps, but it is much more difficult to create bigger ones. Inasmuch as apps are just UI front-ends for server functionality, that might be OK for a lot of cases. Although initial productivity is probably higher than for traditional languages/environments, I think the long-term productivity has a lower ceiling.