对标 三家海外低代码巨头：Mendix、Outsystems、PowerApps
图形化编程-国内：CodeWave（网易），scratch儿童语言 汉化版
石墨文档
《iVX对编程最大的贡献是什么？》https://shimo.im/docs/gXqmdgZwQoH8963o/
《iVX虽然是图形化编程，但“我们不一样”》
https://shimo.im/docs/m5kvdW2E9PfJD53X/
《如何选择“低代码”、“无代码”和“图形化编程语言”？》https://shimo.im/docs/913JMzWaLEUwX5AE/
《iVX和低代码并没有什么关系》https://shimo.im/docs/erAdMzMWaZs0mR3G/
《iVX常见问题总结》https://doc.ivx.cn/?page=1884d1a85fc
推荐阅读以上文章，您有什么问题需要咨询？
微信号，教程-视频
10+节，很简单的操作、0基础
谷歌浏览器chrome
从个人账号开始
——copy 浏览几十，wx发送
- [ ]
iVX对编程最大的贡献是什么？ 就一句话：（绝对经典，而且我觉得没啥问题）
iVX —— 用图形化的方式，抹平了编程语言之间的差异！
现在的所有编程语言，从出现到现在，全都是基于“文本”的编程语言，甚至很多人天生就认为编程就是Coding，就是写代码，跟写小说需要写字一样。小说都能拍成电影，那么编程可以使用“图形”吗？ 早期的编程语言发明者或程序员都是计算机领域专家，他们很厉害，但是那个时候设备还很落后，连操作系统都没有图形界面，更不可能想到用“图形化”的方式来编程了，特别是作为最主要的编程手段。 后来，有过很多图形化尝试，有一些也做得非常不错，例如Delphi，VisualBasic，Visual C++，C++Builder，J Builder… ，但是这些其实都是把图形化作为编程的“辅助手段”，而我们这里讲的iVX则是把图形化作为编程“核心手段”。
iVX逻辑编辑界面（替代Code）
当然要做完备的“图形化编程语言”，还需要很多别的东西，这里面有两个东西最关键：一是：“面向组件”编程，也就说“一切皆组件”，组件作为程序的最小颗粒度（这个是没有问题的哈，前端、后台、变量…所有的都可以抽象为组件，现有的可以用，也可以自给自足）；二是：通过代码生成器生成各种编程语言/各种框架的代码，包括前端、后台、数据库代码。
iVX完成图形化编程需要实现的“三大特性”
在iVX完成应用开发之后，由于可以选择性的生成各种语言和框架（现在有react/vue/Java/Node/SQL…），我们发现似乎什么“静态”编程语言“动态”编程语言，变得不那么重要，甚至各种编程语言本身都变得不那么重要，似乎所有编程语言的差异，都可以通过“图形化”的方式“抹平”！ 稍微联想一下，ChatGPT本质也是一种“抹平”，他们的叫法是“对齐”，其实一个意思。ChatGPT其实就是“抹平”人类自然语言之间的差异，而这种能力已经和正在改变几乎所有人的生活，带来前所未有的生产力水平上的提升。我相信iVX是用另外一种方式，在做类似的事情，再过一些年，也许“文本编程”会过时也说不一定。到时候，我会拿着以前写的代码给外孙讲“以前我们做过一件事儿，叫Coding…”
iVX和低代码并没有什么关系
很多用户和客户都误解我们是“低代码”平台，也就是“LCDP”，我觉得需要在这里申明一下：iVX和低代码并没有什么关系！
虽然iVX确实符合很多低代码平台的基本特征，例如“可视化开发环境”、“有组件有模版”、“支持多平台扩展”、“也能不写代码完成应用开发”、“也能完成工作流、BI、表格、表单场景的开发”… 但是，iVX和现在所说的“低代码”还是存在本质的区别：
| 核心差异点 | 低代码平台 | iVX | 说明 |
|---|---|---|---|
| 定义和定位 | 针对企业设计的： 内部快速开发工具 |
面对开发者的： 图形化编程语言 自带IDE |
导致技术架构上也完全不同： iVX涉及编程语言设计、编译器/解释器、各种框架/语义/语法转化、图形化IDE、 图形化多人开发工具、图形化逻辑表达（采用专用高密度事件面板）、变量设计、云计算集成、调试器集成等。 |
| 代码生成 | 无 （平台内运行） |
有 （全栈多语言） |
具备“代码生成能力”，则能“往前兼容”， 用户最终可以脱离平台，直接代码修改， 不会被单一平台“锁定”。 代码生成是核心，使得iVX具有编程语言特性。 |
| 功能颗粒度 | 场景级 （模型驱动） |
语言级 （组件+逻辑） |
iVX具备图灵完备的“非代码逻辑表达”能力，以及分层的设计： （代码—组件—小模块—模型—模版） 无论是前端后台，iVX都具有更细颗粒度 |
| 和代码关系 | 需要少量代码 （低代码由来） |
充分非必要 | iVX和代码是“充分非必要”的关系，代码在iVX中的各个地方都可以使用，包括：自定义组件、JS函数、CSS、HTML、Java、SQL、以及各种SDK。 但是完全不用代码也可以。 |
| 导出部署 | 无 | 有 | 源于代码生成能力 |
| 逻辑表达 | 工作流逻辑 （非代码逻辑） |
逻辑事件面板 （代码逻辑） |
iVX使用专有技术； 低代码平台使用开源框架。 |
| 售卖方式 | 最终用户数 | 开发者数量 | 源于代码生成能力 iVX只负责生成代码，和运行时资源解耦（运行时资源由“公有云”“私有云”提供） |
| 开发工具 | 多个 （多个工具） |
1个 （一个IDE） |
iVX实现了All in One； 低代码平台需要在多个工具上使用切换。 |
本申明的目并不是评判“谁高谁低”，每一种技术都有其符合自身使用的场景。低代码也有很多适合的使用场景，也许在其适合的场景中，低代码还要更便捷一些。 但是iVX确实不应和低代码划分为同一个类别，希望大家能力理解和支持！
==
iVX虽然是图形化编程，但“我们不一样”
首先简单介绍一下iVX。iVX基本上算一个比较成熟的“全栈图形化编程语言”，自带IDE，自动对接云资源的产品。这种编程语言内化到了图形化界面和操作中，通过“生成器（Generator）”的方法再生成多种前端、后台和数据库语言。无论功能、性能、扩展性、兼容性应该都是这个领域内杰出的代表。大家可能也清楚，无论编程语言还是IDE，要想做好都是一个非常费时费力的过程，基本上都是10年起的事儿，据我所知iVX做到现在这个程度，差不多花了17年的时间！
我和一些朋友说起图形化编程（或图形化编程语言），很多人就是“一脸鄙夷”的样子😅，有几种最常见的想法，在这里我来给大家仔细分析和回应一下：
图形化编程效率低？
常见的几种观点：
“不就是程序**流程图**吗？我高中就用过，那个实在是太慢了…不可能用来做应用开发…”
“我敲键盘/**写代码**的速度很快，我就不信图形化操作比我键盘还快?…”
“图形化编程就是**画图**… 我不会画，画起来也慢…”
也大家分享一下，常见的几种图形化编程软件和工作方式：
（1）最早期的“程序逻辑线框图”，拖拽画图，效率也是最低的，无封装
:::info
~visio 办公流程图还在用，普通行业比程序员落后很多==:::
（2）近代的，还在使用的“用于数据流编程的Labview/NodeRed”，拖拽画图，强大直观，效率有所提升（在数据处理和测试等领域的编程）
:::info 学过，忘了==
:::
:::info
~导图，拖拽 拉线:::
（3）特殊“儿童/青少年编程”的“scratch/blockly”，拼接画图，把语法拆成逻辑块，效率低，但比较有趣，适合小朋友
看了教程，青少年培训+外接硬件OK
大家再看一下iVX的解决方案：
（1）iVX前端逻辑的开发
- 虽然也是图形化的编程方式，但是iVX不画图！这个很重要，因为画图本身就效率很低，有时候甚至需要排版和设计，而且多数情况下画图的空间信息利用率并不高，也就是说“信息密度”通常都很小。（也不知道是谁一开始就是把“图形化”编程往画图这个坑里带，一代一代的图形化编程都是走这条老路，因此一直发展不起来。）
- iVX主要操作就是点击鼠标，直接操作各种封装好的组件进行逻辑的拼接，如果要定义一种编程范式，我觉得可以叫“面向组件编程”。（这个有点像DOS到Windows的感觉，Windows把操作都封装在可点击的对象里面，无论学习和操作都带来很大效率上的提升，除了一些坚守“键盘操作”的极客以外，多数用户都投向了图形化操作系统的怀抱。对于iVX不同层次的可高度抽象的丰富组件和内部方法，其编程效率也会显著提升）
- iVX“去掉程序语法，只保留程序逻辑”，把以前编程语言的“控制结构 if while for swich 等”只保留最基本的结构，并抽象成逻辑块，把“控制结构”和“结构内部的逻辑表达”区分开来（听起来可能比较抽象），进一步提升逻辑表达效率。（Scratch虽然也是块，但是几乎是复用所有语法控制结构，导致结构还是比较复杂，效率较低。）
- iVX追求最少的窗口和最少的点击次数，探索编程可能的最短路径；追求“逻辑简单 > 操作简单”，走了一条完全不同于以前图形化编程的技术路线。
因此同样是图形化编程，通过“图形化”方式表达程序逻辑，但是iVX效率上会有非常大的提升！现阶段iVX一次有效操作，平均生成300行以上代码。
图形化编程架构差，技术落后？
几种常见观点：
“VB我就用过啦，后来不用了…被鄙视了…”
“Dreamweaver用过，后来也被鄙视，不用了…”
造成技术落后的几个原因：
（1）图形化编程，本身技术复杂，而且IDE是一个非常“重”的东西！图形化编程涉及到方方面面，编译器/解释器、代码生成、组件设计、中间语言设计和生成、多人开发、版本管理、debug/测试、运维… 再加上IDE开发，使得整个项目非常复杂，而且“牵一发动全身”维护和升级成本都很高。如果技术选型中出现什么问题，那基本上就是灾难性的…相比“文本编程（现在的高级语言）”图形化要更新迭代要艰难很多。
（2）技术进步速度太快 图形化产品如果开放性不够，例如自定义组件不成熟，或无法接入云计算，就会导致技术升级能力比技术进步要滞后很多的现象。如果采用架构再比较落后，基本上后面就很难有大的改进了。因此，本身图形化编程就是难度很大，赌性十足的项目方向。
iVX的做法：
（1）尽量保持架构的灵活，引入最新的软件概念和能力。例如前后台分离、微服务、数据驱动、Serverless（函数计算）、技术/数据中台等。（2）对代码的高度友好，iVX与代码实现“充分非必要”的关系。这里面包含分层的自定义组件、小模块、模型的设计，以及云计算产品/数据库产品组件化接入的设计。同时允许方便引入各种前端库和npm包，后台引入各种语言的SDK等。
（3）生成公认标准的框架代码，例如前端生成vue/react可用代码等。
总之在技术上，保持生成的代码运行效率较高，并尽可能保证技术中立和减少第三方依赖。
图形化编程还需要学代码？
几种常见的观点：
“现在**低代码平台**那些，还不是要学代码？学完代码再学低代码，成本太高了…”
“而且还不是简单学学那种，因为图形化里面需要代码的地方往往都是图形表达不了的，都比较复杂的…这个要怎么搞？”
“先学代码，在学图形化编程…就没有那么有意义了”
iVX的做法：
（1）iVX对用户的要求“零背景知识”！只要有初中文化，加减乘除括号会使用，就能学习iVX，里面不会主动出现任何代码和编程必备 知识和痕迹（你可以用，但不主动出现，鼓励尽量不用代码 ）。iVX能生成代码，也可以完全不用代码进行开发，并把两者完整融合在一块儿。 （2）引入小颗粒的组件、中颗粒的小模块、大颗粒的模型，使用户可以在多种颗粒度之间切换使用，保证最低的学习成本。例如iVX重的模型，并不是模版 的概念，比模版颗粒度还要小，自带数据和UI，还可以自由拼接出更复杂的应用。图形化编程只能做一点点事情，复杂的做不了？
几种常见观点：
“做不了什么复杂的东西，只能做一下小场景”
“只能在**特定领域**可以用，例如Labview我用过，只能在硬件和测试里面用一下，开发不了应用的…”
“就是做**工作流**/BPM是吧？有很多工具，还有开源的…”
从iVX目前表现来看，并非如此，而且还有很大空间
（1）图形化编程本质，“Visual Logic”，这个和产品本身的设计有很大关系，但本身并没有什么限制，原则上所有的逻辑过程都可以“封装和抽象”，都可以通过图形化方式来表达。无论应用、芯片、硬件(iot)、流程、游戏、电商…都可以用图形化方式表达，甚至算法也可以。（2）一些复杂的应用，例如电商系统、MES（工业）、ERP（工业）、CRM、OA、通信/客服、游戏、智慧城市/iot、原生应用等iVX都有很多成功案例，一些项目甚至生成上千万行应用。
总的来说，虽然早期大多数图形化编程产品，基本都是针对固定领域，但并不是说“图形编程”只能做那些。
==
如何选择“低代码”、“无代码”和“图形化编程语言”？ 低代码的定义就不再这里掰扯了，就按照最有名的三家海外的巨头来：Mendix、Outsystems、PowerApps（Power platforms）。这三家应该很具有代表性了，应该也是低代码平台里面做的最好的（应该不会有太多人有异议）。
通过分析这三个平台得出：
低代码平台的最核心特征
A 不直接生成可以部署的代码（一般是某种打包格式）
其中，Mendix生成 .mpk 文件，应该是一种Java的打包格式，也有部分JS代码； Outsystems生成 .osp 文件，应该整体上和Mendix类似的方案； PowerApps生成 .msapp 文件。 也就是说，比较“杰出”的低代码平台，是可以导出文件，并部署在自身“系统”内部的，但是无法部署在“非自身定制系统”。也就是说，低代码平台直接“互不兼容”，低代码平台生标准的代码运行环境也是“互不兼容 ”（例如不能直接在Java环境运行）。B 面向模型编程
低代码平台，设计时主要是针对企业内部管理场景服务的（设计初衷）。在我看来，低代码平台，不能算是一种“新技术”，而是一种为“企业服务定制的产品”，这一点和SaaS有点像。因此，免不了会有一些局限性，无论是功能和性能上都很难和编写代码的系统相比并论。但是，在一些固定场景下，低代码平台效率会很高。几乎所有低代码平台都可以涵盖在这其中基本模型中：
BPM模型
表单模型
在线表格模型
BI报表画图模型
在这个基础上，有一些进一步做了“页面编辑器”“数据库设计器”等等，这些就算做的很好的了。 如果再进一步的，会做“逻辑设计器（或者叫逻辑编排工具）”，Mendix和Outsystems在这方面都做得很不错。C 面向最终用户收费
这是一个商业模式的特征，但是由于产品是“运行时”的配置产品，也就导致了这种“收费方式”。这一点和“图形化编程语言”按开发者license进行收费有很大不同。无代码就是“SaaS”
在我的理解里面，所谓无代码就是SaaS，两者没有什么区别！最多无代码平台把多个SaaS集成起来，具有一定的“互操作性”而已。多数情况下，无代码产品更希望“在线使用”，而不是“本地部署”，这样更符合SaaS的特征（但国内已经卷得面目全非了😂）。图形化编程语言的基本特征
图形化编程语言：这个是新兴起的技术方向（同时也具备很强的产品属性），其实很多产品早就开始尝试，其实没有引起足够的重视。在一些领域“图形化编程语言”占领着绝对的统治地位，最明显的就是“Scratch”，儿童/青少年编程，这个一说，应该很多人就知道了。
但是，作为“通用”编程语言而存在，能够实现各种企业/工业和个人应用的开发场景，这是一个非常大的挑战。 但是，国内已经有两家企业做得很不错了，一家是iVX，另外一家是CodeWave（网易）。（我在这里就不做更多比较，因为我觉得往这个方向发展的，都很了不起！海外还没有怎么看到可以商用的产品。）图形化编程语言的基本特征：
A 直接生成全栈代码
作为一种新型编程语言，必须可以往前兼容，也就是最好能够自动生成“高级语言”，以iVX为例，前端可以生成Vue/React/flutter/小程序等，后台可以生成Java/Node.js代码，代码可读/可改，且全栈代码可以直接编译运行。这意味着，开发者对“图形化编程语言”可以做到完全无依赖，可以随时解绑。B 面向组件编程
要想去掉代码，比较可行的方式就是“面向组件”编程，并且把“逻辑控制”部分抽象出来。
C 免费的（如果要收也不会面向最终用户收费）
iVX和Scratch都是免费的图像化编程语言，iVX更适合企业和程序员学习，而Scratch是针对小朋友学习和使用的，CodeWave好像现在是收费的。 但是，由于“编程语言”本身是面向“开发者设计”，而非“面向企业设计”，因此，最多就是和Ideal J一样收IDE的license费用，不太可能收最终用户的费用（因为原则上完全不知到最终有多少用户，运行时应该是“未知”的）。如何选择呢？
从企业安全考虑，我觉得 企业应该尽量避免使用“低代码”平台，理由如下（欢迎大家指正）： 低代码和SaaS平台用完即走不同，低代码平台需要企业长时间的“投入和迭代”，往“低代码平台注入知识”，这样使用过程中会“越来越重”，以至于无法剥离。对于被选择低代码厂商来说“也许是个好消息”，对企业也不傻，很少愿意“被锁定”在某一个平台。从快速开发考虑，是可以少量使用“低代码”和“无代码SaaS”平台的，特别是“SaaS”平台，用完即走的特性，肯定对企业会更加友好。
如果从技术升级，中台建设（我个人其实还是挺中台的，只是中台要求较高，如果用图形化编程可以试一下，成本会降低很多），降本增效来讲，“图形化编程语言”应该是不错的选择，效率上相比代码提升明显，能力边界和代码开发非常接近。
若有收获，就点个赞吧
0 人点赞
