From an initial use case perspective (early days) I like the native extension setup. I work a great deal with C libs and C wrappers in my work and in the past, so I find it very convenient and powerful.
I do wonder if theres a nice way to make it ffi friendly 
… I know html is pretty much impossible for that, but it makes me think there might be a nice way under the hood to map C libs like like ffi does - or even using the powerful ffi.cdef system to do so. Im thinking this as I go, so stay with me
Your current api is traditional registration setup via C/C++. This is fine and how normal lua does it, so its probably quite familiar to most people anyway. However if you could use the ffi.cdef (or similar) to define the wrapping calls then it would make things very clean when building external interfaces. The reasons I like this:
- The interface is then defined where you use it (in lua) and thus needs minimal documentation.
- An extension could simply provide static cdecl definitions and thus allow a wider array of calling conventions (allowed by C)
- It should be nicer to manage on the Java/integration side because you end up with some simple C handlers rather than problematic method conversions.
- A wider array of libs would almost be directly accessible.
The big drawbacks to this:
- Difficult to control and manage the environment and thus track bugs and issues (this is quite a large prob).
- Potentially nefarious code could get in - although with open source, this is more difficult in reality.
- Not sure how package management and extension management would occur - might be more problematic.
As it stands at the moment. I like the way it works … but thats just me. I like systems that utilise tools and frameworks to allow the developer to achieve their goals - and more importantly, extensible enough that you can find ways around problems. So far… Defold nails it on this aspect.
One thing I would probably be critical of, is the editor. I think there are elements to it that are somewhat dated and probably need some love (I havent checked issues so they may be already underway). For me, these are:
- Undo/Redo is extremely flakey. This might be a Linux Debian GTK thing. Not sure.
- General “feel” is a little stilted - hrm, this is hard to describe, but it isnt ‘snappy’ where it should be. Generally key and mouse input in an editor should be number 1, everything else gets a “waiting” bar… or something like that if its taking time (with cancel).
- There probably needs to be a separation between 3D and 2D editing for scenes (collections). I think reference to Unity3D’s setup here is a good idea, although, thats a little messy.
- I dont wanna sound like a language fan so and so… but I think Java may not be ideal for 2D/3D editing systems. Our sims used Java heavily for control panels and track editing, and they get big and cumbersome quickly. Which sort of goes against the “light and extensible” idea of the Defold system - I get java needs to be used, and it is key to things like cross platform editor visuals, but I think a longer term road map may want to look at systems like html/electron or even utilizing your own GUI builder and make the editor in Defold … yeah… sorry… probably too far…
Anyway… dont change too much just because of an old coder… drive your own path! … I’ll stick around.
