ローコード プラットフォームの解体 - ジェネレーティブはローコードの方向性です

私をよく知っている友人は、感染症流行中に私が自分でコーディングして BAAS (サービスとしてのバックエンド クラウド コンピューティング プラットフォーム) とローコード プラットフォームを構築したことを知っています。

作った理由は2つあり、1つは本当に暇だったから、もう1つは昔作りたいものがたくさんあったのですが、開発費が高くて時間がなくて断念することが多かったからです。 。

したがって、BAAS とローコード プラットフォームを構築したいだけであり、将来何かアイデアがあれば、それを設定して実行可能な最小限のバージョンを作成するだけで済みます。

この両方が達成されました。しかし、今年は再びローコード プラットフォームを取り上げました。 Form Engine と Views Engine を分離して個別に使用し、他は破棄します。

もともとこのローコードプラットフォームは、何かを簡単に便利に作るために始めたのですが、もともと非常にシンプルだったものをローコードで構成すると、より複雑になることに後で気づきました。 。

なぜ？

一方で、コンフィギュレーションを使用してローコードをベースにさまざまな製品を構成することは、多くのことを抽象化し、さまざまなシナリオに適応させる必要があることを意味するため、論理的な問題がますます複雑になります。これにより、構成条件がますます増えていきます。最後に、たとえ小さなことであっても、多数の条件を設定する必要があります。

とても迷惑で、蚊に大砲が当たっているような気分です。

一方で、ローコード プラットフォームに基づいて構築されたものであっても、たとえ小さなものであっても、実行するにはローコード プラットフォーム全体に依存する必要があります。実行効率とある程度の計算能力コストの問題があります。

したがって、より良い方向であるローコードは、「構成的」であるべきではなく、インターフェース設計に基づいて、実行用のコードを直接生成する「生成的」であるべきです。
実はそういうのがあるんです、伝統的なやり方。

さて、私は誰かが GPT を使用して生成的なローコード プラットフォームを実装することを検討していることを知っています。私はこの方向性について楽観的です。