I thought I would break this question out into the Developers category, for geeky discussion.
Should the web app my.SketchUp have an API that is Ruby ?
… or JavaScript ?
… or Java ?
… or some other web technology ?
Should it support Chrome extensions ?
… or MSIE plugins ?
Coders already have to think about small differences between mac and win. So my layman’s guess would be: re-use the existing ruby & html & css & javascript system that’s already in place in SkechUp. There are already plenty / wonderful plugins and it would be great if those could be used in my.SketchUp as well.
Juts my 2 cents. A proper/real coder might see it differently - they probably have a far better view of future developments as well.
I think developers are going to want their existing plugins to work almost as is in my.Sketchup. Of course, it might require evaluations like
if Sketchup.platform == :my_Sketchup
Hopefully for minor differences only. The additional question is how shared object files will be handled. Currently, you need one for 32 bit windows, 64 bit windows, and Mac.
aside from, css/js ‘theme’ manipulation, I’m having difficulty seeing how any ‘external’ plugin could possibly work on the platform…
isn’t SU’s core code being compiled to asm.js, which in turn outputs webGL in the browser?
unless the plugin is part of the core would it not need to be converted to C and then injected somehow into asm.js?
I wonder if it’s better to retain plugins for the desktop and have this as a Make replacement…
john
After spending the last 2.5 years mucking around in SketchUp and developing a couple of plugins I feel like a have a fairly good handle on the SketchUp API and Ruby. My biggest concern with porting a plugin over to the web based SketchUp is how much of the code will need to be rewritten.
Unfortunately, some of my plugins are quite large now with thousands of lines of code, to completely rewrite that code would be a monumental task, at least a month of two of solid work.
I am completely comfortable with javascript and html as well as a number of other programming languages and scripting languages so moving to a web based model probably doesn’t scare me as much as some.
I am wondered if SketchUp for Web we can leverage Opal (Ruby → Javascript translator) ?
… or how RubyFiddle.com executes Ruby code using JRuby ?
@thomthom @tyler_miller @bugra … any thoughts ?
We’ve looked at all of that. But so far not seen a solution that would provide a Ruby environment fully compatible with with the desktop client.
One emcripten build of Ruby I found that looked to be MRI was 6-7 years old, Ruby 1.8. Apparently Ruby 1.9 was so different that the project could not continue.
So the question is then, if we cannot provide a 100% compatible Ruby environment for SU on the web, is it still important to look at Ruby? Or think new? JS is more of a natural choice for any API on the Web. With JS at a base you could use a number of languages that allow you to transpile to JS.
As we said above several times, as close as possible to reduce the amount of changes is the goal.
Not 100% changes.
It is obvious much of the UI module would work differently.
Personally - I’m not really interested in porting my plugins over to JS for the web version of Sketchup.
As long as Sketchup Pro is available I will continue to work with Ruby, However if push comes to shove I will look at Fusion 360 and FormZ etc.
I’ve always used the C++ like syntax when coding with Ruby so porting should be a little bit easier. && instead of AND, || instead of OR, {} instead of do end etc.
Still - I’m hoping that Trimble will support Ruby - even if they have to create the interpreter themselves !!!
When you have 20,000 lines of scripts - it would be a difficult port. Some programmers would simply scrap it and start over. I simply don’t want to spend that time - especially since my market is very vertical and a good percentage of it use CAM software that is NOT web based.
Porting a small plugin (majority of plugins) to JS will probably not be big deal but anything over a few thousand lines of code is going to be a serious undertaking.
In addition to the time converting the code there will also be some significant time burned up in debugging.
If there is someway to not have to port away from Ruby, that would be optimal.
I still contend that the whole web based SketchUp thing is a mistake. How does SU or Trimble make any revenue from this FREE web based product. Please don’t turn SketchUp into a gimmick. Offer SketchUp Make at a reasonable non-pro price, it will sell.
How about… making JS the standard for web AND desktop. 
This would’ve been my answer if you asked me a year ago.
But, with webassembly having shipped in all major browsers, I can see a bright future for C/C++ in both SU free and pro.
JS could be possible in both endorsements but it is an ugly language in my experience. Ruby is a lovely language where you can do very much with little text and easily write very readable code.
But then there is TypeScript with Types, Visual Studio Code with intelliscence and thousands of npm packages, async all the way, …
An API is usually not as short-lived as a some npm modules… and the SketchUp API is rather one of the most stable APIs. Changes to an API will have a very long transition period.
JavaScript has been a too fast evolving target. While ES7 is so much improved, I find it rather a totally different (better) language embodied under the name “JavaScript”. But consider that Ruby is the language of love for most of us here, with probably the most beautiful and consequent OOP realization.
Yea, it would a much easier to add JS API to desktop, than Ruby to the web. And the JS API could live along side the Ruby API.
With all the tools that transpile to JS it could even allow developers to choose their own language of preference.
So that is also a route to investigate.
Yup, modern JS is a very different beast than the ES5 and older. TypeScript, with it’s great tooling, actually makes it enjoyable.
I dangled Opal in a post above, but you seemed to discount it. … Said y’all looked at it.
Do these tools have some kind of translation table that can map Ruby-side to JS-side API calls ?
They look at the AST of the source language and tried to transpile it into JS code that do the same thing. Exactly how perform this transpiling I’m not sure. But getting a 1:1 mapping is a challenge.
However, in the context of Opal, it would mean there would be an underlying JS API - because Opal compile Ruby to JS. So we can’t use Opal et al as a replacement for a Ruby Interpreter and instantly get the existing desktop Ruby API on the web.
Okay, there is some misunderstanding present here.
Others involved and I have been coming from the extension developer’s perspective on how WE will “port” our desktop SketchUp extensions to SketchUp for Web.
How YOU (the team) support extensions is not what I’ve really been speaking about in any of my previous posts.
From the API implementation side of things, I assumed perhaps that Ruby namespace names would be mimicked in JS, with as close to the same method names as possible.
For a simple example, … UI.messagebox() would be a wrapper around JS’ alert() call or perhaps a popup with a few more button choices.
Geom methods and subclasses would be wrappers around WebGL or ThreeJS method calls.
Yes this is more work than some automatic transpiler of your API C code, as it’d likely need to be done manually (unless something like SWIG can help here ?)
Yea, it’d make sense for a new API to in many ways looks like Ruby - in terms of structure. The classes in Ruby API mirrors pretty close to how the internal core is structured.
My big question is how extensions for ‘SketchUp Web’, could deal with file system access and security issues? Would extensions need to be installed on the client computer? Or would they be part of the user’s account, and be downloaded each time SketchUp is run? I agree that for SketchUp Web (paid versions) to really be useful, an extensions API will be necessary. Although I personally still loath all web apps in general. Perhaps it has something to do with the 12 second delay when starting up. Although I must say the twelve second load time in a browser is actually impressive, for a web app like this.