jare这个调研完全看不出是为编辑器插件准备的。如果写明了为编辑器插件调研，那肯定是另一个结果
你为啥一定要站在道德高点去指责别人呢？显得你很能是吧
如果是为插件的路线而投票，为啥不直说，搞这么几个选项，相关度太低了。
28 定律，集中精力做最重要的事情就行，而不是面面俱到，只有 laya 才有办法做到这一点
为什么要说是为什么？真正的调研是那么容易让你猜到的，那结论还有可信度吗？
总之就看调研结论，当时连我自己都不相信非得搞一套“简单好上手的”UI 才行。只能说…… 幸存者偏差
因为幸存者偏差啊，我直说我要搞插件，那就会招来 100 个喊着要新 UI 的，我哪里知道门外还有 900 个对老 UI 已经能接受的用户呢？那我与其花力气重写一套 UI 服务这 10%，给自己增加日后天量的维护成本，还分裂开发者社区…… 那我不如花力气多修几个 bug 服务好剩余 90%？ 反正自然会有插件小王子这样的牛人搞出一堆类似 cc-plugin 的东西，助力大家更好的做插件，这样就能反过来证明官方不用亲自下场。
明白了，明天cc-plugin就闭源，反正也没人用，我不想学习雷峰了，被镇压在雷峰塔好难受
3赞
哎，其实可能在一开始，开发编辑器的路线就没选好（使用2套技术栈），现在那就只能补一补算了。
一般游戏开发的人，在开发通用编辑器的时候，第一时间就会想到用引擎的UI。不管是代码形式的那些库OGRE，Urho3D，还是编辑器形式的Unity，Godot，做编辑器的时候，都是第一次就采用了引擎内UI，方便跨平台，代码还统一。
所以不清楚为什么当初在方案选择上，采用了web栈形式，这会使得引擎开发需要两套技术栈同时协作，增加了复杂度。
这就像我见过的一个项目，在Unity里面，运行一个flash虚拟机来用flash做UI，一样的别扭。把两套不同的东西硬要混合在一起。
laya这么牛逼么
使用 web 相关技术应该是因为编辑器是基于 electron 的，可能这样对他们更自然
就是不太理解，为什么他们写编辑器的时候，用electron，而不是直接用引擎UI。在那个时候已经歪到web技术栈上了。也许是他们对web更熟悉吧？
现在要改就改不了，就只能修修补补，看起来好用一点了。
我前面说的，在unity之上用flash做ui的项目，采用这个方案的理由，是美术团队对flash做ui更熟悉，有flash的工作流。我感觉是不是cocos也是这样，做编辑器的时候团队也是web前端过来的。
你可以先设想下2014年左右的技术环境和趋势.
-
都在走脚本语言化方便热更新
-
希望能有跨平台的编辑器开发框架 ,Electron那时可是即将成为新宠,市面上大多数的C端跨平台软件(网易云音乐,qq音乐等一大堆大公司软件)都在改造或者重写.
-
基于以上,这不js/ts就是个非常好的选择了.
-
就类似于现在国外很多web技术栈的客户端软件开发都开始基于flutter一样.
-
回过头看,这个选择没有任何问题,只是没执行到当初预期和设想而已.
1赞
用引擎UI做编辑器，那要先造一个类似electron的轮子。。 另外就cocos那个引擎UI 在mac windows有什么竞争力，系统控件全要从头开发
godot, blender后期之秀，在这方面考虑的很周到，尤其是blender，交互做的是真丝滑
因为我们写编辑器的时候，其实哪怕到今天，引擎在桌面端也不成熟啊 
很多 API 没有。
不是不想用，而是缺乏桌面端良好的支持。
游戏引擎的编辑器，和普通软件编辑器还是有一定区别的。我记得以前在用OGRE的时候，就推荐用引擎本身的UI做编辑器了，因为本身游戏引擎跨平台，且写编辑器也是对其UI库的一个能力测试。
而普通软件，业务逻辑上本来是没有另外一套UI库的存在的，当然会选择一套比较好的UI系统，当然就会选择web技术这类可以跨平台的技术了。选择之后也不会出现两套技术栈的混合。
退一步讲，如果我不选择引擎UI，那也会选择与引擎运行时类似的技术，例如C++的引擎，可能会选择QT，有C#为脚本的，也会选择C# + winform。
而且如果引擎用js/ts 做脚本，那编辑器一样可以用js/ts啊。只是说底层基础使用cocos原生运行时而已。
1赞
现在我理解了，因为cocos定位上就没把自己当成一个桌面端的引擎，而是只专注于移动平台开发，那确实和OGRE，Unity，Godot这类以桌面端为主，移动端兼容的引擎不一样了。
不过编辑器用引擎UI开发，其实是对引擎跨平台和UI库的一个能力验证。如果当时做了的话，引擎也会稳定不少。
1赞
这个倒是不用，可以把编辑器当成一个原生游戏开发就行。桌面端UI确实是缺了不少，也许是cocos本来就没定位成桌面端引擎吧。
刚立项那会，还没到 Cocos 呢，没想过将来要发布到桌面端