No-Code vs Pro-Code: A New Hope

When it comes to building apps, no-code is having its moment. Typeform is a shining example of how no-code is well suited for simple use cases, and here at JourneyApps we use it extensively. However, therein lies the problem: No-code’s sweet spot is simple use cases. This limitation of no-code tools has been well analyzed. [1][2]

If you want to build more sophisticated custom software, you essentially have two options:

  1. Use a no-code/low-code tool and jump through nasty hoops to implement the sophisticated parts of your app — which most often means writing actual code that needs to conform to the constraints of the tool.

  2. Use pro-code tools such as Swift/Objective-C, or frameworks like Xamarin/MAUI, etc.


Image: building anything beyond basic logic with a visual programming language ends up looking like this

A Big Problem That Needs Solving

Both of the above approaches (using pro-code, or using a low-code platform’s pro-code extensibility) are time-consuming, although for different reasons. Both also require senior developer talent, while senior developers are as scarce as hen’s teeth.

The result is that many companies are highly constrained while executing on ambitious software and digital initiatives.

These are the companies that we serve. Enterprise developers have been building custom apps using code on JourneyApps since 2009.

Towards the end of 2019 we wanted to up the ante. We wanted to offer a new app development paradigm for companies with a large app backlog, especially where a big chunk of that backlog consisted of ambitious B2E and B2B apps.

We set two high level goals for ourselves: help companies write great software much more productively (especially those whose core focus is not software), and let them do this using modern software technologies and best practices, without the typical barriers.

Key Tenets of What We Set Out to Build

We decided that the best thing we could do was to build a next-generation IDE (as a complement to our full-stack app platform) that has the power and flexibility of pro-code at its core, but also has the high development velocity and easy adoption of no-code/low-code platforms.

From the start, we decided that some things are non-negotiable:

1. Coding should be easy

  • Creating a new app shouldn’t require any configuration or setup.
  • Developers should be able to start coding immediately.

2. Coding should have a fast feedback loop

  • We will have a first-class IDE with real-time error checking, keyboard shortcuts, IntelliSense, etc.
  • Developers should have access to a real debugger.
  • We will have live, stateful hot reload on an actual device in development mode — not a time-consuming compile & deploy process.

3. Coding in the IDE should be fun and relevant

  • We will not use a DSL: We will support open-source programming languages – preferably those with gradual typing.
  • We will not use convoluted proprietary visual interfaces.
  • We will not use a proprietary “app store”. Developers must be able to import open source packages.
  • The IDE should be easily accessible to junior developers.

4. Coding should be as efficient as possible

  • We will provide developers with powerful functionality that can be used with minimal lines of code, and customized as required. This will include things like bi-directional relational offline data sync, dozens of UI components including Excel-like data grids, full audit trails, a cross-platform BLE engine, to name just a few.
  • We will offer full git support with either hosted git, or external git providers (e.g. GitHub)
  • We will support unit testing.
  • We will support multiple environments, with easy portability of changes as new versions of software are moved from one environment to the next.

5. There should always be an escape hatch

  • There will be APIs for everything.
  • We will allow developers to easily mix in fully custom HTML in their UIs, and allow those custom HTML components to communicate bidirectionally with the rest of the frontend stack, when required.
  • There will be a Node.js environment in our cloud backend where developers can build any custom backend functionality, without any configuration or setup.

6. The platform should be secure by design

A Foundational Decision: Building a Web IDE

We were taking the time to figure out a new approach to app development from first principles, so we had to make big design decisions with significant trade-offs. One major early decision was whether to build a web-based IDE or an installable desktop IDE.

The obvious question is: “Why an IDE on the web?”. We strongly believe that the recent developments across browser technology, transpiled languages and new approaches to software development (such as declarative UI) have made it possible to not only reach a desktop-grade level of quality in a web IDE, but also capitalize on the inherent benefits of the web paradigm.

Using this approach, we would have an IDE that is evergreen, cross-platform, cross-device, backed by modern UI and most importantly, ready for the future. Oh, and there would be nothing to install. Perhaps the biggest win, however, would be our ability to innovate quickly due to the open nature of web technologies and how quickly they evolve.

We’ll discuss other key design decisions in separate posts.

Unveiling the Solution

Today, we’re incredibly proud to announce OXIDE. It’s the fruit of a lot of hard work by the JourneyApps team over the past year.

OXIDE helps both junior and senior developers build sophisticated cross-platform apps using JavaScript or TypeScript, complemented by visual tools. Apps can run natively on mobile and desktop operating systems, or in the browser as PWAs. Under the hood, OXIDE uses CRDTs [3] to enable live co-editing in teams, and it is deeply integrated with both GitHub and npm. In OXIDE, developers can switch between visual editing and coding for UI layout and schema design. Developers also have access to a first-class code debugging tool.

OXIDE is a fundamental pillar of the broader JourneyApps platform. Therefore, all apps inherit other flagship JourneyApps technologies out of the box — technologies that have seen around 10 years of R&D and battle-hardening:

  • All apps ship with an enterprise-grade BaaS, and it’s easy to integrate with other data sources (in part because the platform is not based on a DSL).
  • All apps are offline-first: Data is automatically synced to user devices, and loaded from the local database on each view. Querying data is fast. This avoids complicated state management and/or query cache systems. (What happens when data volumes scale? The platform provides highly configurable selective syncing.)
  • Each app is automatically provisioned with a Node.js serverless compute environment so that developers of all skill levels can add server-side logic and functionality.
  • Developers have access to a rich built-in UI component set that is designed to work with data, with very little development overhead. No tweaking of styles or adding event listeners and state management to each component — this is handled for you.

In general, JourneyApps takes the complexity out of the development cycle. We take care of the hard problems of enterprise software development (hosting, offline data sync, mobile app builds, backend APIs, deployment tooling, audit trails, and more) so that developers can focus on core app requirements and maximize the rate of innovation at their companies.

Working in OXIDE looks like this:


And here’s a view of a debugging session. The app can be seen on the bottom right (running on macOS), the Chrome developer tools on the top right, and OXIDE on the left:


Try it out and let us know what you think — Try For Free.

← Back to all posts