I’m currently in the process of converting a no code product to “pro code“ per their definition, and I agree with their intentions here.
Many of these efforts in the past (including the team I’m on) lump opinionated libraries in with what I call secondary programming languages.
Opinionated libraries can save everyone a lot of time, as long as they are programmable and allow easy access to levels below, as well as further abstraction upwards. Throwing a new programming language into the mix interferes with abstraction traversal and stack traces in a devastating way.
There is a huge advantage to using an existing language (JavaScript/TypeScript) like this, compared to creating new DSLs. There is simply such a big ecosystem to leverage in terms of development tooling (auto-complete etc), existing libraries and existing libraries.
Firm agreement about the goals! Over at Dark (https://darklang.com), we've been referring to the space adjacent to Low/No-code as "Just code", to indicate that there's only code there and nothing else. Would be curious what other languages/frameworks the JourneyApps folks would include in "Pro-code"?
Good question and we also resonate with "Just code".
OXIDE at its core is built on-top of a radically new framework we architected called Reactor which allows us to build desktop-grade software in the web (such as OXIDE), which we then used to craft the ultimate experience for the Journey ecosystem.
Apps built on Journey are currently developed using Javascript or Typescript but because of the highly modular nature of our tools and platform, we are going to start supporting more languages in the near future.
I wonder if you are familiar with the predictive databases?
We at Aito.ai have gotten lot of interest from different RPA/no-node users and providers, and predictive database queries seem like a best intelligent automation.
It would be interesting to deeply integrate predictive functionality in your system, especially as it integrates a DB naturally. This could be used to offer predictive functionality from the plarform out of the box.
IMHO if you want to attract no-code users you need to change your site branding. It's very 'engineerish' aka probably fine for the crowd on HN but not on Indie Hackers. Look at Webflow/Airtable/Zapier and take inspiration. You're going to have a hard time resonating with that crowd. They like bright colors.
I'm a bit confused here. The article starts out talking about no-code software development and the advantages and limits of no-code software, then lays out a bunch of principals including things like using an OSS stack. Then at the very bottom drops what looks like a complicated TS development IDE with some bolt on tools (which appear to be for-fee/ non-OSS).
Who is the target market for this? What kind of app would I write with it? Since Could I build up an OXIDE stack myself and make some apps for my friends?
About the only use-case I can see here is enterprise app development and personally, I think tying yourself to a vendor Platform-as-a-Service solution like this is a bit fraught.
Hi there! So OXIDE is interesting in that it has what we believe are the best of the typical low-code tools, but integrated in a way that the developer can easily transition to and fro into typical pro-code development. The screenshot on the homepage shows a plethora of the various tools and features that OXIDE has, but the IDE can easily be configured for low-code or pro-code development independently. Out of the box we provide some default workspaces that cater for the typical paradigms of software development on our platform, which are not as complex as in the screenshot.
Regarding the OSS, we deeply integrate it into the IDE effectively removing most of the configuration and complexity required to make it all work well together.
Hey ogre_codes, thanks for your question. Our core target market is enterprise app development. We have many of these customers who are using the platform today. We built this new version of our IDE based on a need that we identified by spending a lot of time talking to our customers. Using traditional professional development approaches (for example, .NET, hybrid app frameworks, native app dev, etc.) is just too expensive for them to build all the apps that they need. That's why many of them have adopted low-code/no-code platforms which allow them to build apps with a point-and-click approach. But the problem is that the limitations of those platforms become problematic when they start building slightly more complex apps. That's why we built our platform (and our new IDE) to fill the gap between no-code/low-code and pro-code tools: We created a high-productivity platform that is code-centric (JavaScript and TypeScript). We've done studies with our customers showing that using the platform is between 9x and 10x less expensive as far as developer hours to build enterprise apps.
The app looks really interesting but I'm hesitant to consider it for any practical projects due to the pricing model. If I'm reading it right, it's 25 dollars per app per user (not developer?) per month if you want to include features like GitHub integration, billable annually in advance. So, US$300 a year per user, or multiples of that if you have several apps for the same user? What's the target market this kind of pricing has in mind?
Hey OliverM! Cofounder of the company here. Thanks for your question. The primary target market of the platform is midsize to larger companies who need to build apps for their employees and customers. We've seen that the platform has strong ROI for these customers compared to the alternatives they typically have for developing these apps (where all-in TCO can get quite high — as much as six or seven figures). Our pricing is competitive relative to other high-productivity enterprise app platforms, especially since it's a cloud-native full stack (dev environment, cloud backend, etc.)
Ah, interesting. As a software contractor I'm outside that target market, and maybe even a competitor to your product in that I offer services to that market. It's something I'd love to play with though - so much "procode" as you call it is detail-oriented arcane config rather than coding and it would be good to have a tool that accelerated (or removed outright) that work. Kudos.
Many of these efforts in the past (including the team I’m on) lump opinionated libraries in with what I call secondary programming languages.
Opinionated libraries can save everyone a lot of time, as long as they are programmable and allow easy access to levels below, as well as further abstraction upwards. Throwing a new programming language into the mix interferes with abstraction traversal and stack traces in a devastating way.