What I'm using now instead of Rebol

I still use Rebol apps regularly in my daily business life, and it's still my go-to for creating quick utility scripts. But for connecting with modern services and doing everything else I need, I've been using the Python Anvil framework. It's incredibly productive, runs and deploys absolutely everywhere, and is ridiculously easy to learn. With all its modern features, everything just works out of the box, and for the sorts of work I do with it, it ends up being more productive overall than Rebol. I wrote a 150 page tutorial, with 200 screenshots and 22 app examples: <a href="https://pythonanvil.com/">https://pythonanvil.com/</a>

Absolutely everywhere? I appreciate a major new work from you, but I can't seem to find the targets for Atari 8-bit and Syllable. :-) And you don't seem to have found the Anvil replacement for MakeDoc. :-)

Thanks for the great learning materials, they were the ones who opened up Rebol for me. Regarding Python, it is a classic programming language with a large number of libraries, but it is far from the first in brevity :) Regarding the framework - this year, many users from Russia are faced with the fact that the authors of some frameworks and libraries inserted code into them, which, by determining the Russian IP, corrupts all user data on the local disk, for example, node-ipc (https://security.snyk .io/vuln/SNYK-JS-NODEIPC-2426370) which is a dependency for more than 350 packages... And unfortunately this is not an isolated case, even bookmarks are made in firmware for microcontrollers (https://github.com/arendst/Tasmota /commit/98cbf2587a1a914bbd16996ebb48dd451d3da448) which, if stopped in critical infrastructure (medicine, fire / chemical / industrial safety), will bring a lot of trouble. But what is no less important is the "gluttony" of frameworks. For example, for a simple calculator (https://calculator888.anvil.app) using the framework, we need a modern browser that requires a modern OS, which requires a modern and powerful PC, as well as more than 5 (!) megabytes of network traffic! 0_o Although this technology may well be in demand for someone, but I pass :) P.S. A small wish from the reader - please take screenshots at the minimum screen resolution so that the text on them is no smaller than the printed text of the book, otherwise it is impossible to read the text on them, especially in printed form. P.P.S. Thanks again for your much needed work!

I was going to do the tutorial in Anvil, but screenshots of Anvil, in Anvil, looked a bit like reflecting a mirror in another mirror, so Makedoc 2022! Sergey, I've also enjoyed doing some work with Lua - probably a bit more appropriate for your tastes. The old Corona game engine was released as open source: https://solar2d.com/ Lua is a compact language, typically with compact interpreter implementations, and it tends to run quickly. If Python didn't have so much support, I'd prefer to live in Lua world...

Python is from the city next to me, and three decades old, so I think it's time they pass the cup. ;-) REBOL's real-world productivity has deteriorated for many years, since R2 was abandoned. Most things you do inside REBOL are great, but when you need something from outside, the trouble starts. I don't think productivity is a good argument for REBOL anymore, but there is no reason it couldn't be restored. All those frameworks such as Anvil are built on existing languages, and it could be done for REBOL family languages, too, at least as well. I, too, evaluated many of those languages over the years. REBOL always came out the winner of the comparison, in any case as far as pure language power was concerned. It's extremely frustrating that this power hasn't been used to maintain real-world usability, so I have taken matters into my own hands. We can and should fix this, or be forever regretful. Hard comparisons with other systems show that improvements of two to three orders of magnitude can be achieved. And that is without the less measurable issues such as resilience of the world we live in now. It would be bizarre to pass up this opportunity.

Nik, what version is this Makedoc 2022? Where i can see it? :) Lua is next in line for me. heard a lot of good things about him. It is used when programming ESP-8266/ESP32 NodeMCU Lua microcontrollers. Solar2D is an interesting engine project, and for Lua there are plenty of crossplatform GUI tools. In general, I will definitely pay close attention to it, especially since the Rebol program containing a line like "lua_lib: load/library %lua54.dll" promises to create an interesting world for life and creativity :) Kaj, if Rebol is always your favorite then why did you take up Meta instead of working on Rebol3? For me, Rebol - lamp thing. I don't know if there is a similar expression in English, but I'll try to formulate - Rebol is like a tube amplifier or a record player, against modern amplifiers and CDs / mp3. Modern - without a soul, the sound is always the same and pure, and tube things with a soul, which in the form of harmonics and interference is superimposed on the sound and makes it alive and constantly different / new. In the digital age, the rustling of the player's needle in music, romance and those feelings that I experienced as a child listening to records are very lacking. I even print and rebind books myself, they are more convenient and pleasant than electronic ones, although they are larger and much heavier :)

I did work on R3, a decade ago. I wrote bindings as R3 plug-ins to cURL and ZeroMQ, to add missing functionality to R3. First in C, then when Red came, in Red/System and Red. Then, R3 was abandoned, so I continued with Red. But it didn't fulfill its promises, either, so I had to think about something better to solve those problems.

"...was abandoned..." By whom? Carl? But it seems to me that this banner was raised and carried first by Atronix, and now by Oldes. I'm just interested in your motivation. Once upon a time, I also tried to make my own programming language based on REXX, because. he was in the system (PC-DOS, OS/2) and processed words depending on the position. A line like "if then>if then=if" was executed correctly, "if" is executed as an operator if it is where the operator should be and as a variable if it is where the variable should be, this allowed simple instructions to be processed with minimal cost in human language. But all the acquaintances left for more classical languages, asm, c / c ++, focal, basic ... For myself, the motivation was only enough for a prototype :( Now I would rather join the development than develop my own, because going into the finished product from scratch takes time and I'm very impatient :)

Some people seem to be puzzled by my motivations, so I wrote about them here: https://language.metaproject.frl/#who I just need a capable programming language for my work, and nobody has delivered. REBOL was first abandoned by Carl. Then it and its community were torn apart by competing interests. I had no interest in that struggle, because I had already joined Red. Eventually, most competing interests also abandoned R3. It now feels quiet enough to use it again, and recently, Oldes has continued it in an authentic way. But I was already working on my improved design, that solves problems of both REBOL and Red. I tried for two decades to use and contribute to an existing language, but it sabotaged my work. There are reasons that so many people left. The common alternative is to settle for some other language, but my designs are based on REBOL abilities, so I can't do that. I used Ruby for the Syllable build system and ORCA for its package manager, but it drags me down. So after two, three decades I had to make the big decision to roll my own, and now I need to promote it to get the community and funding to keep it going.

Hi Nick, Are you using Anvil for any serious jobs (commercially) at the moment?

@Nick Thank you for the tutorial. @Sergey_Vl "ESP-8266/ESP32" Those things are amazing. It's unbelievable how powerful little microcontrollers are.

Rebol WASM works fine for me. I am managing to create a number of rebol apps that run in the browser

Daniel, Yes, I've got several contracts for large projects and lots of little apps working right now in Anvil. Graham, What implementation of Rebol WASM are you using?

Here's an example: https://geosearch.anvil.app/ That little app is using the Google Map API for geocoding, the typesense API for geolocation searches, and the Anvil API for UI, server, and database functionality. The whole thing is a few dozen lines of code. https://booksearch.anvil.app/ That one uses the typesense API for fuzzy search. It's FAST - searching millions of items takes a fraction of a second. Learning these APIs and implementing this sort of functionality, with front end, back end, database, and multiple third party API integration takes part of an afternoon with Anvil. Deploying to any modern device (Android, iOS, Windows, Mac, Linux, Chromebook, etc.) takes 10 seconds, and users don't have to install *anything* to run the app (with an optional icon on their home screen). That sort of productivity and power is hard to beat. It took me one afternoon to port the main guts of my guitar chord diagram maker from Rebol to Anvil, without any previous understanding of their canvas API: https://chords.anvil.app/ The Anvil IDE is browser based, so I move several times a day between different machines at any location, and pick up exactly where I left off at the previous machines (again, with absolutely no software installation on any machine, and I can be on any Windows netbook or Chromebook I own, on my girlfriend's iPad, on an Android, etc. - it works flawlessly everywhere. Python isn't as beautiful a language as Rebol, but when it comes to productivity, it's not so much the language that really matters, but all the features of the framework, libraries, connectivity, code examples for every API, etc. which really help with the heavy lifting. Just the database built in to Anvil, and the UI, make most CRUD tasks child's play. Python lists and dictionaries are great for dealing with the sorts of things I used Rebol blocks for, and I've even written scripts to help port data structures between Rebol and Python. In many ways, things like Python slices work even more beautifully than Rebol's series functions. I find myself doing fewer casting operations in Python (ints, floats, and strings get used for lots of operations), and f-strings make easy work of concatenation. And I can't even begin to fault Python's connectivity and breadth of libraries. The ease with which foreign APIs and complex functionality can be implemented quickly is the sort of practical functionality that makes Python (and Anvil) really productive... and of course a quick Google search will yield working code for just about any task you need to complete. It's hard to overemphasize how important a part all those pieces play in creating solutions for clients. And it goes beyond that. When the new Raspberry Pi pico W board was released, their was a commercial bootloader to connect an Anvil uplink to it, within days. And with that, I can build little hardware devices with a $6 microcontroller, using readily available APIs that I can connect with freely. That's the value of an enormous community, and why I'm using Anvil/Python. I love Rebol, and would love to work with it more in the future, but to built apps productively, Anvil is the sweetest spot I've found yet.

Since I'm indulging, I'll point out a few more features off the top of my head, which have made an enormous difference in terms of how little time I need to spend getting things done with Anvil. First, I never mess with any server settings, file uploads, linux commands, etc. - that's all baked into the framework, and you'd be amazed how cutting out toolchain componentry works to eliminate time-consuming work. Also, sharing code with clients and others who want to work with the code is as easy as sending a 'clone' link via email, Slack, an SMS message, etc., and built-in version control, GIT integration, etc. make it very easy to work on production and development versions. Having so many composable pieces of software development tooling built into Rebol, back in the late 1990s, and being able to use it across multiple platforms, with only a 1/2 meg executable made it so productive, even well into the 2010's. But without modern web and mobile support, and without the kind of adoption that encourages makers of new tools and APIs to write Rebol example code, and without the sorts of libraries needed to connect with machine learning, AI, modern ecosystems such as Micropython for building hardware solutions, there's just no comparison any more. Don't get me wrong, I hate most JS frameworks, even the full stack ones. And I hate having to use tools like django+HTML+CSS+JS, but Anvil is something really special. I'm excited to find solutions for clients again - it's really fun and exiting to have so much power at hand, with the joy that comes from being able to use the sort of great design and implementation that I discovered when I first began using Rebol.

In the past, I've set up Rebol development machines for an afternoon, at clients' locations, and written prototype code in person, so that we could iterate through versions of UI implementations and other design choices in person. I found this to be a great way to prototype with the actual users of the software, to help understand their needs and go through choices about implementation. With Anvil that sort of iterative interaction with clients is so much simpler. I just send them links with different version numbers, they try each one in their browser, and tell me 'I like this part of version 3 and this part of version 5'. No software installs, no physical meetings, just quick feedback, easy version control - all super simple to do.

It's hard to overstate how nice it is to be able to implement some complex functionality using a few lines of API code. Do you know how much work I put into video conference and things like simple SMS capabilities in the past? https://conference.anvil.app/ Implementing that JS API in Anvil took a few minutes, using code that was in an existing Anvil tutorial. And any service such as Twilio or Vonage, which provide Python examples, is typically just a few minute long endeavor to implement. Implementing mapping features, phone calls, machine learning models with huggingface, etc. - all SO easy. Oh, and the user management feature built in to Anvil - jeez, that saves soooooo much work implementing real apps for users. A couple lines of code turns a simple single user prototype into a production multi-user database app. And the built-in Google API features (and MS Azure, if you're into that) - I can access files in Google drive accounts, directly edit rows and columns of Excel files in those accounts, etc. C'mon, that would be so difficult otherwise... And if I need to build an uploader to convert someone's existing spreadsheet, just add a fileloader widget to an Anvil UI, use the Python Pandas library to convert the file, load it into the database, and I'm off and running. This stuff is the sort of functionality that makes Python/Anvil ridiculously productive. Tasks that used to make me cringe, it seems like every one of them is now a fun little project to dig into for a few hours - and then I've got some really powerful reusable pieces of code in the toolbox.

I still think Rebol's ability to create dialects is a method of design simplification, that the industry still needs to learn about. But in the meantime, I need to be productive, and simple integrated tooling, connectivity, and integration with the most popular and powerful ecosystems in modern tech go a much longer way to getting things done, than having the potential build more efficient language tools.

What attracted me to Rebol originally was its appeal as a pragmatic solution to building user apps. My interests, and none of my professional background has ever been about building languages or tools. And that's still the case. Pragmatic solutions to building user applications are what I'm interested in. I'm not concerned that a first run of an Anvil app requires 5Mb of traffic. That's a limited, static issue, which is simply not an issue for my clientele. What matters much more is that they can run my app on their iPhone or whatever other common device they have, without having to go through some time-consuming installation/configuration process that requires some (any) technical knowledge, and that I can build and deploy to all those platforms instantly. That's real, practical time and money-saving capability. Rebol spoiled me, and now Anvil is continuing to spoil me more than I could have ever imaginged.

Hi Nick. I'm not aware of any other than this one http://hostilefork.com/media/shared/replpad-js/ I'm using it to write prescriptions for patients including antivirals for their Covid, and I use it for billing hospitals for my work

Hi Graham, I'm glad to here that you're able to get some work done with Rebol in the browser, but that's a far cry from being a productive full stack solution. I'm assuming you're using HTML, CSS, JS for any front end design? I'm curious how data is saved on a server, and what the toolchain and backend development process involves. It looks like there's a workable replacement for JS on the front end (Rebol), and I imagine the backend server language (Rebol), and perhaps the data transfer protocol (Rebol series instead of something like Json), but what about the roles of HTML, CSS, database, and the work involved with interoperating with all the other pieces of the full stack? How difficult would it be to connect with the Google map API, for example, or any service which requires Oauth, or to connect to the API at https://typesense.org/ , without having the benefit of 'import typesense', for the languages they support? Solutions to those sorts of problems are what's needed in order to be productive. The biggest thing that can't be beaten is 'import <anything>' in Python. Building up an ecosystem as rich as Python's is something that simply can't be done, without decades of deep work, performed by millions of people. That makes the accomplishments of the Anvil framework pale in comparison. It's the availability of libraries, for every purpose, which makes Python incomparable. What if you want to record voice notes and send them to users' phones, what it you want to train an machine learning algorithm to recognize poison ivy, using an embedded system with a camera, which you can attach to your bike, for example? You can do that first thing with a few lines of Twilio or Vonage API code. You can do the second with any RP2040 microcontroller that supports Micropython and TinyML (there are dozens of those microcontrollers available on the market - and they cost a few dollars). Those sorts of things are *easy* with Python, because of the vast breadth of the Python ecosystem. Anvil just bridges the full Python ecosystem with a professional, full stack set of productive tools. Anvil handles every bit of the full stack development process, from front end, to database, all in one cohesive system. Just the user management service in Anvil is a game changer for building multi-user apps. And the Client-Server architecture *integrated with database security features*, built-in, makes building secure apps several orders of magnitude easier than trying to cobble together solutions with HTML, CSS, JS (Rebol), some data transfer protocol (Json or Rebol series), some RDBMS (Postgres, or maybe some files storing Rebol blocks), etc. - it's a whole different game when all the necessary parts are built-in and *integrated*. Anvil has a modern fully functional UI built-in, with a drag and drop builder (and/or you can build layouts entirely, or partially with *Python code) - you never need to touch HTML, CSS, JS, unless you want to style designs more deeply than the builder allows (all the normal expectations for fonts, colors, spacings, various flex-box type layouts, alignments, etc. are all built in, as well as rich repeating panel and grid data displays that can be instantly bound to database columns, with each row containing *any* sort of UI display). Material Design is the default style choice in Anvil, but several others are provided, and you can style however you want, with custom HTML, CSS, and JS (and any such changes are easily re-integrated into the UI builder and the Python object system). None of that needs to be implemented manually. You *can mow a lawn with a razor blade successfully, but that would take days of hard work, every time the lawn needs to be mowed. Isn't it a more productive choice to use a Husqvarna YTH18542, to get the job done more professionally in a few minutes?

It goes beyond all those features - it's the *work flow* - the built-in IDE with *autocomplete*, that runs on any modern device - being able to just open up any project I'm working on, on any machine, running any common OS, without installing anything... and deploying with the same ease (just send a link). My God autocomplete is so nice - it saves soooo much time, and eliminates sooooo many erros. Built-in versioning - just click a button to save the current version, restore and make any save point your production or development version, with a click (and every piece of that process is automatically integrated with GIT) - those sorts of things, *all integrated*. It kinda sounds too good to be true, but it's not. That's the sort of thing which is fully implemented in Anvil, and it's not buggy or quirky in the least. Every part of Anvil is implemented using best practices, and it *just works* in a way that feels not just slick, but utterly professional. I love the Rebol language design, and would love to see a light weight full stack framework built using it, for building CRUD apps, some day... But even once something like that were created, and if it were implemented beautifully, and if it became popular and well supported... it would takes decades to build the sort of capability which is available for the taking in the Python ecosystem. Anvil is *already there* 100%.

It goes beyond all those features - it's the *work flow* - the built-in IDE with *autocomplete*, that runs on any modern device - being able to just open up any project I'm working on, on any machine, running any common OS, without installing anything... and deploying with the same ease (just send a link). My God autocomplete is so nice - it saves soooo much time, and eliminates sooooo many erros. Built-in versioning - just click a button to save the current version, restore and make any save point your production or development version, with a click (and every piece of that process is automatically integrated with GIT) - those sorts of things, *all integrated*. It kinda sounds too good to be true, but it's not. That's the sort of thing which is fully implemented in Anvil, and it's not buggy or quirky in the least. Every part of Anvil is implemented using best practices, and it *just works* in a way that feels not just slick, but utterly professional. I love the Rebol language design, and would love to see a light weight full stack framework built using it, for building CRUD apps, some day... But even once something like that were created, and if it were implemented beautifully, and if it became popular and well supported... it would takes decades to build the sort of capability which is available for the taking in the Python ecosystem. Anvil is *already there* 100%.

Nick, that is clear and understandable. REBOL was designed for more than user applications, specifically to create a successor to AmigaOS. When Carl released iOS, it turned out he meant an Internet operating system more than a traditional operating system. I know what you mean, because a quarter century before Anvil, I specialised in Lotus Notes, which, for its time, did everything you praise Anvil for, and was the first to offer an integrated environment in a network setting. Notes was awesome and nothing compared, yet, when I made moderately complex applications for customers, I ran into limitations of the platform that the framework made impossible to solve. This made me remember REBOL, and I suddenly saw that it was designed to offer all of Notes' abilities in a fundamentally modular way. Sometimes some more work is needed to match an app in Notes or Anvil or all those other frameworks, but it is far less limited than such frameworks. Current limitations in REBOL family languages are accidents of management, not fundamental limitations such as in frameworks. That's why one problem with frameworks is that there is always a different latest and greatest one. There have been other Python frameworks before that tried to imitate the integration of Lotus Notes. You just told me about Anvil; I hadn't heard about it yet. I don't know how long I will be hearing about it. I don't think it's immortal. It certainly doesn't fulfill my needs. I am designing Meta not only for applications and groupware, but also to enable implementing traditional operating systems. Stuff Python can't do. Perhaps that doesn't mean anything to you. That's alright, but it means Meta doesn't have to replace Anvil to be successful. Still, replacing systems that seem too big to fail happens all the time, by nimbler systems that eat away at them from the bottom.

Of course, Anvil isn't made for building OSs, or web browsers, or any sort of system tools. Please don't get me wrong, I am very excited to see where Meta goes, and what can be created with it, but my purpose for using Rebol was always to create applications for end users. And of course you can do more with a general purpose programming language than with a spreadsheet system. That was the basis for my 800 page web site at business-programming.com - about the benefits of using Rebol to build business apps, especially as opposed to using boxed software, spreadsheets, and any other limited tooling which enabled less than custom solutions. There is no inherent limitation in using a framework such as Anvil - all it does is bring the entire scope of the general purpose programming language Python into a new environment, so that you can integrate all front end and back end work using that single language - incorporating and integrating everything that language has to offer, in a way that's much more naturally connected: functions on the server can be called by functions in the browser, and the database can be queried in Python, without any intermediate steps or pieces of the entire mess of 'normal' web componentry getting in the way. I'd love to see that same capability evolve with Meta or any Rebol based language - that's what I was supporting when Doc first began to build Red, but that goal was abandoned with his need to earn income. I think what you're doing with Meta is working towards what's been accomplished with Anvil, for Python. Anvil isn't a limited rigid framework that forces developers to stick with a few basic tools - the opposite - it's a system that enables developers to use the full scope of everything in the Python ecosystem, with far *fewer* restrictions upon any part of the development and deployment process than was previously possible. That's what I'd love to see happen with any sort of Rebol language tooling - You are clearly doing more to make that possible already, and I would love to see more of Rebol working seamlessly, directly in the browser, connecting with Rebol on the server, sending Rebol data structures directly back and forth between front and back end, and storing data in native Rebol structures - without any of the messy platform implementation problems getting in the way - so that one could just write pure Meta code for every part of the web app development process. Carl's idea with iOS was to create a better Internet, based on simplifying each component of his incarnation of the 'web', making server and client software speak more easily with one another, using more efficient designs for each piece of the distributed system. It would have been far better than how things on the web have evolved, of course. I loved everything about Carl's vision, and Rebol's implementation was brilliant. But that ship has sailed, the web exists in its current state, and that whole mess isn't going to disappear quickly. The idea behind Anvil seems to me to be very much in line with Carl's vision of simplification. They're just building it upon existing ubiquitous tooling (current browser standards, Python language, PostgreSQL database, etc.). There's no reason the idea of Anvil couldn't be implemented using Meta, for example, so that the entire development process for full stack web apps, could be performed using nothing but Meta. That's something I'd love to see. Anvil is just an implementation of all the tools needed to create full stack apps using Python, end to end - with a bunch of helpful tools which really do increase productivity in the development process. I'd love to see such a tooling stack evolve for Meta, which included version control and GIT integration, for example. And if not a GUI builder, a nice GUI dialect which runs in the browser (requiring no other language or tooling) - I always wanted to see VID or RebGUI ported to run in webassembly, with a graphic engine running on canvas or some other universal standard... With Anvil, they've just done all that already, and it's been done so professionally. It's just Python, for every stage of the development process, integrated with lots of extremely useful tooling to increase productivity (an IDE with autocomplete, version control, drag-and-drop UI builder, built-in database, etc.). None of that is limiting in any way comparable to using spreadsheets to solve problems that are far beyond their intended scope of use.

I hope it's clear, the last thing I want to do is suggest that developing something like Meta is anything but valuable. The modern web development environment is an utter mess - it's the incarnation of everything that Carl was hoping to derail before it became such a massive quagmire of badly constructed standards which have been pushed so far beyond their originally intended scope... It's just always been my perception that there's a sweet spot of features needed to attract a large community of developers, and to gain traction - which offers tremendous benefits, and if there's merit in changing standards, that should be part of the goal of any tool. Python has succeeded because they made it easy to build libraries, and to connect C code, with a language interface that anyone could learn and use. They dominated the data science arena with libraries that were better, and with implementations in a general purpose language that were simple enough for a large swath of developers to grasp - not as beautiful as Rebol, but much more approachable than C, Java, etc. What's happening with Anvil is happening all over - implementations of front end tools which run in the browser using WASM - connecting to back end systems in ways that had always previously required HTML, CSS, JS, JSON, (React, Vue, etc.). There's nothing wrong with building better, more accessible tooling to work with a language. That's all Anvil is, and I'd love to see someone in this community not discount the value of that sentiment.

Oh, I'm not discounting your sentiment, I'm saying I had very much the same sentiment a quarter century earlier with Lotus Notes. Pretty much all systems have problems with their implementation technology. REBOL is the ideal implementation technology for systems such as Lotus Notes and Anvil. In my private REBOL and Red systems, I always worked towards making them similar in concept to Notes. I am designing Meta to be even a few orders of magnitude better. On the other hand, I got to know the limitations of both approaches. It's like Joel Spolsky says it in his Law of Leaky Abstractions. For example, if you build web sites in dialects, you won't have access to all features of HTML/CSS/JavaScript. At some point you will need them or some customer will complain about it. I attempted several such abstracted designs and they tended to hamper functionality and productivity. It's better to start with supporting all functionality if you want to match any competitors. Another side of supposedly not having any limitations, is that the limit is that everything and the kitchen sink is included. It weighs you down when you need to do something lightweight. This was actually why web browsers eventually won over Lotus Notes.

Anvil lets you drop down to HTML, CSS, and JS, whenever you want or need to use it - there are no limitations there - but 90% or more of what you'll ever need to do won't need it. And in addition to that, Anvil provides some really nice methods of encapsulation HTML, CSS, and JS in ways that allow bits and pieces to be used (by defining styles as 'roles', for example). That's a productivity magnifier that doesn't impose limitations. I think the inevitable evolution of all this systems is towards more productive high level functionality which still allows for low level control. The low level control in Python is really enabled by making it possible/easier to implement libraries of low level functionality. The low level control in Anvil's front end capabilities is made possible by enabling full access to HTML/CSS/JS.

What really amazed me with Rebol was that high level capability could be built up with layers of composable language, as opposed to larger and larger libraries of rigid functions. That's a technique which hasn't been employed so much in the rest of the industry so much (except by the Lisp guys), and something which I think will be (re)discovered by other communities eventually.

Right, eternity is a long time from now, while current frameworks have lifetimes of around a decade. I have long been tired of switching frameworks. I want one that lasts me at least my lifetime. My private REBOL and Red systems have features similar to what you mention, inspired primarily by Lotus Notes. I'll review Anvil when I redo them in Meta.

Thinking about this more, I see a solution that's relatively simple. The biggest limitation with any system that isn't among the most popular languages/tools, is library and code example support, but I guess that problem is potentially fairly easily solved, just by calling code in a third party system. If you've got Meta running in the browser, it really shouldn't be to hard to integrate any code that's callable in JS, so that really solves the connectivity/library support problem. The biggest issue then, is just converting data back and forth between some JS data structure and Rebol. (There really needs to be support for Json in any new system!). JS seems like a great match for extending library and code example support to any system which runs in a browser, but even being able call a Python interpreter on a server to run some code which requires functions in an imported library eliminates the argument for not using a given language - it just requires some code to massage returned data values into Rebol structures. For example, I did this to convert a Rebol blocks to Python dictionary: R E B O L [] root5-shapes: [ "." "major triad, no symbol (just a root note)" [1 3 5 11 55] "m" "minor triad, min, mi, m, -" [1 b3 5 11 55] "aug" "augmented triad, aug, #5, +5" [1 3 b6 11 b66] "dim" "diminished triad, dim, b5, -5" [1 b3 b5 11] "5" "power chord, 5" [1 55] "sus4" "sus4, sus" [1 4 5 11 55] "sus2" "sus2, 2" [1 9 5 11 55] "6" "major 6, maj6, ma6, 6" [1 3 55 13 11] "m6" "minor 6, min6, mi6, m6" [1 b3 55 13 11] "69" "major 6/9, 6/9, add6/9" [1 33 6 9 5] "maj7" "major 7, maj7, ma7, M7, (triangle) 7" [1 3 5 7 55] "7" "dominant 7, 7" [1 3 5 b7 55] "m7" "minor 7, min7, mi7, m7, -7" [1 b3 5 b7 55] "m7(b5)" "half diminished, min7(b5), (circle w/ line), m7(-5), -7(b5)" [1 b3 b5 b7 b55] "dim7" "diminished 7, dim7, (circle) 7" [1 b33 b5 6 111] "7sus4" "dominant 7 sus4, 7sus4" [1 4 5 b7 55] "7sus2" "dominant 7 sus2, 7sus2" [1 9 5 b7 55] "7(b5)" "dominant 7 flat 5, 7(b5), 7(-5)" [1 33 b5 b7 111] "7(+5)" "augmented 7, 7(#5), 7(+5)" [1 33 b6 b7 111] "7(b9)" "dominant 7 flat 9, 7(b9), 7(-9)" [1 33 5 b7 b9] "7(+9)" "dominant 7 sharp 9, 7(#9), 7(+9)" [1 33 b7 b3] "7(b5b9)" "dominant 7 b5 b9, 7(b5b9), 7(-5-9)" [1 33 b5 b7 b9] "7(b5+9)" "dominant 7 b5 #9, 7(b5#9), 7(-5+9)" [1 33 b5 b7 b3] "7(+5b9)" "augmented 7 flat 9, aug7(b9), 7(#5b9)" [1 33 b6 b7 b9] "7(+5+9)" "augmented 7 sharp 9, aug7(#9), 7(#5#9)" [1 33 b7 b3 b6] "add9" "major add9, add9, add2" [1 3 5 99 55] "madd9" "minor add9, min add9, m add9, m add2" [1 b3 5 99 55] "maj9" "major 7, maj9, ma9, M9, (triangle) 9" [1 33 5 7 9] "maj9(+11)" "major 9 sharp 11, maj9(#11), M9(+11)" [1 33 b5 7 9] "9" "dominant 9, 9" [1 33 5 b7 9] "9sus" "dominant 9 sus4, 9sus4, 9sus" [1 44 5 b7 9] "9(+11)" "dominant 9 sharp 11, 9(#11), 9(+11)" [1 33 b5 b7 9] "m9" "minor 9, min9, mi9, m9, -9" [1 b33 5 b7 9] "11" "dominant 11, 11" [1 b7 9 44 444] "maj13" "major 13, maj13, ma13, M13, (triangle) 13" [1 3 55 7 13] "13" "dominant 13, 13" [1 3 55 b7 13] "m13" "minor 13, min13, mi13, m13, -13" [1 b3 55 b7 13] ] python: copy {} foreach [a b c] root5-shapes [ lst: copy {} foreach i c [append lst rejoin [{'} form i {'} ", "]] append python rejoin [mold b { : [[} lst {], } mold a {],}] append python newline ; append python newline ] editor python The returned Python dictionary values: "major triad, no symbol (just a root note)" : [['1', '3', '5', '11', '55', ], "."], "minor triad, min, mi, m, -" : [['1', 'b3', '5', '11', '55', ], "m"], "augmented triad, aug, #5, +5" : [['1', '3', 'b6', '11', 'b66', ], "aug"], "diminished triad, dim, b5, -5" : [['1', 'b3', 'b5', '11', ], "dim"], "power chord, 5" : [['1', '55', ], "5"], "sus4, sus" : [['1', '4', '5', '11', '55', ], "sus4"], "sus2, 2" : [['1', '9', '5', '11', '55', ], "sus2"], "major 6, maj6, ma6, 6" : [['1', '3', '55', '13', '11', ], "6"], "minor 6, min6, mi6, m6" : [['1', 'b3', '55', '13', '11', ], "m6"], "major 6/9, 6/9, add6/9" : [['1', '33', '6', '9', '5', ], "69"], "major 7, maj7, ma7, M7, (triangle) 7" : [['1', '3', '5', '7', '55', ], "maj7"], "dominant 7, 7" : [['1', '3', '5', 'b7', '55', ], "7"], "minor 7, min7, mi7, m7, -7" : [['1', 'b3', '5', 'b7', '55', ], "m7"], {half diminished, min7(b5), (circle w/ line), m7(-5), -7(b5)} : [['1', 'b3', 'b5', 'b7', 'b55', ], "m7(b5)"], "diminished 7, dim7, (circle) 7" : [['1', 'b33', 'b5', '6', '111', ], "dim7"], "dominant 7 sus4, 7sus4" : [['1', '4', '5', 'b7', '55', ], "7sus4"], "dominant 7 sus2, 7sus2" : [['1', '9', '5', 'b7', '55', ], "7sus2"], "dominant 7 flat 5, 7(b5), 7(-5)" : [['1', '33', 'b5', 'b7', '111', ], "7(b5)"], "augmented 7, 7(#5), 7(+5)" : [['1', '33', 'b6', 'b7', '111', ], "7(+5)"], "dominant 7 flat 9, 7(b9), 7(-9)" : [['1', '33', '5', 'b7', 'b9', ], "7(b9)"], "dominant 7 sharp 9, 7(#9), 7(+9)" : [['1', '33', 'b7', 'b3', ], "7(+9)"], "dominant 7 b5 b9, 7(b5b9), 7(-5-9)" : [['1', '33', 'b5', 'b7', 'b9', ], "7(b5b9)"], "dominant 7 b5 #9, 7(b5#9), 7(-5+9)" : [['1', '33', 'b5', 'b7', 'b3', ], "7(b5+9)"], "augmented 7 flat 9, aug7(b9), 7(#5b9)" : [['1', '33', 'b6', 'b7', 'b9', ], "7(+5b9)"], "augmented 7 sharp 9, aug7(#9), 7(#5#9)" : [['1', '33', 'b7', 'b3', 'b6', ], "7(+5+9)"], "major add9, add9, add2" : [['1', '3', '5', '99', '55', ], "add9"], "minor add9, min add9, m add9, m add2" : [['1', 'b3', '5', '99', '55', ], "madd9"], "major 7, maj9, ma9, M9, (triangle) 9" : [['1', '33', '5', '7', '9', ], "maj9"], "major 9 sharp 11, maj9(#11), M9(+11)" : [['1', '33', 'b5', '7', '9', ], "maj9(+11)"], "dominant 9, 9" : [['1', '33', '5', 'b7', '9', ], "9"], "dominant 9 sus4, 9sus4, 9sus" : [['1', '44', '5', 'b7', '9', ], "9sus"], "dominant 9 sharp 11, 9(#11), 9(+11)" : [['1', '33', 'b5', 'b7', '9', ], "9(+11)"], "minor 9, min9, mi9, m9, -9" : [['1', 'b33', '5', 'b7', '9', ], "m9"], "dominant 11, 11" : [['1', 'b7', '9', '44', '444', ], "11"], "major 13, maj13, ma13, M13, (triangle) 13" : [['1', '3', '55', '7', '13', ], "maj13"], "dominant 13, 13" : [['1', '3', '55', 'b7', '13', ], "13"], "minor 13, min13, mi13, m13, -13" : [['1', 'b3', '55', 'b7', '13', ], "m13"], The actual Rebol code is just a few lines, and setting up this sort of routine to bridge Rebol with Typesense arguments and results (or consider using a library like Tensorflow, for example), is not much work at all in the whole scheme of building a full app.

Yes, there are many possibilities. Most of my publications for REBOL and Red were bindings to C and C++ libraries. In Syllable and other operating systems, language bindings are an important but difficult topic. They are usually problematic and inefficient. REBOL is designed as a silo, and Red bindings are laborious and inefficient because they have to go through Red/System, but Meta is designed for easier and efficient binding to other languages, so it can make use of other systems. See its goals: <a href="//language.metaproject.frl#goals">language.metaproject.frl#goals</a> As I elaborated to Sam in another thread here, Meta does not need to reinvent the world, because it makes use of other languages: <a href="//language.metaproject.frl#features">language.metaproject.frl#features</a> The first language of choice is not Python, but C. C is much more ubiquitous and efficient, and there are probably still more C libraries than Python libraries. Like Sam wants a Meta back-end that generates Nim, if you really think Python is the way to go, you could write a Meta back-end that generates Python. Other forms of bindings are possible, too. The more work you put in them, the more elegant they can be in Meta. It's possible to make generic, automatic binding generators, but the most elegant is to abstract them into Meta types. Meta's type system is much richer than that of REBOL, to make both the language and bindings more elegant: <a href="//language.metaproject.frl#how">language.metaproject.frl#how</a>

One of my publications for Red was a JSON codec, that converts data between Red and JSON as transparently as possible. That's for remote communication. For local data conversion, much more efficient ways are available, depending on the language. Currently, the first plan for calling JavaScript functions actually goes through C, because the current way Meta runs in browsers is through Emscripten: <a href="//language.metaproject.frl#web">language.metaproject.frl#web</a>

I believe their are more libraries in terms of total count, for C, but most new 'high-level' tools and APIs release official bindings and code examples for JS, Python, Java, C#, Ruby... And Python leads, without reservation in all the 'data science' category of libraries (machine learning, data visualization, data wrangling, AI...) - and implementing those tools, is where so much of the business (money making) opportunities are. Just being able to import an officially supported library, drop in some JS or Python code, to implement some deeply capable solution (like Typesense, for example), enables capabilities which are far beyond what any single developer could ever hope to implement for a single project. Would you want to have to design a solution that implements Typesense's capabilities, just to finish a project? It took me a few hours last Wednesday to implement some serious search capabilities, including fuzzy search that deals with misspellings and natural language input, and geolocation based on distances between latitude/longitude locations, and connect that to the Google geocoding API, to produce wickedly powerful results for a client. One sitting in one night, without any previous experience with that system. That's not simple CRUD stuff - and the capabilities of tools like tensorflow - jeez man - those aren't the sorts of things that any single person is going to design to finish a project. All those modern libraries, which are specific to Python, for example, represent lifetimes of work encapsulated in tools and APIs which cannot be accessed other ways, except in the ecosystems in which they evolved. Look at Tensorflow's documentation: 'A word of caution: the APIs in languages other than Python are not yet covered by the API stability promises'.

I think Json is an obvious fundamental requirement - such a huge percentage of modern web APIs return data in Json. Maybe XML should still be supported...(?)

Again, I need to say that I'm incredibly impressed with what you're doing with Meta, and I wish I could be more involved (I'd be happy to help with testing, documentation, etc!). I'd love to have a usable Rebol-like system available to build full stack web apps - nothing would make me happier. Tens years ago, I did my best to develop interest in supporting mobile and web platforms for Rebol, and started financing work that would lead in that direction. I've been happy to have Rebol for Android as a result, for my own needs, but nothing has been viable for doing commercial development work with Rebol with new clients. Anvil is likely a more than a workable solution for any work that I may get involved in for the next decade (it's much more than workable, it's a special joy). But I'd be so much happier to see Meta become a viable choice for certain classes of apps. I deeply respect everything you've done in the Rebol community, and love to see your shared interest in Carl's values/goals and passion for the whole ethos which surrounded Rebol in general. I'm just hoping to provide some perspective on what's working for me, and hoping that there's still some way forward for a Rebol-like alternative.

Thanks Nick, appreciated! I have an unpublished HTML/XML markup codec for R3 and Red. I'm actually using the encoder to create all my new web sites. It's not highly abstracted like my previous REBOL and Red Content Management Systems, but it gives me full control over HTML/CSS/JavaScript, which I need for my recent web apps. It's a REBOL data dialect that at least helps with the most awkward aspects of web technology. It can be built on later by higher-level dialects. If we define Meta as an Anvil clone, it will fail as you say. It's a natural instinct to want to match anything a competitor has, but it's a loosing strategy because it's chasing tail lights as you say. Several of my strategies for Meta are the other way around. Instead of retracing the trodden path, I designed Meta to go where others are unable to go. There, there will be no competition. It will give Meta places to survive and attempt other ventures. I have long shared your frustration of most REBOL-related projects eventually being abandoned. To fix this, I designed Meta to be extremely generic and extremely productive. There should be no dead-end streets: everything should happen on Meta's main road. There should be no explosions of complexity in either the language or the project infrastructure: it should all remain managable by myself for times when I get no support and have to get by on my own projects: <a href="//language.metaproject.frl#when">language.metaproject.frl#when</a> Of course, support will be appreciated, so I am interested in opportunities where money can be made. The strategy is to change the planning to accommodate such projects. That said, in general, many library projects offer C bindings, some Interface Definition Language, or network API's, usually over plain HTTP, or some messaging system. When a Python binding is also available, it's usually not a good idea to go through Python, because it adds the complexity explosion of Python. When the library is written in Python, or some other language, obviously a binding to that language is inescapable. The form depends on the language. Many dynamic languages support a generic, dynamic bridge to their functions and data. Python probably does, but I would have to look into it. If viable, just one generic Python bridge would serve all Python libraries. It would be more elegant to match Meta's language abilities, but it wouldn't be mandatory. Another strategy of mine is to support constructing Service Oriented Architectures through messaging systems. In the past, I enabled R3, R2, Red and Red/System to interoperate by implementing ZeroMQ bindings for all of them. I used them to implement a commercial product. This avoids messy direct bindings between languages in the same process, while at the same time making your systems much more modular, flexible and scalable.

@Nick, since wasm runs in the browser ( as well in the cloud ) I have access to anything written in JS. There's enough functionality for most things, and as the JS engine improves, rebol wasm improves. To see how Rebol is interacting with JS, try http://hostilefork.com/media/shared/replpad-js/ and type `do @chess` without the quotes. Type `chiu-vs-jensen` for a demo game of mine from long ago! @Kaj - yeah, long time since we spoke. Last time was when we tried to find you when try Rebol stopped working in the StackOverflow chat!

@Nick, since wasm runs in the browser ( as well in the cloud ) I have access to anything written in JS. There's enough functionality for most things, and as the JS engine improves, rebol wasm improves. To see how Rebol is interacting with JS, try http://hostilefork.com/media/shared/replpad-js/ and type `do @chess` without the quotes. Type `chiu-vs-jensen` for a demo game of mine from long ago! @Kaj - yeah, long time since we spoke. Last time was when we tried to find you when try Rebol stopped working in the StackOverflow chat!

@Nick, since wasm runs in the browser ( as well in the cloud ) I have access to anything written in JS. There's enough functionality for most things, and as the JS engine improves, rebol wasm improves. To see how Rebol is interacting with JS, try http://hostilefork.com/media/shared/replpad-js/ and type `do @chess` without the quotes. Type `chiu-vs-jensen` for a demo game of mine from long ago! @Kaj - yeah, long time since we spoke. Last time was when we tried to find you when try Rebol stopped working in the StackOverflow chat!

I'm not that hard to find. I'm a public person with an email address and a number of profiles, including on LinkedIn, and I'm on AltME. I'm not on StackOverflow, but I vaguely remember you using TryREBOL from a bot. There was no guaranteed API, but I sent you some specifications when I changed it. I think that's why I started putting "/internal/" in API links. :-)

@Kaj, I think we did try contacting you. then we figured you had joined Andreas and Carl in disappearing into a cave somewhere.

As I said, you contacted me, and I sent you specifications for the changed API. It should be obvious that trying to contact me in places where I am not doesn't work very well.

Graham, cool chess example! (hehe, for that sort of stuff, I use Godot :')

Interesting, Godot is a lot like what I'm looking at for Meta's multimedia future. I could use it as inspiration, or write Godot bindings for Meta.

Cross post from the save wave topic, since Anvil was mentioned: To be clear, Anvil is NOT strictly SAAS - I stay away from those sorts of products completely. There is an open source version of Anvil server, and I run an automated backup routine of all my apps and data hosted by Anvil.works, so that I can pop everything up to a self-hosted server if Anvil's hosted product ever gets hit by an asteroid. And to be doubly clear, I do the same thing with any Rebol web app hosted on any third party servers. Running web apps in *any* environment typically relies on third party servers. I wouldn't use Anvil if there wasn't a drop-in open source self hostable replacement to rely on. The same is true of Typesense, BTW. I choose that over Algolia, specifically because Algolia is SAAS only.

Hosted solutions of those products offer great convenience, which are fantastically practical, but no tool I choose to use would ever make the list if it relied entirely on an SAAS product or some other closed source requirement, which would break my apps completely if the vendor ever went out of business or required me to make changes to my code base, based on their choice to deprecate or not support previous production APIs.

I spend time making sure I can implement any tooling on my own servers (on a machine at my physical location and/or in a cloud service), before I ever start to use it in production(!!). I did the same thing for Streamlit (which is another great Python tool for certain types of front end work). If I can't get projects up and running on a self-hosted, open source platform that I can completelely control in house, without a connection to the Internet, with version control, etc., I won't use it.

I'm amazed that people make such broad and critical comments as: 'Anvil is a Saas. Personally I wouldn't want to hand my entire business to a company like Anvil which can and will shut you down or change policies at any time and for any reason.' without doing any research. 'Anvil offers an SAAS solution for convenience, but you're not required to use it.' is instead correct.

Maybe this will make a little bit of sense. Take a look at this: https://rebolapi.anvil.app/ That took me a couple minutes. That Anvil app connects to https://re-bol.com/piglatin.cgi , where I just plopped in some old Rebol code to generate pig latin: #!./rebol -cs R E B O L [title: "CGI piglatin"] print {content-type: text/html^/} sbmttd: decode-cgi read-cgi output: copy {} foreach t parse sbmttd/2 "" [ x: parse t "aeiou" append output rejoin [ either m: find/match t x/1[m][t]x/1 either m["ay"]["hay"]" " ]. ] prin output (that code was NOT previously a CGI script, and of course it could be deployed in other ways than CGI - this is just a quick demo). I put together a quick little UI in Anvil, which I connected to a server function that sends an HTTP request to the script above, parses the response, and displays the results in the UI. There's no proprietary technology in any of that process, in terms of what Anvil is doing. The tools in Anvil just help me do that quickly - and it turns out that the full set of tools in Anvil makes up an absolutely beautiful toolkit to do 90% of everything that's needed to build most of the app functionality I need regularly. So I can still interface with Rebol code with Anvil, for some complex data processing that perhaps I don't want to have to re-implement in Python. I'm just choosing to use Anvil because it's a nice professional toolbox that gives me access to just about every capability I could ever imagine needing, to build apps for the next decade+. Now take a look at this freakin thing: https://anvil.works/pico I've got some pico W's coming in the mail today, so that I can build a quick little foot operated wireless push button hardware page turner, which I'll use to turn pages while I sing and play guitar. That project should take me one sitting to build with Anvil - without their support of pico W, with uplink support, that project would be much much much harder. Perhaps those couple little examples shed a tiny bit of additional insight? It would be so nice to hear 'that's pretty cool', or at least 'that piques my curiosity', instead of off the cuff uninformed criticism (referring to the comment that Anvil is just SAAS). I'm loving the idea of being able to use and connect with Meta tooling, as it becomes more mature!

There just aren't yet any tools that provide the broad scope of capabilities I can achieve with Anvil so productively, built with Rebol, or any other language (and I've been looking hard for 40+ years, and tried many hundreds of tools over the decades). I started really just looking at Anvil for modern multiplatform UI, after finding Streamlit, Remi, PySimpleGUI (with Remi, PyQT, and others as a backend), and Anvil did the UI work sooooo much more professionally, and it turned out, the other backend features were deeply powerful (UI was just a small fraction of its functionality). I'll probably still use Streamlit for UI at times - it's fast and easy to install in house, and is even more more concise and elegant than any UI that ever existed for Rebol - plus it provides nice access to camera on every device, for example, without having to use any third party API. I love collecting tools, and using the right tool for the job. I love doing the research about their capabilities, putting them in practice and learning about their drawbacks and limitations. I used VB for DOS in the very beginning (even though I cut my teeth on C and Lisp in school) - and there are still some VB for DOS apps running in Indianapolis businesses, which I wrote 27ish years ago. I did a ton of work with AutoIT in the early 2000s. I went through a Lua loving period for a while last year. I spent some time using Livecode. I used Haxe when Flash first began to die out. And of course Web tools have been around for a few decades, and I use whatever I need there... Everyone who comes here thinks of me as a Rebol guy, and Rebol has been fantastically useful to me, but I'm into whatever works to make things happen, productively, in the real world.

I just got my Pico W's. Just for fun, using one of the Anvil examples as a starting point, I'll make a Rebol server script generate the Morse code from user input sent over WIFI from an iPad or Chromebook front end, to flash lights on the Pico... Would anyone else like to try doing that in an evening without Anvil? Of course that's a little silly and just for fun, but I see those sorts of practical productivity gains in every project I approach with Anvil. It's just a great set of basic tools to use in my tool box.

I have every intention to enable Meta to do that, in an evening in an executable of a few kilobytes, without going through a remote server running PostgreSQL and everything.

I have always been very interested in your publications and your tool choices besides REBOL, because I know you have a keen feeling for them. I also like your enthusiasm and pragmatism very much. I believe you immediately when you praise Anvil, and of course, it's cool what it can do. Why I am reluctant to say that, is because this is your REBOL forum. It's one of the last places where we keep REBOL alive, and I don't want that to be watered down. We have both been evaluating tools for around fourty years. Where we differ, is that, while I enjoyed collecting them on my Atari 8-bit, I grew tired of it after I was forced to work on PC's. I found PC's to be uninspiring, so I needed to look for inspiring software to somewhat compensate. The first was Lotus Notes. I can clearly see where Anvil still lacks compared to Notes more than thirty years later. I have seen it all before. I want fundamental progress, not the deterioration all around us in our field, due to ignorance and stubborness. With REBOL, Carl invented a unique and timeless design. It was after Notes, so I can't fault Notes for not being implemented in REBOL, but most systems after it should have been. As Carl did with iOS and AltME. I don't want to spend my brain power on learning all the petty details of several trendy new systems every year. I have always spent it on thinking how to improve and modernise REBOL. It's a big step to actually do it, but it needs to be done, and it needs the support of a community.

Kaj, You are championing a great cause, and because you have stayed focused on engineering, building tools from the ground up in C, you'll be able to create tooling in ways that I can't. There's no question in my mind that you will find fantastic support, once Meta is mature enough out of the box to be put to use for mainstream work. I'll be on the front lines hoping to help out as much as I can. Honestly, it's a tremendous satisfaction to see you focused on building Meta. I tried so hard for so many years to try and rally community, pay for work to be done, etc. My position and needs have changed, but I have no less interest, or belief that what you're stepping up to do is valuable - more than valuable - a real hope for the industry. I still think it could be very successful commercially if it solves the right problems.

Kaj,"...Sam wants a Meta back-end that generates Nim..." You misunderstood me. My, possibly insane, idea was that instead of writing all the C code for Meta or using R3 you could use Nim. Which compiles to C, C++ or JavaScript. Maybe this is stupid but two different Rebol like languages have been written in Nim. There must be a reason why. Nim's "...Nim has a powerful macro system which allows direct manipulation of the AST, offering nearly unlimited opportunities....". Nim also has lots of built in goodies like garbage collection that can be tuned to different levels. The basic idea is to get something running faster. I wrote this idea a while ago. I think my understanding now is that you want to control things top to bottom so this is probably not for you. I wonder though if Nim could be used to toss something off quickly. It might be great at building a prototype and testing what works and what doesn't then go back and code the rest from scratch.

Sam, sorry, I mended your words a bit to fit the situation. I think prototypes are a waste of time and show weakness of the prototype language. I designed Meta to be able to develop prototypes smoothly into the final products. I'm also doing that with Meta itself. It's currently a prototype that is already very powerful because it uses REBOL and C. A final performance boost will come when I port from REBOL to Meta itself.

Nick, thanks for your words of support. I always saw your support for advancing REBOL, and it was part of the frustration that the makers of projects let your support end up in dead ends. I tried for too long to support projects of others. I should have taken the wheel years earlier, but I wasn't sure if I could. A lot of time is lost, but I did spend a lot of thought on how to catch up, and that's why several aspects of Meta are different and extreme. One aspect is that I'm developing Meta to support use cases one by one, not in one big 1.0 dump that takes a decade to develop. I hope REBOL people will get used to that and not wait until Meta is compatible with REBOL, which will never happen.

Kaj, I don't care that Meta is compatible with Rebol, just that it's productive and capable. UI is an important priority for creating user apps, and modern UI for most users seems to be most productively implemented in the browser - and browser based UI provides a bit of future-proofness, because new platforms will likely provide a browser, and everyone is comfortable using a browser, no matter what OS they're on. Not needing to install apps is also a great boon for most users. Also, updating apps just has to happen on the back end, without having to rely on the user going through a download/install/security configuration process to keep them up to date with most recent versions of apps. Please forgive me if I've missed it, but where is browser-based UI, without HTML, CSS, JS, React, Vue, Svelt, etc., in your roadmap? How far along are you in getting dug into that? For me, getting communication going between client and server, using the same language and data structures on front and back end, along with data persistence on the server, using the same data structures, is the heart of making the system usable. Whether that language is compatible with Rebol isn't important - just that it's compatible with itself on front and back end. I think that's the basis of productivity - as long as the language isn't a mess (JS).

That's a great attitude, and matches well with my goals. I don't put things in the road map if I can't make concrete promises about them, so most things will depend on funding. But broadly, the first Meta year was getting it working, using Atari as baseline; the second year was setting up more project infrastructure, supporting the most popular platforms and introducing more audiences. Coming year will be a push for more platforms and more audiences, to see who is most interested. I do have a plan to show basic UI bindings as proofs of concept, but I don't know yet in what order I will do those things. In general, Meta is very much about integrating with existing systems: often the opposite of REBOL. I don't aim for full Meta systems until well in the future, because it's a lot more work, and there is lack of acceptance of such concepts. Instead, it's about combining the strengths of different systems, and replacing parts of them with Meta as it grows stronger. First, Meta will be more like a glue language, like Lua. As it becomes stronger, it will be able to be more standalone, like REBOL.

For me, making end user apps, UI is a huge part of what glues things together. Just text field, button, image, drop-down (or another multi-select), and some sort of data grid/repeating row widget, along with basic column and flow page layouts, cover most business app needs. If you're trying to attract an audience, having UI in place with those basic features, would resonate.

What got me into Lua recently was seeing that Corona been open sourced (Solar2D), and then Lua Studio - each with UI that worked just as well on desktop and mobile (and Solar2D supports web).

Web is the only UI that needs to be supported, as long as it connects to a back end system for data persistence, integration with other systems, etc.

Just a thin wrapper around HTML, CSS, JS, so that language and data structures are the same on front and back end, is all that's needed. I bet you'd find lots of community support getting a system like that built up. Everybody and their brother would be added UI functionality.

Maybe a wrapper for canvas drawing along the way. With a basic system in place, you could accept bounties for work that others want done :)

Maybe a wrapper for canvas drawing along the way. With a basic system in place, you could accept bounties for work that others want done :)

I don't need anything more than that to start building useful apps - and having a lightweight option (lighter than Streamlit, with a full install of Python and some RDBMS on a server, for example), is very appealing. I'm sure there's a market for that.

Here is my evening project. It's a very lean pig that can win pig races for you: Meta [ -Title: "Pig Latin example for CGI" -Author: ["Nick Antonaccio" "Kaj de Vos"] -Rights: "Copyright (c) 2020-2022 Kaj de Vos" -License: { --PD/CC0 --http://creativecommons.org/publicdomain/zero/1.0/ -} -Purpose: { --Convert words to Pig Latin through CGI. -} -Notes: { --https://en.wikipedia.org/wiki/Pig_Latin --Ported by Kaj de Vos from the original in REBOL 2 by Nick Antonaccio: --http://rebolforum.com/index.cgi?f=printtopic&permalink=Nick16-Jun-2022/11:12:40-7:00&archiveflag=new -} ] write/line {Content-type: text/plain } text: find/tail select/case system/environment "QUERY_STRING" "=" while ( -if space: find word: text " " [word: copy cut text space] -unless is-empty word [ --write either is-same word vowel: ---any [find word "a" find word "e" find word "i" find word "o" find word "u"] --[-; Word starts with vowel ---write word ---"hay" --][ ---write either vowel [ ----write vowel ----copy cut word vowel ---][ ----word ---] ---"ay" --] -] -space )[ -write " " -text: next space ]

It should be a drop-in replacement for your REBOL version, unless you use post requests. Let me know if Anvil needs a different interface.

It should give you some idea of the state of Meta. It's lower-level than your REBOL version, but I think it's fairly straightforward, and it uses only a tiny fraction of the time and memory that REBOL needs. Over time, more data types and higher-level convenience methods will be added, so it can become more compact and closer to REBOL.

I'm only interested if you can host it on an 8 bit Atari :')

I thought you insisted on Anvil. :-) I have been working on network support for Atari 8-bit. I almost got the compiler client to work, but the testers went silent. A web server would be possible. CGI wouldn't be the most efficient, but the above example wouldn't be hard to adapt to run on it.

I have the same ideas as you about UI. Just standard widgets would cover many use cases. I did those for my GTK+ binding for Red. Which toolkit is very personal. Web is universal, but many people want to do native apps in a specific toolkit. Especially mobile devices have features that web doesn't support. I can't do all those bindings at the same time. I need some web support for the project infrastructure, for the rest I will let it depend on funding.

I compiled the code above using run.com on Windows. It runs on the command line. I get a 500 internal server error when calling it from a pig.cgi in Uniform Server: #!./pig.com BTW, this morning I did get the Pico W blinking morse code returned by the Rebol CGI below (using Anvil to send strings entered by the user to the Rebol script, and then send the returned morse code to the Pico W via Anvil uplink): https://re-bol.com/morse.cgi?x=SOS Now I can use my phone (or any other remote device) to flash Morse code messages on a Pico W which is simply connected to a power supply at my girlfriend's house (the Pico is connected wirelessly to her WIFI). She doesn't know Morse code, but it's romantic to send her sweet messages. Maybe I'll add a Twilio text message to translate for her... It's special for me because Rebol does the Morse code encoding.

:-) Thanks for testing! Did you add a query string? Like ?x=piglet The program isn't robust against missing input. It may print an error message, or crash; I didn't check.

I tried: http://localhost/pig.cgi?x=this%20is%20cool

Any chance you could try a different web server, of different operating system?

It works on Linux: <a href="//do.metaproject.frl/examples/PigLatin?x=pig">do.metaproject.frl/examples/PigLatin?x=pig</a> But I made a mistake in the vowel parsing. I'm working on a fixed version.

It does look like the current Meta version is robust against missing input. It just returns a blank response. (Unlike the REBOL version, which errors.) This came about naturally, because of all the built-in REBOL-style checks for NONE values. (Other languages that have it call them option types.) Meta is not crash proof yet, but it usually already feels like a safe language.

Our first collaboration :) https://metapig.anvil.app although, I'm currently getting "atinpig%20lay" as a response for: http://do.metaproject.frl/examples/PigLatin?x=pig%20latin

Very cool, thanks for that! Please change "Convert with REBOL" to "Convert with Meta". :-) Yes, I found several bugs in my parsing. Working on them. Also, URL encoded %20 is not converted to space yet.

Oops, missed that 'Rebol'. It's changed - and the string returned from Meta is decoded :)

Thanks, but I have to implement that URL decoding, otherwise I can't separate words.

Fixed the vowel parsing.

5 Minute CRUD run-throuh with Anvil: https://www.youtube.com/watch?v=IF9uCnIkTc8

Oops, better version of the video content above: https://www.youtube.com/watch?v=cEtpJVh8UzI

Cool. Implemented URL decoding of %20: <a href="//do.metaproject.frl/examples/PigLatin?x=This%20is%20rad">do.metaproject.frl/examples/PigLatin?x=This%20is%20rad</a>

Here is the new version: <pre> Meta [ -Title: "Pig Latin example for CGI" -Author: ["Nick Antonaccio" "Kaj de Vos"] -Rights: "Copyright (c) 2020-2022 Kaj de Vos" -License: { --PD/CC0 --http://creativecommons.org/publicdomain/zero/1.0/ -} -Purpose: { --Convert (space separated, English) words to Pig Latin through CGI. -} -Notes: { --https://en.wikipedia.org/wiki/Pig_Latin --Ported by Kaj de Vos from the original in REBOL 2 by Nick Antonaccio: --https://rebolforum.com/index.cgi?f=printtopic&permalink=Nick16-Jun-2022/11:12:40-7:00&archiveflag=new -} ] write/line {Content-type: text/plain } text: find/tail select/case system/environment "QUERY_STRING" "=" while all [text not is-tail text] [ -text: if space: find word: text "%20" [ --word: copy cut text space --skip space 3 -] -unless is-empty word [ --vowel: none --character: word --until any [ ---is-tail character ---if find "aeiou" copy cut character 1 [vowel: character] --][ ---advance character --] --write either is-same word vowel [ ; Word starts with vowel ---write word ---"yay" ; way, hay --][ ---write either vowel [ ----write vowel ----copy cut word vowel ---][ ----word ---] ---"ay" --] -] -write " " ] </pre>

It's a good example of several things that still need to be improved in Meta. It's probably similar to REBOl 1 before it got string PARSE. Your REBOl version shows the improvement that PARSE brings.

I tried the CGI in its portable version on Linux. It runs, but doesn't process the input. It could be that the portable Meta programs don't support environment variables. I compiled a version specific for Windows: <a href= "//language.metaproject.frl/programs/test/PigLatin-CGI.exe">language.metaproject.frl/programs/test/PigLatin-CGI.exe</a> Could you please try that on Uniform Server?

500 Internal Server Error: I'm running an old old version of Uniform Server, here's the log: [Tue Jul 26 22:05:12 2022] [error] [client 127.0.0.1] Z:/public_html/metapig.cgi is not executable; ensure interpreted scripts have "#!" first line [Tue Jul 26 22:05:12 2022] [error] [client 127.0.0.1] (9)Bad file descriptor: don't know how to spawn child process: Z:/public_html/metapig.cgi Probably calling your executable incorrectly: #!/usr/bin/PigLatin-CGI.exe No permissions need to be set in windows. This is how I call Rebol in that same folder - the following script works: #!/usr/bin/rebol.exe -cs R E B O L [] print "content-type: text/html^/" print [<HTML><HEAD><TITLE>"Test"</TITLE></HEAD><BODY>] ... When I run PigLatin-CGI.exe at the command line, it works properly: Content-type: text/plain How should I pass the arguments to PigLatin-CGI.exe in the line first line of my metapig.cgi script?: #!/usr/bin/PigLatin-CGI.exe

PigLatin-CGI.exe is not a script interpreter, it's an executable of the compiled program. It executes very differently from a REBOL script. It should be straightforward to run as CGI: it's the simplest case. But every web server sets it up differently, so I don't know how Uniform Server does it. There are no arguments to pass. The argument is in the query environment variable, which is part of the CGI interface standard.

From your description, normally, Z:/public_html/metapig.cgi would have to be PigLatin-CGI.exe not a script.

By default, Apache on Windows just downloads the .exe file. It's been a while since I've messd with configuring Apache...

It just needed to be put in the cgi-bin folder. It works as expected: http://localhost/cgi-bin/PigLatin-CGI.exe?a=this%20is%20cool returns: isthay isyay oolcay

Cool, thanks! Could you also try a .com version that you compiled yourself?

BTW, the program that I compiled previously using run.com (I named the file pig.com) does also run properly in Windows Apache, accessed via CGI: http://localhost/cgi-bin/pig.com?a=this%20is%20cool returns: is%20is%20coolthay (that was the old code, but the executable runs fine)

Great!

Thanks very much for testing! It's good to have gone through the CGI use case, because it's one of the first things that Meta is suitable for (as evidenced by all my project web sites). Concluding, you made me find a problem with Meta's current released portable format. It's based on the Actually Portable Executable format, that modifies itself on first run to adapt to the platform. It turns out that my Caddy web server on Linux can't run this format. I would expect the same problem with other web servers on other Unix systems. Since the .com format is actually a native Windows format, it's apparently not a problem on Windows. So Meta can currently be used for CGI on Windows, but probably only I can use it for CGI on Unix. I need to release the Meta compiler for more specific target platforms to solve that.

Piece by piece, it'll get done ;)

Nik, can anvil.app give data from the table to another program? For example - need to process from people.anvil.app in Rebol, how can I get them? >> a: read http://www.pochinoksergey.ru/sslv3/proxy.php people.anvil.app connecting to: www.pochinoksergey.ru == ... but there is only 100 kilobytes of anvil.app code, without data from the table.

I cover consuming and creating web APIs in my tutorial: https://pythonanvil.com/#section-19 https://pythonanvil.com/#section-20

For example, I added this function to people.anvil.app: @anvil.server.http_endpoint("/somedata/:column") def get_columns(column): return [str(u[column]) for u in app_tables.people.search()] That gives me any column from the 'people' table, like this: https://people.anvil.app/_/api/somedata/name https://people.anvil.app/_/api/somedata/address This function gives returns the whole 'people' table: @anvil.server.http_endpoint("/getdata") def get_db(): return [str(dict(u)) for u in app_tables.people.search()] https://people.anvil.app/_/api/getdata

It really looks very simple! Thanks for the example. P.S. Sorry for the stupid question, I haven't started translating your anvil tutorial yet, but I'll definitely do it!

Not a stupid question. Lemme know if you have questions :)

Graham, I just noticed that someone in the Anvil community wrapped the chessboard.js library: https://jschess.anvil.app/ As a learning exercise, I'd like to implement the saving and replaying of games, as you did.

I published a tutorial for Streamlit: http://streamlitpython.com/

I published a tutorial for Streamlit: http://streamlitpython.com/

I'll a sk the obvious: have you dumped Anvil? :-)

Of course not. Streamlit's just a nice tool for quick in-house apps. It was made to support all the Python visualization and ML libraries natively out of the box, but useful for simple CRUD tasks too.

Anvil is still stupendously productive and all-encompassing in the broad capabilities it provides. I've made quite a few clients happy with it this year, creating solutions for a huge variety of development tasks - I don't think there's anything else quite like it :)

I think it's far more productive than any of the 'low-code' tools that are gaining market share (even in the small domains of work they occupy), but dramatically more capable, as a 'pro-code' tool with the full Python ecosystem backing it (and of course with a super convenient built-in database, UI builder, API endpoints, lots of integrations, etc.)

To give you an idea, since July: I built a payroll and billing system for an accounting firm (with time tracking, PDF generation, lots of varied reporting and admin panels, automated email and text alerts for clients). I built an app to help a vision therapy business collect and calculate patient evaluations (and also a small supply ordering app for them). I built a prototype machine management app for a large IT firm, with an API that's designed to scale reliably to at least 300,000 requests per second. I helped extensively in building a large commercial marketplace web site app for a niche retail industry in Canada (launching early 2023). In integrated a Typesense database with Google maps API, used to find locations based on 'fuzzy' search. I built an authentication system based on IP addresses, to integrate into an existing shift clock app. I built a personal photo sharing app for a private individual, with an all-original custom carousel widget designed from scratch, folder authorization, and other precise feature requirements. Little projects: I built a QR code reader, a Twillio SMS text integration, an API that delivers XML results from database queries, a pub-sub communication system, a Tabulator (complex JS grid) implementation that works equally well on mobile and desktop, a background video web page layout template, a custom tree grid component built from scratch, a Markdown editor, an FTP utility, a Daily.co video conference integration, a Quill wysiwyg HTML editor integration, a UI to control wireless Pico W microcontrollers, and lots of various little CRUD components for clients. I built an in-house tool for organizing recitals and generating jazz chord diagrams for students in highschool jazz band (used at my Rockfactory business), an automated invoicing system which I use for all my clients, and also my personal web site at com-pute.com I'm currently working on integrating a bar code scanning feature into an ordering system used at a hospital. I built the front end to a machine learning project by a data scientist who wanted to publish his model online (using Streamlit).

That's all been in my part time. I still operate and teach at Rockfactory 3 1/2 days a week, and spent a lot of this year running and teaching at my paramotor school (I'm the East Coast dealer for the largest paramotor manufacturer in the US). Anvil is productive.

It's not just productive - I *enjoy* working with it more than any other tool I've used - it's simple, quick, and genuinely painless to accomplish the majority of common development tasks that I like to take part in. It's been a life changer for me, I'm happy to take on projects again :)

That's certainly impressive. What I always wonder about with such projects, is how they are supported. Do you update them over time? If not, do they not suffer bit rot over time? If yes, do you not feel it's a burden to have to support multiple application platforms? For me, I have always wanted to support projects long-term, but the maintenance always became a problem over time, to the point of turning into nightmares. One of my strongest goals is to prevent that.

The lifecycle of every application is different, but almost all of them change and evolve to varying degrees. One of the things I loved about Rebol was that it was so small and instantly installable, that I could go to any client's location, set up a development machine in a minute, work with them interactively in person, live coding to prototype and create actual working code with a fantastically agile workflow. I could make changes to code files by email, by sharing remote desktops, etc. Anvil is even more effective in that regard. First of all, to get worm done, I can be anywhere, on any device (even iPads work great, for example), and because every piece of a project is hosted - even the IDE - I can get work done everywhere I move constantly between machines and just pick up right where I left off, with the exact same environment, without any setup or installation. I can be at my girlfriend's, working while she's on the phone, or waiting for an appointment at the doctor's office, etc. I've never experienced convenient and quick/productive workflows in my spare time, like that. And delivering changes is as easy as telling a client to refresh their browser, wherever they are, on their phone, desktop, etc. And Anvil has a full versioning system (backed by GIT), which allows you to constantly save a current version, revert to it at any point, and set any version as production, so you can work on and run development versions without interrupting the production version, roll back changes to production version at any moment, copy paste between verions, etc. And at any moment, the user just resfreshes their remote browser for a full update. Delivering constant little changes to software is now instant, fun and satisfying - and I just log any hours into my little Anvil based invoice system, wherever I am, so a get paid for every minute of work :) If I ever need help with building projects, I could hire a designer, even someone without any coding background or much experience laying out interfaces, and train them in a day to complete simple time consuming layout tasks. I thought I wouldn't like using a GUI builder. and spent a lot of the getting better at building interfaces with code in Anvil, but the overwhelming majority of layout tasks just take a few minutes with drag and drop, and making significant changes is always easy.

I understand, I have part of that workflow down already with the Meta web console. But what I mean is what happens when Anvil, Streamlit and the other environments you have used to build apps release updates. Some of them are bound to break your (old) apps. And when they stop being supported and stop releasing updates, your apps may break when the world changes. Such as R2 not supporting SSL.

You can self-host any Anvil app using the free Anvil server, if you want to freeze it in its exact state (or if Anvil hosting ever goes out of business). I download a copy of the server software occasionally so that I have snapshots of it at various stages. When it comes to technology moving on, and needing to connect with new paradigms, that's just part of any software development process. The thing with Anvil is that it's all pure Python, with a Python-JavaScript bridge. The server particularly provides access to the full Python ecosystem. The 2 most common types of SDKs and documentation examples that are provided with every new technology are typically Python and JavaScript. And the combined user base of Python and JavaScript together FAR outsizes any other group of developers on the planet. So it's hard to imagine a tool more prepared to move forward into for the foreseeable future. And when we're past the foreseeable future, I expect there will be something better than Anvil and everything else we're imagining at the moment...

One of the things to keep in mind is that something like the core Anvil API is made to stay consistent, despite changes to the underlying layers of architecture. I've been able to use Anvil on more machines, in more versions of browsers than any other modern framework I've found. I've been really happy to see Anvil apps run on even the inexpensive mobile devices I have that are a decade old, and on low powered single core 32 bit netbooks running Windows 7 from 2009, with Palemoon browser (Chrome doesn't even run nicely any more on those old machines). And the thing is, I can buy a pile of new Android phones for $29 each at Walmart, and run an Anvil app on them immediately, without having to install anything. If some client isn't happy with those flexible possibilities, I'm not interested in working with them.

I'm happy to pass off the hard work of maintaining APIs and coordinating all the other pieces of infrastructure to a company whose only job it is to do that. They seem to have done a great job for the past few years, and based on the best practices I've seen them implement, I trust them to do a better job than almost any other project I'm aware of. Again, if you need the guarantees of full control, just self host.

I'm playing with a ton of Python, but also some JS frameworks. I really like Quasar (a VUE component framework) + Google Firebase/Firestore + FastAPI. I'll most likely end up using that combination in the future for projects which require heavy scaling, and actual Android and iPhone front end apps (app store type apps). NiceGUI is another Python framework, actually built on an old version of Quasar. I'm even playing with some no-code tools like Appgyver and Appsmith for quick solutions to particular limited problem domains. There lots of fun free toys available to waste my time :)

BTW, for Streamlit (or any Python libray), you can pip install any version, and pip even lets you create separate environments on a system, all with different versions of any library(s) you want, so that you don't have any library version conflicts on a machine - environments are basically folders containing a full install of Python and all the libraries you want to use, with the particular versions of every library you need for the project. Most Python developers create a new environment for all but the simplest projects. A requirements.txt file can be used by pip to install a complete list of all the libraries needed (in the correct versions) for project. When deploying apps on remote servers, you can bundle the entire system setup, including python version, libraries, network settings, etc., using Docker containers, so that the exact environment needed is reproduced on the remote system - that avoids any bit rot or broken apps, and makes it really quick and easy to install on cloud computing platforms. Python makes every part of that process very easy to control and manage (pip is built in to the standard Python distribution on every OS). The Python ecosystem is pretty great :)

https://thomas-berweger.medium.com/ermittlung-der-%C3%A4hnlichsten-fussballspieler-mit-dem-knn-algorithmus-in-python-e9b04fc4a70e I wrote the Streamlit code used to publish the model in that article (running at https://fifa-similar-players.streamlit.app/ )

I dealt extensively with dependencies in the Syllable operating system. While it can be a good idea to include dependencies with your app to isolate them from the system, it causes another problem in that they are not updated anymore, so you don't get fixes, including for security and changing circumstances in the outside world. They may even stop working with newer versions of the host system. These two sides that both cause their own problems must be carefully balanced. Going to the extreme on either side is not a solution. The only way to really reduce the problem is to reduce complexity.

In any Python environment, updates can be made to any library in that environment at any time. With Rebol we had a particular problem with our tools not being kept up with the rest of the world, because the pool of developers was so small. That's not at all the case with Python. There are millions of developers and users all ironing out problems and helping keep all the pieces up to date and working properly in different environments. That rich and lively ecosystem, along with the fundamental pieces, PEP, and ethos are Python's way of beating complexity - and in my experience, it's working fantastically. I do think Rebol is a better fundamental design, and the ethos of reducing complexity was approached in the best way I've come across, but without support and an extremely large and productive ecosystem, Python solutions currently provide the best simple, productive solutions, without the sorts or troubles you're expressing concern about, which I have been able to find. Together with the mess of JS - used only where absolutely needed (extremely rarely in the tools I'm using), there's the possibility to accomplish the broadest range of tasks with the least work. You're working on building better tools, I'm working with the best tools I can currently use. I sincerely hope you're succesful!

I understand what you're saying, and we'll have to leave it at that for now, because Meta is a lot of work. On the other hand, I have no reason to believe that Python is immune to dependency problems. JavaScript has the same enormous support, and it can't be that it's a mess in a limited, controlled environment, while Python is problemless on general platforms. My experience is with systems and libraries in general languages, but mainly C and C++. They also have the same enormous support. Yet, REBOL is much more problem-free, except for a small number of well known problems, that nevertheless ruin the experience because support went to zero. Fixing REBOL's problems is doable, while fixing huge ecosystems is practically impossible.

The way things are moving these days, with web APIs forming the backbone of so much processing work, database storage, Etc., it's not anywhere near as hard as it used to be to keep dependency issues from causing problems. Even on a single machine, you can have a bunch of separate little app pieces all running entirely in their own environments, each of which could potentialy have tremendous problems working together, if they were in the same environment, but now they all work in their own little worlds and communicate with each other and the rest of the world via REST API. And it becomes even less of a situation when you deploy any of those little pieces of app and API onto separate dockerized containers running, for example on some cloud host. They're all entirely separate environments, with OS, language versions, database systems, and all the library dependencies running in their own little universes. Any piece that doesn't play well with any other piece can just be separated entirely into an entirely different containerized little universe.

Low level system development, and game development, are very different markets, and use very different processes - game development is mostly tied to using Unity, Unreal, Godot, and all the other game engines. I think the world has lost the sense of ever having a single tool set to do lots of different categories of work.

No one is going to use Anvil to build a console game, or to develop a new os, or browser. And no one is going to use C to build a web app.

Ah, yes and no. Indeed, Anvil and such are limited to business and web apps. Meta covers the whole range of programming domains, so there is really no comparison. And if those web apps can only work by exploding their complexity into many large containers, while Meta covers its whole range with a small, unified system, that's a very good sign to me. They're not very different to me, that's a myth. <a href="//www.infoworld.com/article/3639050/complexity-is-killing-software-developers.html">www.infoworld.com/article/3639050/complexity-is-killing-software-developers.html</a> <a href="//qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/">qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/</a> Yet, I am using C to build web apps. I write them in Meta, Meta compiles them to C, and the enormous support ecosystems of web and C compile them to JavaScript for me. I have been a proponent of service-based design for a long time. It shouldn't be done to avoid solving the problem of dependencies, but it is a solution to making subsystems in different languages communicate, and to migrating old systems to new ones piece by piece. Like how we made Meta and Anvil communicate here above.

I was lobbying to get Rebol ported to mobile platforms and the browser more than a decade and a half ago. No one seemed to care. I watched the core language get ported to WASM, but with absolutely no thought about attaching it to a UI, or being able to connect to a server to save and data in a centralized location, so those projects never saw much daylight. With even a simple GUI in the browser and a way to connect to a server platform to persist and use data, plus just a bit of basic hardware control, all using the same language, the possibility exists for practical use. I'd love to see a small Meta tool kit like that take root - because then more and more users would begin to grow the system, and there is the possibility for life. I built hangman and my guitar diagram maker with Anvil, as part of the first explorations with it, but that's not even in the same ballpark as creating massive multiplayer virtual reality games, which are relatively painless to create with modern game engines. Like everything else, if there is enough support, tools can potentially grow in every direction. This guy is creating awesome business apps with Godot: https://github.com/alfredbaudisch/Godello And here's an interesting article about why that's a great thing: https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b That's happening with Unity too. All because there are many users, and the fundamental building blocks are there to be used in useful ways. I think once any language is running in the browser, with a useable UI, and some connection to a server running the same language and data structures, with access to a file system/database and hardware, then the building blocks are available for a community to start doing useful work with a toolkit. That seems to be a worthwhile goal... I'll be right there trumpeting the value of such a system, with Rebol-like language and ethos!

I'm having a strong reaction to this topic, because it's important to me. I fell in love with Rebol 20 years ago because it made complicated tasks easy to accomplish. That was the case not just because Rebol had a great language design, but even more importantly because it included a massive variety of built-in capabilities which were engineered specifically to address a broad scope of problem domains, and it provided a beautifully integrated language interface to deal with common task in each of those domains, all in a tiny package that ran exactly the same on more OSs, better than any other software development available at the time. First of all, that cross-platform landscape was very different back then, with lots of new OS contenders that appeared to be gaining market share. There were certainly some awesome language concepts that worked beautifully in ways that were never really fully explored - dialects were probably more important. In my experience, it was the really deeply thought-out set of well-engineered and all-encompassing built in tools, along with the way the language unified all those tools, which helped to make Rebol so productive. It wasn't just the language - and I think so many developers in the Rebol community missed that. They seemed only interested in the pure language - but without all the tooling that came with Rebol, it would have been just another academic curiousity. It was it's ability to handle graphics, sound, networking, all the built-in network protocols, file management, etc. all with the same series functions, that made it so useful. Just the idea of having series functions manipulate all the data is a great design idea, but without all the actually well implemented, well integrated realizations of all the deeply engineered useful pieces of technology that came in that tiny package, Rebol would have been useless for any practical purpose. Without the ability to run it on any platforms, the language ideas would have just been ideas. Rebol was a success just as much in how it actually provided so much tooling in a fantastically small package. I don't think is was as important that Rebol was small, and that certainly doesn't matter as much now. What mattered was that it was capable at handling so many different problem domains. You seem to have a drive to accomplish the same goal. I hope that the idea of simplicity doesn't get prioritzed in that end, to the point that the more important goal of capability doesn't get lost. A simple tool that can't accomplish and goal is useless. A powerful tool that tool difficult to use productively is also useless (the case with many other tools, especially in the past). In recent years, the quality and productivity of development tools has improved dramatically. My realizations with Anvil and Python, in regards to those improvements, have been particularly powerful. Anvil's built-in tooling a broad range of capability dramatically outweighs anything Rebol was ever capable of - in PRACTICAL TERMS. The facility with which you can accomplish SO MUCH of the typical software development problems - in this MORE COMPLICATED modern environment, demonstrates just how much deep engineering has gone into succesfully providing consistently useful tools that enable working software to be created more productively. Standing far enough away from any language, framework, tool, etc., without actually using it, it's easy to make simplified assumptions and generalizations, but without actually using those tools, it's not possible to gain a feel for all the benefits that come from the many many designs decisions that pay productivity dividends to the developer. The truth is, Anvil's creators have pulled off a phenomenal practical accomplishment. They've worked on easing the pain points that every developer encounters when working with an overwhelming majority of common problems. Over and over, in thousands of moments, I've just continuously said to myself, holy shit that was easy. Much easier than any experience I ever had with Rebol - and the fact is, I'm aware that each of those realizations is accompanied by an understanding that each of those truly well designed solutions I've discovered runs really deep, so that a much broader set of problems in each category I encounter can be handled with just as much simple work. Yes, the environment that Anvil works in is very complex, and that sucks, but that environment is not going away any time soon. The point is not just to have a simple tool, the point is to have a tool that is simplifies handling the broadest set of problems in a complicated environment that must be tamed. That takes not just and ethos, but lots and lots and lots of actual engineered and well integrated solutions to lots and lots and lots of specific problems that aren't going away. Anvil has done an absolutely fantastic job of harnessing the Python language and ecosystem to beat those problems, providing real worked out, industrial quality solutions and tooling to areas of the ecosystem where there were non in Python, and integrating them into a tool that encompasses more of the modern development landscape than any other I've even seen, and I've spend more than 3 decades learning, exploring, and using every imaginable tool, no matter where it sat in or outside the mainstream spectrum. Being able to integrate and leverage existing tools, languages, and ecosystems is so important in the modern landscape. That's what Rebol did so well. It connected so much of the existing core componentry of the ecosystem, in ways that were beautifully and productively composable. Anvil does the same with the modern landscape of technical building blocks. I still think that a Rebol based language has the potential to tame that sort of integration even better, but only if that's the goal. I'd like to write more, but it's 3am...

I'm sorry, that was very messily written and totally unedited, but I hope at least the general idea comes across - prioritizing capability and integrating existing complicated building blocks in ways which dramatically cut down how complicated those building blocks are to use and and produce working solutions with, I think sould be the only end goal. That's what tools like Unity, Godot, and <name any other productive tool> do. And so much of what makes any tool useful is the degree to which the most important goals are made easier to achieve. The greater the number of useful goals that can be achieved and integrated, with the greatest productivity, the more valuable and useful that tool with be. The ethos of Rebol was brilliant. The number of engineered solution that were shipped in that tiny package was mind blowing. The integration of all those solutions, and the composability of the pieces was better thought out, and laying a foundation for the lessons learned by what Carl created do provide a basis for more powerful, more simply designed solutions in the future, and I absolutely support trying to achieve that goal.

I just need to be able to get work done, and I've been around the block a few hundred times. Anvil is pretty damn amazing at satisfying the needs of a productivity craving madman who builds working software solutions for clients in hours/days rather than weeks/months. I'd love to see a better designed system, and I'd love to see a system that beats complexity, from its core design principles on up, and I think what Carl proved is that Rebol can actually do that, but only if it starts where Rebol left of in terms of integrating lots and lots of well engineered, natively integrated tools that can connect with, tame, and make all the existing tools in the mainstream computing environment more productively composable.

'No Code' and 'Low Code' buzz is tremendous right now because there's an outrageous demand for the solutions they provide. I can talk to almost any small gathering of people and find business clients who have real needs that could be satisfied by solutions created by those sorts of tools. Most of those tools are simply front end builders with perhaps a database system and a way to connect to rest APIs to process, store, and manipulate data in useful ways - basically CRUD building systems. The market for APIs that perform valuable data processing capabilities not just for the no-code, low-code community, but for every other language tool that connects to them is growing like crazy. Microsoft is building its Power platform with the intent of fully integrating 'no-code, low-code, and pro-code'. Backend solutions like Firebase, Xano, Deta, and a thousands of others are finding hungry markets. I personally think Firebase and Firestore are going to grow dramatically, because that platform satisfies the real needs of projects that need to scale. No-code and low-code tools are all really limited, but they enable real productivity for a narrow portion of the software development market, and that helps to produce growth, plus the existence of new useful APIs and backend systems which can be easily integrated everywhere else in the market makes other development tools of every kind, no matter the language or platform, all more productive. That growth and standardization represents a true simplification of the entire system, in ways that are palpable and actually effective for a bigger portion of the market. Meta can take part in that growth immediately. Take the tact of all those successful no/low code tools that are getting many millions of dollars in funding, and build a tiny tool set that can accomplish all the same goals and more, and you've got a potential goldmine. Make it easy to connect to REST APIs, provide a simple to use UI builder, provide access to file system, database, email, PDF printing, etc., and make it tiny and self-hostable, and you'd fill a niche in an absolutely huge growing market which is also attracting lots of investment capital. Producing that sort of tool set (one that could compete with the no-code tools in simplicity) is also a potentially achievable goal, and one that could attract an enormous user base. I'd be genuinely excited to see Meta go in that direction.

:-) All agreed. We went through the same REBOL valley of tears. I don't see anything in Meta's goals that contradicts yours: <a href="//language.metaproject.frl#goals">language.metaproject.frl#goals</a> On the other hand, it's still early days. I can't advertise that I aim to replace Anvil and everything, because we're still focusing on the base language, and people already can't believe what has been accomplished so far. REBOL is a navel-gazing silo, albeit a tiny one, except for network protocols. It was meant as an Amiga OS successor and was designed that way. REBOL has very little interest in integrating with other operating systems locally. It's a jealous language: it keeps its inventions to itself, literally afraid that MS would steal them. But as Mark Twain said, if you have something really innovative and good, you shouldn't fear it gets stolen, because you will have to push it through people's throats. That's exactly how it feels promoting Meta now. :-) Everybody was expecting Amiga OS 2.0, even more superior consumer multimedia, but what we got was iOS: a sort of operating system for the Internet, for business apps. That was very interesting to me, because I was into Lotus Notes, simultaneously doing things that no other technology could do at that time, and running into its limitations. I saw that REBOL fixed those limitations by carefully designing systems like operating systems, including a pervasive language. It's fine to build business apps or multimedia or whatever on top, but to make that work, a carefully designed system needs to come first. So that's the phase Meta is in, but we also need to fix REBOL's problems, that manifested later. Meta is taking down the ivory tower. It is designed to integrate really well with local systems, libraries and operating systems, and improves them by extending its innovations to them. In Meta, series work not only as its internal data types, but also as abstractions over the data types of those external subsystems. Instead of resisting other systems, Meta embraces them, and uses their power for its own purposes. Using libraries from Meta will be better than using them from other languages. REBOL only does that for network protocols. That was great while it lasted, but resisting local integration eventually made REBOL fall behind. Also, REBOL is implemented as an interpreter. Anything wrong in it is always there. Meta is designed for compilation. It is very incomplete now, but compiled programs are of production quality, unless you need garbage collection in long-running programs. Meta being incomplete is of no concern to me as long as it has the features to compile my programs. To make it of no concern to others, I can implement the features they need. Obviously, I can't implement all the features you speak of of all other systems out there. I won't live long enough, and it would mostly be chasing tail lights. Therefore, Meta's strategy is to use other systems' strengths for our own purposes. This can be using them over the network, or using them locally with tight integration. Just what other parts of the modern ecosystem do, only better. Older systems get replaced by better ones by being eaten up from the bottom when they have become too fat and slow. Interfacing all those systems is still too much work. I have to be very selective about them. My own needs are an obvious criterium. To do substantial work for others' needs, I will need funding to keep going. This needs to be fixed, as well, because it was another reason for REBOL's demise, hence why I am running the project differently. Eventually, opening up Meta's architecture should allow everyone to contribute their own needs, and create an ecosystem similar to Anvil and such. Here we run into the limitations of using other projects: because Meta makes extensive use of existing subsystems, it's hard to open source in a managed, meaningful way. This will take time.

Sorry, Mark Twain could have said that, but it was Howard Aiken.

I'm really curious how you're planning on positioning Meta for a particular market. It strikes me that you could have a unique product in the 'low code' arena. It's so much smaller and more agile, and something maybe you could market as a 'low code system for *developers' - something uniquely lightweight that provides solutions to the same sort of problems that low code tools do, but with even greater productivity, and made for developers who don't want anything to do with drag and drop builders. I have this sense that at the moment, just tacking on the words 'low code' could find you a market. And what the majority of successful low code tools do is very simple. Most are just front end UI builders that connect to Rest apis to provide services and data storage. Tools like Appsmith are getting tens of millions of dollars in funding. I have to imagine you could get a good team together to really build up Meta if you could find that sort of funding. I think the idea of a low code tool could potentially be sold to something like a significant portion of the IT community, where professionals might feel silly using the same drag and drop builders that totally untrained 'citizen developers' use - and they're a group of people who have some minimal coding skills already, and are likely to hear requests for lots of little in-house apps to be built. Positioning Meta as the 'low code tool for IT professionals' could be a way to find investors to help you build it.

And of course, I'm not suggesting that that's all Meta should be - just a way to position it in the minds of investors, to get funding, and to find some initial market share. I think the key thing that strikes me is that building a minimal tool that can compete with something like Appsmith, could be a manageably-sized project to complete within a relatively short amount of time, especially if you could find the funding to hire a team. That would give you a starting point to build it up into a real language product that has so much more capability than anything else on the market, in that space.

I have certainly been thinking about low-code tools for a long time. Successors to Lotus Notes, more or less. There are some hurdles. If you show too much code, people won't understand the REBOL way. It can't be thrown into the market, REBOL knowledge must be learned slowly over time by gradually more people. A tool with little code is more work to make useful, and the code fragments would probably need future dynamic features of Meta that are also more work to support. I'm reluctant to take on investors. This pretty much destroyed the step from REBOL 2 to REBOL 3, and many other startup projects. With Syllable, we tried but didn't even get that far. We're in a similar situation now, where the world economy is tanking, so it's not a good idea now, and there are new ways to get funding. That's why I'm keeping options open now. Meta can be developed to be suitable for almost anything, so I'll see what opportunities come along. As with the rest of the project, it should be done in small steps. Big steps carry way too much risk of failure.

I'm currently absolutely dazzled by Flutter together with Firebase/Firestore. Anvil is more productive, but I think it's hard to produce applications with cross platform front ends that are more performant, modern, and broadly capable than with Flutter (there's even a slick 2D game engine built on it (Flame)). Firestore/Firebase provides backend database and tooling that can scale instantly to any load, with features like live data syncing, and standard Google Cloud pricing. This stack is wickedly powerful in every way, and truly hard to beat in terms of professional application results, and it's very widely used. The low-code no-code SAAS called Flutterflow currently seems to be riding a wave of popularity in that environment too (it exports clean Flutter code). Anvil is currently my go-to for getting work done, but I'm going to devote lots of time in the coming months to Flutter/Firebase.

I've been looking into Flutter bindings for a cross-platform GUI, sort of as a successor to REBOL/View. It's dubious, because they integrated Dart for all the things that I could do better with Meta, so you would have to drag Dart along and have redundancy in your solution. It's an option, though.

A Meta dialect that generates Dart/Flutter code? I'd be *very excited* by that - and the potential market would be huge (literally a 'low-code developer's solution' for Flutter). And Flutter developers have already chosen to learn a new language to get best-of-breed results ;)

It would probably be direct bindings to Flutter and perhaps indeed some generation of Dart. That's annoying, because an extra code generator would be needed. Meta would be competing with Dart. Hard to predict how that would be received. As a little market research, what would you like most: a dedicated web binding or Flutter bindings?

Well, you get web target with Flutter, and I think their whole design is probably better and easier to work with than the whole HTML/CSS/JS mess, but everyone is already use to dealing with code generators and frameworks in the web arena. I don't know if you can improve on Flutter tools, but you can definitely improve upon the options available for web - and the it's probably a better target for a lightweight system initially.

Flutter is definitely to big a requirement for your users to install. One consideration you may want to take a look at is supporting old browsers, and maybe older systems, for the server side. I haven't looked lately at which, if any, old browsers still have some market share, but support for them is hard to come by in newer frameworks and development tools. I can still use JSlinb to target even the very first iPhone browser, version 1 of Firefox, some ridiculously old version of Internet Explorer, etc., along with any recent browser. I haven't had to do that in a long time, but it's nice to know I have a tool kit to support UI on just about any legacy system. Hardware is very very cheap now, but there are reasons that institutions stick with legacy systems, and it's at least food for thought that you could perhaps find an initial market by supporting legacy systems - there may not be as much competition in that arena...

Lightweight is what I'm worried about with Flutter. Browsers are not lightweight, and Flutter is not lightweight, particularly because you can't seem to use it without Dart. Shoehorning Flutter into browsers doubles the problem there. No doubt the industry is used to these constructs and their costs, but that is what Meta seeks to rectify. Even Google recognises this, because there is a separate project Material Design Components for the Web, which provides the MD look and feel, but lighter weight. It's not just a burden for the industry, but also for me. An extra code generator for Dart would be a lot of extra work. One of the problems with all these "easy" components is that if you use too many of them, you take on a dependency burden that becomes impossible to maintain. Choices need to be made.

In the early Syllable and Red times, I minimised requirements on browsers, for example on my Try REBOL site, to be able to run in Syllable's browser without having to update it all the time. Browsers weren't capable of much, anyway. To run Meta in the browser itself, I had to let go of that principle. To make it any use, one wants to be able to use all features browsers have. And it took a long time, but they're more capable now. To make my new web apps, the Meta web console and the chat forum, any good, I had to use newer browser features that Syllable's old WebKit browser doesn't have. Also, the current Meta web backend uses Emscripten, so I depend on what they support. On the other hand, I make the web console generate JavaScript, not WebAssembly yet. I'm not sure where the cut-off for my browser support currently is. Probably around a decade ago.

Minimum requirement for the server side will be Atari 8-bit with FujiNet.

The problem is that, to be useful for anyone, for any practical purpose, you need to support existing user platforms, while the whole point of what you're trying to accomplish is forge a path away from reliance on those platforms. What makes sense to me, and where Meta can be useful, to acquire mindshare and community, is to provide the simplest possible wrapper for the most commonly used UI and data transfer platform, the web and HTTP - using the lightest possible tools and requirements to provide a uniquely productive and agile full stack solution that can satisfy the most common requirements needed to build business apps. My 2 cents is that that should consist of a simple UI that runs in the majority of browsers, a mechanism that can connect to the same language and data structures/database on a server, a mechanism for connecting with HTTP APIs (sending/receiving json, because that's the way structured data is transferred in most online environments now, like it or not), and a way to connect with C and other libraries on the server. That's a full stack, and when a Meta language interface exists to each of those layers of the stack, Meta can be used for a million and one useful purposes, and it can connect with the rest of the modern tech world in standard ways. Build that, and your community will grow, an Meta can begin to change the minds of its users about more fundamental values in computing.

Clearly, those basic requirements should have nothing to do with Flutter, and probably should leave behind old browsers. Those other paths are things that are close to my thinking right now, but if you want to have a real impact, and really build a communinty, then focus on building the simplest possible full stack solution for a web UI builder, with support for consumption of HTTP API endpoint (with json data parser) in the browser, publication of HTTP API ('REST') endpoints on the server, and a way to connect with database and some body of useful libraries on the server.

I think you'll find support if you can accomplish building that stack in the lightest way possible. Again, what makes sense to me, and where the whole world will find value in tools you create, is if the system can create browser based UIs, consume REST APIs, Create REST API endpoints on the server, connect with a database (and file system) on the server, and connect with any useful body of libraries on the server (in any language initailly) so that the server REST API can produce some output of value, such as PDF files, edited images, AI results, etc. I don't think the UI has to be that complex initially - most of it just HTML forms, and you can use any connection available to any database system to start out. Build a json parser, and be able to move values back and forth from the database. Even with just that much of a stack, the system is extraordinarily useful.

Make a wrapper for something like ag-grid or tabulator and you've got a powerhouse of a business software development toolkit. And with that, you'd attract community that would build out the system and support all the other directions Meta has value to offer.

Without that basic stack, I don't see how you'd be targeting anything except maybe the embedded market?

What Meta has to offer is light weight, and that's appealing to many working developers, I'm %200 sure. But what's necessary as a minimum is REST API connectivity (that's how thing work now), and connectivity with a database. Even the server side language and library connectivity is not as important, as long as users can connect with web APIs (REST, HTTP endpoints, or whatever else you want to call them). The world is running on REST APIs. Without that, I think any new stack is doomed. Why not even use Rebol to build that part of the stack? No one cares any more what language a web API is built with - that's actually the whole point - web APIs and json provide the common function interface and data structure of all modern web apps. Using any existing method to persist data with Rebol - it could be a very simple database system written in Rebol, or it could even rely on the old MySQL driver. As long as you can persist and exchange data using HTTP endpoint functions, that's all anyone cares about. Then all you're really doing is trying to build a UI with a nice wrapper on HTML and maybe something like ag-grid.

Following that train of thought, why not build as much as possible on existing Rebol solutions on the server side. Doing that, so much of your work is already done, and you can come up with a very clear plan regarding what to implement on the server in Meta, piece by piece.

Start with just the simplest of UI widget toolkits, just a wrapper for HTML forms, connect to existing APIs, and go from there - demonstrate the ability to make a form layout in the browser, send and receive some data to/from a web API, and process some returned values with your existing Meta web toolkit, and you've got something that will turn heads.

I think everyone is really starting to get used to stacks such as Firebase/firestore + <any web layout system>. And even less than that - just any web UI + APIs. There are some many database as API and services as API, that's what everyone is composing with now. That's a full stack, and enough for the growing army of low-code no-code users to be able to create actually useful applications now. Begin with that wrapping that functionality in a Meta toolkit that simplifies just those parts, and you'll find a market. Start adding the ability to build web APIs on the back end with Meta, and you'll really attract attention. Everything that you want to do beyond that will only set Meta apart even more from other solutions.

Oops, that was supposed to say: Firebase/firestore + some web UI

I'm writing because I'm sure we have a different opinion about what's important in 'software development'. I have to imagine you're thinking much more about low level system development. I'm thinking about all the CRUD work that solves daily data management problems for businesses. Productivity enhancing data management tools that improve some piece of operations in scheduling, communications, point of sale, customer engagement, inventory, accounting, billing, payroll, quality assurance, project management, property management, etc. You know those sorts of solutions don't require complex computing tools, mostly just CRUD operations. I'm having a blast doing it in Anvil because there's no part of building any piece of those sort of software solutions that can't be easily accomplished with Python, JS, a good UI, and a database. Having things like Google and Stripe integration, authentication and user management, PDF generation, camera integration, and anything that can be accomplished with any Python library, all built-in, makes every request I get a total breeze. But those extra things can all be easily accomplished with third party web APIs too - including the database storage part. You can send SMS, do videoconferencing, etc., just by plugging in a few lines of JS and/or setting up a web API. From my point of view, that's where most work in software development that I see still is - and the need for that sort of work is growing even stronger, from my vantage point. There are so many other interesting things happening - in the Python world it's all centered around machine learning, AI, and all the other 'data science' tooling, and it's great to have those tools available to integrate easily, but that's more the domain of 'data scientists'. 'Developers' are still paying for their houses and their children's college experiences by building plain old in-house CRUD data management apps. When I write about this things, I'm speaking from that point of view, with that sort of work surrounding me.

Ah, so we agree that Flutter and other heavy-but-popular stuff are just nice-to-have-if-we-get-to-them. The fundamental strategy is to make the lightest interfaces to the most fundamental-and-unavoidable platforms. To build on C and web browsers is already a big compromise for the sake of popularity compared to REBOL/View. The whole Meta project is already built that way. The console and the chat forum are web apps that communicate with Meta services on servers. Where Meta is not capable enough yet, the browser side is done in simple HTML and JavaScript, and the server side is done in REBOL. Meta is being developed to eat that up over time to do full Meta systems.

Add a little 'dialect' for web page UI generation (something like VID that just generates simple HTML forms at first). Add some basic layout features to make interfaces responsive - basically using a simple flexgrid-like layout to move from horizontal to vertical alignment on smaller screens, and moving sidebar menu drawers into 'hamburger' menu icons. Integrate that with another little dialect to persist data on the back end (something like a Python 'database ORM' that could be eventually migrated to different database systems). Add a mechanism for connecting to HTTP endpoint functions, transferring data structures with json (and converting back and forth to Meta language structures (series)) - or even skip that part and just enable developers to work with json everywhere, because most users these days are familiar with json, and all web APIs work with it by default. That's a full stack that I'd want to start working with. I think others would want to too, if the stack was light weight, with a beautifully *simple* set of UI and database dialects. Package the whole thing in a docker container, and you'd have developers everywhere giving it a try. Eventually add a mechanism for publishing functions via HTTP endpoints, to really make it fit into the architecture that other developers are used to using.

Add a little 'dialect' for web page UI generation (something like VID that just generates simple HTML forms at first). Add some basic layout features to make interfaces responsive - basically using a simple flexgrid-like layout to move from horizontal to vertical alignment on smaller screens, and moving sidebar menu drawers into 'hamburger' menu icons. Integrate that with another little dialect to persist data on the back end (something like a Python 'database ORM' that could be eventually migrated to different database systems). Add a mechanism for connecting to HTTP endpoint functions, transferring data structures with json (and converting back and forth to Meta language structures (series)) - or even skip that part and just enable developers to work with json everywhere, because most users these days are familiar with json, and all web APIs work with it by default. That's a full stack that I'd want to start working with. I think others would want to too, if the stack was light weight, with a beautifully *simple* set of UI and database dialects. Package the whole thing in a docker container, and you'd have developers everywhere giving it a try. Eventually add a mechanism for publishing functions via HTTP endpoints, to really make it fit into the architecture that other developers are used to using.

If you expose any of the features available in Rebol/View, you'd have a really appealing feature set built into the system. Things like draw dialect, image manipulation, audio generation, are all appealing, if they just have a web front end, and a web API. Also, just wrapping modern browser APIs, such as video recording is so easy to do, and adds dramatically to the appeal of the system. Add camera, audio recording, third party libraries for 3D, etc. and just wrap the API in a simpler dialect, and the whole system becomes much more useful, and appears much more powerful. Have you seen https://nicegui.io/ ? They built that whole system by wrapping everything in justpy, which wrapped everything in and old version of Quasar UI on the front end (which is build on Vue, etc...), and also included an old version of ag-grid, plus an interface to three.js to display 3D scenes, as well as Highcharts and Matplotlib. Pretty awesome little system. And Streamlit got bought out for $800 million this year, mostly becaus they wrapped a bunch of Python visualization libraries, and integrated the front and backend so that data scientists could create front end layouts with backend Python code in simple little scripts, wrapping HTML/CSS/JS in the simplest possible API, and hiding how data is transferred back and forth between server and front end (nicegui works in much the same way).

But Streamlit is purpose-built to deliver machine learning, visualizations (dashboards), and other Python data science-y projects to the web. It's not focused on CRUD development, and even with a simple pip install setup, it still much heavier and slow moving in terms of how responsive it could be for normal CRUD development. Anvil is massive. The hosted version is great, but for building strictly in-house CRUD apps, it's a huge thing to install (and only the server is open source, so you don't get the UI designer, IDE, and other the things that make the hosted version so productive to develop with). Flutter is installed locally, but it requires Windows 10, and it's several gigabytes. And that's just a front-end tool. It needs Firebase, or some API driven back end, etc. I'm extremely happy with my current tools, but I'd LOVE to have a light weight, quickly installable, super productive dialect driven tool setup that had no huge external dependencies (basically a web front end to Rebol, with a database, json, and APIs). Getting away from Rebol is of course essential to make the front end part more capable, but that can be accomplished a first by wrapping HTML/CSS/JS in Meta dialects.

What would have solved everything for me would been porting VID, along with the Rebol language to the browser, and creating a standardized method to send Rebol data structures back and forth with a server. The language part was ported with WASM, but the most important part, the GUI, was never approached. Having Rebol/view, VID, draw dialect, sound, etc. ported to WASM would have been absolutely killer - can you imagine? There was a time I would have spent 10s of thousands of dollars to get that done, but no one cared or even seemed to understand why that would have been valuable. I'm fully past that, but I'd still love to see the simple Meta CRUD system I've described. I think that would be useful to so many developers, becuase little in-house CRUD apps are still a huge market.

What would have solved everything for me would been porting VID, along with the Rebol language to the browser, and creating a standardized method to send Rebol data structures back and forth with a server. The language part was ported with WASM, but the most important part, the GUI, was never approached. Having Rebol/view, VID, draw dialect, sound, etc. ported to WASM would have been absolutely killer - can you imagine? There was a time I would have spent 10s of thousands of dollars to get that done, but no one cared or even seemed to understand why that would have been valuable. I'm fully past that, but I'd still love to see the simple Meta CRUD system I've described. I think that would be useful to so many developers, becuase little in-house CRUD apps are still a huge market.

All the Meta web sites and web apps, and the new Syllable front page, are written in a dialect. It's a thin dialect that allows all features of HTML/CSS/JavaScript, while still helping with their creation. A REBOL/View like dialect can be built on top later. Remember, the strategy is to first access all platform features, and then build easier dialects on top. This dialect is currently in REBOL 3. One of the goals I'm developing towards is to port it to Meta. In fact, it's a complete XML/HTML codec. When you have Meta on both client and server, there is no need for JSON; it would be inefficient. However, I long ago published the first JSON codec for Red, so another goal is to port that to Meta for communicating with other systems. Similarly, as we know, simple database apps in REBOL don't need databases. But I also published an SQLite binding for Red. I have ideas for making a better one in Meta. Again, later, an abstracted dialect could be made for multiple database systems. Your vision is mine. The REBOL design has a great capacity for abstraction to make things easier. I was always frustrated that it wasn't used to make existing systems easier, mostly only for its own internal purposes. I tried to open up Red to the outside world, but experienced friction. Meta is designed and built as an integration engine, the spider in the web. It looks like REBOL, but is built out of existing parts. The language is just a dialect that binds it all together. Using existing parts is the fastest way to construct this vision. Still, it's a huge amount of work, and lower-level parts need to be integrated before we get to higher-level parts. Even if we see where we are going, it is still some way to go.

I like your input to hear what business programmers are using these days. Not everything is suitable for Meta, though. Some things are examples, but competitors. Some things can be integrated, but can be expected to be too much work too support. Some things can be integrated, but are much heavier than other options. It's not good to do heavy parts first, because Meta would send its users into an inefficient direction. It's best to offer the most efficient options first. Meta is currently built on C, and eventually we'll have a situation like with C. Many projects can have Meta bindings, but they wouldn't necessarily be part of the Meta project. What's coming from the official project will be a selection more like REBOL, an integration of efficient choices.

By the way, I made the Meta sites and web apps fully responsive, making use of flexbox layouts. We work on Meta on all types of devices during the day. This is also the reason that browser support only goes back one decade, not two. These responsive features weren't available then. (Back then, responsive meant responding fast to user actions, in Amiga OS, BeOS and Syllable. This term has been hijacked by the web community. Browsers are not responsive at all, even as I just type this in a standard text box on a phone. I call it adaptive instead.) These adaptive features are not formalised in the low-level web dialect, it's just CSS. They could be formalised in a higher-level View dialect.

NiceGUI is almost the first framework I see that writes its own website in itself, so it's the first one that is not out on the first strike. :-) These frameworks justify themselves in terms of the other frameworks not being adequate for their purposes, confirming my apprehensions about them. We know there has been technology to do better for a quarter century, but it hasn't been applied. A decade before NiceGUI, I did a live coding demo in GTK+ for Red: <a href="//github.com/kealist/RS-fossil-mirror/blob/master/GTK/examples/GTK-live-coding.red">github.com/kealist/RS-fossil-mirror/blob/master/GTK/examples/GTK-live-coding.red</a>

Check out how they're using nicegui to control robots: https://rosys.io/examples/steering/ Right now, Streamlit is more powerful and more productive (consistently gets more done in ever fewer lines of code) than NiceGUI, and its capabilities, community-built components, etc. are growing by leaps and bounds, but Streamlit isn' made for building web 'sites' - it's really aimed at the ML community (data scientists), and especially for visualizing data results with charts and graphs, so not at all surprizing their web site isn't built with Streamlit. I did use Anvil to built the site where I'm advertising my (primarily) Anvil development services: <a href="http://www.com-pute.com/" target=_blank>http://www.com-pute.com</a> BTW, it would have been far more productive, more pleasant, and there would have been more options available, if I had built the Anvil tutorial in Anvil, instead of with Makedoc. But I was new with Anvil at the time, and it felt strange to use the default Anvil layout styling to display screenshots of the default Anvil layout styling... Then, when I wrote the Streamlit tutorial, I just cut down on the source file of the Anvil tutorial, so it was quicker just to use Makedoc again. For most documentation now, I use Markdown in Anvil (and any other Anvil widgets/tools needed to make nice page layouts, live features, etc.)

Check out how they're using nicegui to control robots: https://rosys.io/examples/steering/ Right now, Streamlit is more powerful and more productive (consistently gets more done in ever fewer lines of code) than NiceGUI, and its capabilities, community-built components, etc. are growing by leaps and bounds, but Streamlit isn' made for building web 'sites' - it's really aimed at the ML community (data scientists), and especially for visualizing data results with charts and graphs, so not at all surprizing their web site isn't built with Streamlit. I did use Anvil to built the site where I'm advertising my (primarily) Anvil development services: <a href="http://www.com-pute.com/" target=_blank>http://www.com-pute.com</a> BTW, it would have been far more productive, more pleasant, and there would have been more options available, if I had built the Anvil tutorial in Anvil, instead of with Makedoc. But I was new with Anvil at the time, and it felt strange to use the default Anvil layout styling to display screenshots of the default Anvil layout styling... Then, when I wrote the Streamlit tutorial, I just cut down on the source file of the Anvil tutorial, so it was quicker just to use Makedoc again. For most documentation now, I use Markdown in Anvil (and any other Anvil widgets/tools needed to make nice page layouts, live features, etc.)

Rosys looks more like a Logo Turtle to me. :-)

I think Nicegui is a partial corollary to what you're trying to do. They literally wrapped the entire Justpy.io project, which itself integrated Starlette and Uvicorn on the backend for the server, and Quasar, ag-grid, and other powerful third party frameworks on the front end (plus integrated highcharts, Matplotlib, markdown and other libraries), to create a truly full stack system that's entirely codable in Python (all but a database - just drop in SQL alchemy or any pure SQL library available in the Python landscape). The makers of Nicegui said Justpy was 'too low-level HTML' for their daily usage, so they wrapped that entire system in a higher level Python 'dialect'.

There is a LOT going on under the hood in NiceGUI - Justpy is pretty deep, with a lot of integration on it's own - still offering only a *miniscule fraction* of what Anvil does to ease developer pain, and to improve productivity, but Nicegui is definitely a neat project that uses what I think of as something reminiscent of the Rebol feeling of dialect creation to provide a simplified language interface to the features provided by another very comprehensive project.

Quasar is a real gem, and strikingly complete as a UI framework. They push using their CLI, and the on building mobile, web and desktop apps (w/ Cordoba or Capacitor, and Electron), but you can just import the library (~15k) and use all the 100+ AAA quality widgets. Justpy is stuck on version 1 of Quasar. I haven't done any work with Quasar yet - focusing on Flutter - but it's really worth looking at...

Thanks. It looks a lot heavier than MDC Web, though.

I haven't looked into MDC Web. I saw these big notices: Web support is planned The Material Web team is making significant changes to the codebase in preparation for adding Material Design 3 support. Follow the material-web repository on Github for updates. IMPORTANT: Material Web is a work in progress and subject to major changes until 1.0 release.

Yep, just the right time to support the new version. :-) Many projects that Meta uses have only become feasible in the past few years. They mature while Meta develops. It's why I couldn't really have done Meta this way a decade ago.

Stay ahead of the curve!

I mentioned jslinb above, and it brought back a feeling of reminiscence, so I cracked it out again yesterday and set up a front end for a set of Anvil HTTP endpoint functions. I made 2 versions - 1 using the aging built-in 'linb.ajax' API, and another version using fetch. The really cool thing about jslinb (as long as you only use the built in API functions) is that you get a totally free, open source visual UI builder which you can install just about anywhere: https://guitarz.org/jslinb/Samples/index.html https://guitarz.org/jslinb/VisualJS/UIBuilder.html and apps that run on virtually every mainstream browser ever made (very very old versions of IE, Firefox version 1, the browser that came with the first iPhone, the first versions of Android, QtWeb, etc.). I feel like a total nerd spending Friday evening connecting this crusty thing to an Anvil backend ... but who knows, maybe some day some client will be in desperate need of a birthday reminder system that runs in IE 6 :P linb.ajax version: http://musiclessonz.com/jslinbcrudgrid/indexajax.html fetch version: http://musiclessonz.com/jslinbcrudgrid/ Next Friday maybe I'll make an NS Basic version ;)

Honestly, it sends a chill down my spine to think about how difficult even little demos like this were to create in the past. Now, creating such more capable apps, with with multi-user access, authentication, reliable and consistently accessible interfaces across common mobile and desktop platforms, etc., takes 5 minutes, and connectivity with so many more fundamentally useful capabilities just sitting there for the taking. It's neat to play with old tools for the mental gymnastics, but jeez, this work has gotten to be so easy :) ...cue old man saying, 'I remember the old days when we had to walk 3 miles in the snow, uphill both directions'... :P

I woke up snowed in this morning. :-D I'm a different kind of old man, because since 1994 I could easily do all those things, with Lotus Notes. Since that time I have been appalled how long it takes for the world to first reject and then poorly reimplement superior technology. It's why I usually ignore all "new" products. The only newer development platform that warranted attention was REBOL, because it was the only one that solved fundamental problems that I encountered in Notes. REBOL is fundamental technology, Notes had more of a framework built in. So here I am, still looking to reconcile those things, improving the fundamental tech and aiming to build new frameworks on top.

Plato inspired the invention of Lotus Notes, Notes inspired the invention of web browsers, and it escalated from there, because nobody wanted someone else to own the technology. REBOL tried to do another silo product, but it was too late for that. Like REBOL, Meta will have the most benefits when it is used for all parts of a system, for example on both native client and server. But it will also be encouraged to use it for isolated parts, integrating with existing systems and filling the cracks they leave open. A big part of why all those old systems fell by the wayside, Notes, REBOL/View, the old web frameworks you show, and even Red/View, is that those GUI's are based on fixed coordinates, usually on large screens. Smart phones and tablets made that inadequate. The way I make my new web apps could run on the oldest browsers, except that there is not much point anymore in not making them responsive, which puts browser support at around the last decade.

The need to be responsive makes the concept of drag-and-drop UI builders problematic. They exist because HTML/CSS/JS is hard, but I think a proper Meta dialect would still be a useful middle ground.

Responsive layout with a GUI builder is another pain point that just evaporated with Anvil ;) I've been happy with how layouts look on mobile by default, and the layout process is so much faster than with fixed coordinates.

That's interesting.

Even without responsive layout, jslinb has some really nice ways to use screen real estate: http://musiclessonz.com/jslinbcrudgrid/linblayout8.html Check out all the accordion sliders on tab 1 of PAGE 2. That's a lot of real estate that takes up very little space on mobile, and still works functionally on bigger screens. Pop-up dialogs, like in the third tab also privide a great way of maximizing the effectiveness of every pixel. I love that jslinb can run on virtually every device that could ever run a mainstream browser, and that I can connect to all my modern backends :) I'm posting this using an old version of QtWeb - a great little browser that runs as a single uncompressed file of about 7.5 megs, with support for every OS from Windows Vista/2000 forward, MacOS 10.3, Linux, Unix, etc.)

Definitely ancient looking, but it's got grid grids, and everything needed for all sorts of common CRUD work. I'm starting a project to show all my favorite front ends connecting interchangably to all my favorite back ends - so they're all dealing with the same database tables, API layers, etc.

If you'd like to experiment with hooking up and testing Meta with any of those pieces at any point, just let me know. That could be a fun way to focus on building and testing some useful core functionality. Setting up a Rebol server in a Docker container on AWS, Google cloud, or Digital Ocean would be a good way to get it started. I've got plenty of working code to get that up and running...

And of course, there are already CGI examples up and running that could be used right away...

Yes, the Meta Pig Latin CGI service is still running: <a href="https://do.metaproject.frl/examples/PigLatin?x=This%20is%20rad">https://do.metaproject.frl/examples/PigLatin?x=This%20is%20rad</a> To work as a client, I need to make network bindings. The scaffolding is already there.

To be clear, the only reason that I'm messing with JS linb, is because it's got the best cross browser support, across the entire history of every web browser that I've ever seen, so it's just a little insurance policy to ensure that I can hack together a managably useful front end for existing CRUD systems, in the case I ever run into edge situations in which a client needs access on some very old hardware system with a no longer supported browser It's also one of those free tools in which the workflow* is productive, and it can be hosted and accessed from basically any common device - and given the limitations of the ancient environments it can work in, it's pretty darn powerful and reasonably professional looking. Simple tool chains that let me accomplish lots of productive work, on any device, no matter where I am, have value to me. JS linb's little visual layout system, and all the widgets it has, form a really nice package that I can run anywhere, without having to install any software - it shares that useful characteristic with Anvil - the entirely self-contained IDE, where all the visual layout and all the coding happens in a browser - I can install the entire package on any web server, or even on a phone that's completely disconnected from the internet, and it outputs a nice clean zip file which contains all the resources needed to deliver and host the project, plus I can save an entire project to a single text file, which can easily be sent by email, uploaded, transferred instantly between machines, etc. And since I can connect it to any web API, running in any language on any server, using any database back end, etc, there's still plenty of potential use for it (my only interest and it is really to support old platforms, but it's one more little tool that who knows, may get used in other ways). Just tonight, one of my friends told me that the whole business he's employed by still realies on a core part of the system that needs Windows 95, and they can't seem to escape that requirement (for some political and or technical reasons), and that's a really huge business- I was actually thoroughly awestruck to hear that's the case there, but it certainly made me realize it's not a bad idea to be able to still support very old systems.

Meta should run on Windows 95 once I release 32-bit programs, like the Windows-native Pig Latin CGI I compiled for you. (And I want to support ReactOS.) Meta must eat away at existing systems from the bottom, so we shouldn't wait until there's a complete development environment, we must look for small parts of existing systems to replace where Meta can already add value. The two strengths it already has are platform support and efficiency, including speed.

So, why not extend what you've done with Metapig to accept requests to create, read, update, and delete values in rows of a data store of some sort? Then we could connect any front end to that and do typically CRUD work it. Most front ends will send those structure as json - I even have the rebol code needed to decipher the examples in the tutorial at http://re-bol.com/jslinb/ . Why not start with some of those examples? They accept parameters sent the same way the metapig app did. If we could get create, read, update, and delete functions happening, then there's already the most critical part of a working system based on Meta, that others could begin to use. Can you save data structures to a file, or can you use a C library to work with Sqlite on the server? Really just storing series structures in a flat flat file is enough to get it working...

I have 20 different ways to accept requests on the back end, so this isn't critical for any work, but I'd love to see Meta grow. What I see as the value that Meta adds is that it's light weight. It could potentially be installed in places where modern python and Fastapi, for example, would be more difficult to install. I can do that right now with Rebol core and CGI scripts on any cheap shared host, but Rebol is closed source, and at some point it won't be supported, and that entire historical option will disappear. I'm sure there's a market for that sort of back end, even if it's just able to handle simple CRUD interactions with a flat file to start out. To begin, use any JS front end library to create user interfaces that send some data. I'm happy to help build some front end examples that connect with whatever pieces you'd like to test. Maybe just recreate some of the functionality of the Rebol code in the examples at http://re-bol.com/jslinb/ , since there are already Rebol code examples there that might provide an easier starting point, and which work with some paired existing front end code. I can see people being interested in such a system that requires only a single tiny binary without heavy dependencies, and which connects with a front end that can run in any browser anywhere.

Present it as a demo with a bunch of great little layouts all doing using little CRUD operations and tell them that the entire system can run on an 8 bit Atari, and whatever other ridiculously bare minimum OS requirements you can port it to. Make it run on as many platforms as possible, including phones, and you'll turn heads. The development world going the other way, supporting firestore, netlify, snowflake, AWS, Google Cloud, Azure (and even things like Anvil), etc. in big ways, and I'm sure there's a huge crowd of experienced guys who are horrified with that progression, and would love to support a smaller system that doesn't require such big infrastructure. If you can make start towards making the "lightest weight web API framework" that all the new JAMstack developers can connect to, you've got a market.

Is there a C library you can use to encode and decode json data structures that you can then save to any existing database, or any storage mechanism? You don't need to accept json, just a string of URL encoded parameters, but being able to just decode a json body would make the system able to connect with just about any front end (funny, the built in ajax functions in jslinb or the opposite).

There must be a number of JSON codec libraries in C, but I wouldn't bother with them. I would port my JSON codec in Red to Meta. The only thing is that not all needed data types are implemented yet. SQLite is a C library, so I would port my Red bindings to Meta. In that case, Meta would directly use SQLite data types. A CGI CRUD interface certainly wouldn't be hard. The question is what interface is needed. I have several CGI interfaces for the project. In general, an app is best served with a custom interface design between client and server. I never use a generic CRUD interface to a database. Meta CGI interfaces are easy enough. I would look what an app client needs. For the chat forum, I use text files in blockchain-like structures. It is better to do a generic JSON codec and SQLite binding and some general CGI examples. There are thousands of examples I could do. I can't afford to work randomly on them. I looked into the Windows 95 target. It doesn't seem to be covered by my current plans, but it can be done. Again, hundreds of possible target platforms. I can't afford to do them randomly.

https://musiclessonz.com/jslinbcrudgrid/ uses the modern fetch browser API to send a json payload to one of 4 HTTP endpoints ('web API functions') . At the server, each particular HTTP endpoint function performs an individual create, read, update, or delete operation with the json data, in the database. Most current web front ends will connect using those mechanisms http://musiclessonz.com/jslinbcrudgrid/indexajax.html uses methods from the linb.ajax library, which are just wrappers for the old XMLHttpRequest ('xhr') browser API. Those pieces of data are transferred to the server as URL encoded parameters (http://site.com?name=john&time=1200am). You could interface with the second example above by just extending what you did with the metapig CGI interface. The idea at first is just to create 3 functions at three different CGI endpoints that can create, update, and delete values from some row based data structure that you choose, using the incoming data values send to each of those scripts: http://site.com/create.cgi?name=john&time=1200am http://site.com/update.cgi?id=12 (or maybe http://site.com/update.cgi?name=john&time=1200am&newname=johnny&time=100pm) http://site.com/delete.cgi?id=12 (or maybe http://site.com/delete.cgi?name=john&time=1200am) and 1 endpoint that reads: http://site.com/read.cgi?id=12 (or maybe http://site.com/read.cgi?id=all) Dropping the '.cgi' and the '?' would look more like people expect now: http://site.com/read/12 But you can certainly just start with accepting data sent via the older xhr API and accepted at CGI script URLs with '?id=value' pairs, just like with metapig. If you want to decide how to store values in any structured way that you're comfortable with, at least to to start out, that method doesn't matter so much, as long as you can create, read, update, and delete values in each row/record. then just create 4 endpoint functions (scripts) to do each of the 4 CRUD functions. If you'd like to try doing that for the http://musiclessonz.com/jslinbcrudgrid/indexajax.html example, you'd be well on the road to having useful backend system, and already one that developers could use the open source jslinb IDE to quickly make front ends for your system. That would be a pretty darn useful way to get people's attention. If you'd like to do that, I could write some examples and documentations to show others how to use it.

jslinb is very old, but it's free, open source, and using it should be immediately familiar to anyone who's used any IDE that descended from the Microsoft VB style visual development environments (or any of the thousands of variations of those sorts of environments). It'll also connect easily with the simplest possible CGI interface that you've already got working. Your biggest decision is what sort of data storage mechanism you want to start out with, but you can change that out transparently later on. For the proof of concept, and getting a 'REST' API set up, the front end doesn't care how that's accomplished.

jslinb is very old, but it's free, open source, and using it should be immediately familiar to anyone who's used any IDE that descended from the Microsoft VB style visual development environments (or any of the thousands of variations of those sorts of environments). It'll also connect easily with the simplest possible CGI interface that you've already got working. Your biggest decision is what sort of data storage mechanism you want to start out with, but you can change that out transparently later on. For the proof of concept, and getting a 'REST' API set up, the front end doesn't care how that's accomplished.

Hopefully, that's a concrete suggestion that would provide an actually useful set of tooling, which shouldn't be a monumental set of tasks to achieve, and which I can help test, and write examples + documentation, if it's an interesting goal for you. I can imagine other potential users finding that bit of infrastructure actually useful. There's no pressure from me, I'd probably be years away from wanting to try using it in production, but it's definitely the sort of tooling that I could imagine being able to eventually put to productive use.

The smallest examples in your tutorial can be done now, but for the larger ones Meta needs more array support and file operations first. A JSON codec and file serialisation or an SQLite binding are substantial work. I can't prioritise that now over other work.

I could do something excruciatingly simple, if you say this would be useful.

The idea would be to first just to create a dedicated endpoint API for a single little app - maybe a contact management app, or even a just todo list, shopping list, etc. - and then make the API more generic and add features for searching, sorting, creating new database and schema, etc. Sqlite would work well for this since it's file based, and has every possible feature already built in, just needs to be wrapped. Give results back to the front end in json format, be able to accept incoming json body structures, and you've got a really usable generic system.

I thought so, you want me to write a database system. :-) That's not what I need to do now. I always had ideas in this direction, but it will be REALLY simple.

I'm just trying to suggest some direction that I can potentially offer some help with (examples, docs, testing, front end to your back end, etc.) - and just in ways that make sense in my world. I'm not asking you do anything, just wondering where we might find some common ground. I suggested using sqlite. That seemed to me like a potentially good fit for your background in C. There needs to be some sort of storage mechanism for any sort of CRUD system, of course, but like I said, how that gets implemented doesn't matter to the front end - or to me :) No pressure, I'm just hoping you can find more community to support your efforts, and offering my two cents about what might attract a community. ...ok, maybe I've offered my 792 cents, but I'm just hoping that you can get to the point where people are asking to help you build this cool new thing...

What I'm focusing on is the idea of a REST API - that's where I think you'll find common ground with a larger community, and the beginnings of a system that might attract users. If you want to focus on system development, games, etc., then clearly, that's not a direction to go - but you're already building web apps with Meta, so building an HTTP endpoint API system seems like an obvious move - one that will be familiar and useful to a massive crowd of potential users, and a building block that may be easier to complete than other potential goals. 793 cents :)

I'm warming up to the idea, but I always have to sleep on such a thing. It's a sign that we have indeed reached common ground for a concrete step, so thank you for that! :-) I don't want to do a big project that I won't use myself and that others will regard as a toy. I have a hard time believing that many people would want to build client/server apps on a generic database API, but thinking back how we got into this mess, that is exactly what happened. Decades ago, file systems weren't good enough for databases, so database systems evolved. First COBOL-style database files, that I had to program. They had trouble supporting concurrent access, so a lot of complexity had to be added, that often remained unreliable, especially over network file systems. Then database servers were added on top to regulate the access. Then they could be extended to network and Internet access. People were so happy to have something that worked some of the time, that everybody started programming to the network API's of these database servers. System admins, network admins and database admins were hired to keep it going. The next step was adding application servers in front of the database servers, and hiring application admins, because shoehorning an app into a standard database API led to more problems. But when you can't afford that step, I suppose standard database API's are still used. So they became fat by adding functionality of application servers, but not custom for your app. Meanwhile, computers and networks became thousands of times more powerful, but small apps using relatively small databases all use these humongous systems. They say most Oracle customers pay them big money to effectively load their data into cache memory. By now, almost nobody can imagine anymore that we could do without all this expensive complexity. Yet that is what I have to do. Meta will have to follow the above path to modern architectures, but simplifying everything along the way, starting with a Minimum Viable Product. Actually, I already have this, because I mulled this over for decades. For example, the user database in my new chat forum is built this way, similar to what you specify, but not bothering with a standard database API. I will port that from REBOL to Meta and generalise it. Meta needs some extra functionaly for it, and I need to support Arnold, too, so it will take a while, but it's a nice, concrete direction to work in, that I need anyway. The resulting code will be so simple, that people can use it either unchanged as a database system, or they can modify and extend it into custom application API's for their apps.

Central to the idea of modern web APIs is json. Python, JS, and all the languages and tools that take part in the modern web stack all use it natively. And that's why Mongo, Firestore, and other nosql database systems are popular - it allows users to model their whole database system using the same data structure that is used for all data transfer transactions. Mongo and Firestore are basically big searchable repositories of json documents. That works really well with the way everyone brought up on web APIs thinks. If your hope is to be immediately relevant to a potential broad base of new users, being able to work with json data structures should be a core goal. Food for thought as you think about putting together pieces...

JSON is needlessly complex. I certainly won't use it in the internal implementation, but I will support it as an option for an interface format.

Wearing clothes is needlessly complex. ... but you kinda have to do it if you want to hang out with other people.

No one cares about the machinery of the backend, only about the API (and most web APIs now transfer data in json format natively).

I read 'interface format' initially as 'UI interface format'. Did you mean that in the sense of data interchange/transfer format?

I'd pick JSON over XML any time.

100 million other developers said the same thing, so here we are. Douglas Crockford said: "JSON had a lot of influences on its design. It didn't just come out of my head. It's based on a lot of things that I had observed over the years ... Another influence was Rebol. Rebol's a more modern language ... in that it's all built upon a representation of data which is then executable as programs... it's a much richer thing syntactically. Rebol is a brilliant language, and it's a shame it's not more popular, because it deserves to be."

There's always something even worse. Depends on who you hang out with, Nick. ;-) Yes, I meant transfer format. I wonder what you mean by native. A database that stores all data in JSON format would be very inefficient.

https://www.mongodb.com/json-and-bson#:~:text=the%20BSON%20specification.-,Does%20MongoDB%20use%20BSON%20or%20JSON%3F,just%20as%20easily%20in%20JSON.

I meant 'natively' in the sense that jason is currently like a sort of 'native tongue' of common data structures. Everyone expects to be able to work with json by default, for built in tools to take care of parsing, manipulating and transfering json data structures without little effort. Internally, in MongoDB, those structures are saved and transferred as bson (that's what the link above is all about).

Right, they can call it BSON for marketing, but it has little to do with JSON. It's just their internal format. I'm using similar designs in my storage and transfer. It's just a myth built around JSON. It doesn't solve everything.

For example, you don't "manipulate" JSON data structures. You parse them to some internal format, then manipulate them, then encode them into JSON again when the user wants them back. If you can leave out the parsing or the encoding, or you can replace them with something simpler or more efficient than JSON, you have an improvement.

By parsing the data into an internal data format, manipulating, and re-encoding, you've manipulated the keys and values in a JSON data structure - that was my point - developers using json don't care how that occurs internally, they just expect to be able to use that data structure, send it somewhere, get a json data structure from an API service or a file, or returned from a database search, etc., and refer to values with keys to manipulate those values, etc. No one wants to get anywhere near the guts of how that happens internally, they just want to be able to access, manipulate, and transfer that data, using that familiar and universally supported structure (universally among the hundreds of millions of developers who are familiar with it in the environments they work).

Ah, but I do care how it works internally, because you want me to program it. :-) And the way it's implemented can make several orders of magnitude difference, which shines through to the users in the external properties of the product. If they want to talk JSON, fine, but it will cost some performnce, and a JSON codec is relatively large for, say, an Internet of Things sensor, so your sensors will need more expensive hardware and more energy.

We could semantically and technically about what's actually happening when you 'manipulate' a string, but bringing developers back to the level at which they need to think about what's happening internally with bits and bits being processed by a CPU is not the way to improve productivity and move on to higher and higher levels of composability. That's the job of the language and the tooling. At this point, even the idea of a database system (and the use of SQL, for example), and everything that occurs in all the layers of the network model, as well as every part of the the rendering systems upon which user interfaces are built - all those things are abstracted away for developers. We use ORMs to create, read, update, and delete data in databases, without having to think about the differences between the versions of SQL used in each database, or how to serialize and de-serialized values properly. We use layers of UI tooling that hide all differences between subsystems on different OSes, so that one consistent tool can be used to build beautiful and complex front ends that look and act exactly how they're expected to on every OS, with grids that paginate automatically, and animations that run with a single function, for example, or 3D interfaces that are built at a level which is intuitively simple for even small children to create visually. We use machine learning libraries to 'teach' a system to recognize poison ivy images that appear in a video stream, running on a microcontroller that costs $6. We use web APIs which send and receive json values using a familiar HTTP endpoint syntax, and which hide everything about how that process in the machine's memory, the OSI model, etc. Rebol had the right idea about how to simplify so much about all those sorts of processes, but the actual language, program structures, UI interface builder, and high level capabilities of development systems available now have far and away superceded anything that Rebol ever approaced achieving. Yes, internally they're more complex, but no one cares abou that. The care that they can build their 3D game, or their web site with a beautiful interactive layout, or their AI device that they can put on their bike to recognize poison ivy, with ease. Anvil and other modern tools enable me to accomplish all those sorts of high level things very easily, and they just work. That's the way Rebol was in it's day 20 years ago, but it's absolutely nothing like what I can do now. It's 50x easier to actually work with Anvil and create useful software (and I spent thousands of hours working with Rebol). But yes, the internals of all these systems are incredibly complex - the developer's user experience is fantastic, but the underlying machinery is outrageously complex, and most developers these days rely on third party services to enable facility in the development process, hosting, etc. Big systems are containerized and hosted on AWS, entire backends run on Firebase, entire systems like Anvil, including IDE, DB, etc. run in a browsers. Functionally, that is super convenient, but despite cloud providers like Google, Amazon, and other cloud providers likely being more reliable than any service I could create, I do NOT like HAVING to rely on any third party system to make my systems work. Even Python's pip install, which is absolutely awesome, or any libary management system which relies on CDNs to deliver pieces of a software system - despite being more reliable than anything I can create - still rubs me wrong, and I'm interested in how Rebol was able to do so much with such a great foundation that eliminated that need for so much complex infrastructure. But what drew me to Rebol - my experience, in terms of facility and productivity as a developer - has been tremendously superseded by newer development systems, so I'm going to use those systems to get work done. But I'm still interested in seeing a system developed which cuts down on the complexity of all the internal machinery - all the third party hosted layers and dependencies. Making a system that does that, and can at least fit in with what modern developers expect and need to get work done, starts with having a UI layer that runs across all mobile and desktop OSs with the least amount of installation trouble for users (web does that), having an HTTP endpoint API, using json data structures, and having a database (or some equivalently functional data persistence layer) on the server. Any system that starts with that, can at least by useful and able to be integrated with the modern development environment. I didn't make those rules, but they're a way to fit in and be relevant.

At least, having a web UI, HTTP APi, server database system, and json support, seems like the most realistically achievable way to be useful, integrateable, and relevant in the current landscape.

I'm not at all saying that I want to expose developers to bits and bytes of the implementation. I keep saying that I will support them talking JSON, as an option. But to make this project viable, I need to think about the implementation. And it will have nothing to do with JSON internally.

Remember, Meta is about reducing waste, by reducing accidental complexity: <a href="//language.metaproject.frl#muda">language.metaproject.frl#muda</a> There's no point in doing things just like others do, because you might as well use those existing products. And I wouldn't be able to duplicate them, anyway, because you would be eternally chasing tail lights. We've done that in the second half of REBOL's existence, and we don't want to do that anymore. We want to move ahead. There's plenty of accidental complexity in the systems and layers you describe, so that is specifically what we want to do differently. We should not <a href="//en.wikipedia.org/wiki/Wirth%27s_law">mistake complexity for sophistication</a>.

Rebol died for me when it stopped being able to connect with other systems, and make use of technology that was evolving around it. Being able to use json and connect to functionality via web API, like the rest of the world does in so many other systems seems like a bare minimum for compatibility, and for developers to leverage the benefits of other existing systems.

Of course, json wouldn't be used internally, we're clearly working with the same understanding that it's a format for data representation and exchange, at the user level.

I need to be really clear, I'm not *asking you to make this system. I'm offering what perspective I can, from my point of view. I'm interested in what you hope to accomplish, I think your goal in creating a successor to Rebol is valuable. I'm happy to offer what support I can in the form of testing, building user apps, docs, etc. But for my own needs, I am fully tooled up and not needing an alternative for my work. Anvil is just one of the tools I'm mired in. I can deploy apps made with it using the open source server, and I have multiple alternatives for every piece of any part of a product I build with Anvil. It's basically ideal at this point for most of the work I do. Streamlit, existing databases, and generic Python have already been productive for dealing with data scientists' requirements. jslinb is what I need to support UI on legacy devices, with a back end build with any platform. Godot is perfect for potentially game, graphics, VR, and other related needs. Flutter will likely become my preferred tool for building customer facing front ends that are distributed as mobile (+ web/desktop) apps (and I'll roll with quasar and whatever other similar frameworks become useful). Python, JS, Node, etc., will probably always be in the mix. For my needs, I'm mired in those sorts of tools now, happily. Actually, those sorts of tools give me great satisfaction and joy at this point. And they give me the opportunity to do lots of the work that I love to do with other human beings, especially in their business environments. My interest in Meta comes from my experience with Rebol. I've gotten past my expectations to ever be able to use Rebol in my productive life again, but its values and methodologies, and the whole perspective Carl enabled and instantiated/incarnated with Rebol is something that I held very close to my beliefs, and which actually was productive to me. I think building a system that eliminates complexity at its heart will be fundamentally useful in this world. I'd like to take part in supporting those values, and to help share that perspective, and the benefits that come from it, with others. I'd also like to see you become successful. I'm interested in what you're doing with Meta, because I have a lot of insight into how and why it can be valuable. But I need to make sure you're not working with an understanding that I'm waiting for you to build a tool for me to get work done. At least not at the moment. I'm just excited to see you approaching what I had desperately hoped the community would realize was important. I've had to move on to other tools to be productive, but I'd like to see you succeed. Please don't mistake my suggestions and 793 cents about what I think are necessary building blocks for developers in my position, as requests to begin a project.

I think we are in agreement. It's just that we started the same path two decades ago, but halfway we took different turns. We hoped for too long that REBOL would do what it should be capable of, that was clear to us. You held on for a long time, but eventually started collecting alternatives. I started looking for ways to extend REBOL myself, joining several open-source projects, but eventually having to decide to start my own. You used many alternative systems. I only reviewed them to see what was essential about them that REBOL should be able to do. JSON went on my list, so I wrote the first Red codec for it. But I don't care for all those systems that use JSON, that I analysed as non-essential, accidental complexity. We're now looking at the same thing from different directions. It's why I was reluctant about the formulation of the project until I had thought it through. I have made a plan to make it fit in Meta's development. But that means that I'm serious about it. I will do it in a way that will make it hard for you to resist using it, otherwise there is no point.

I'm excited to see how you get started and what you come up with!

Nick, Check out https://flet.dev It allows you to build Flutter apps in Python. Seems like there is no need to load the Flutter framework.

You need to installl a Flet client, which includes Flutter - somewhat comparable to REBOL/View - and a Flet server, and your own Flet app on the server.

I have looked at Flet. The thing that stuck me ws that it's a tiny and quick install compared to the Fluttter SDK. I wonder what they've done to make it so small. Have you built any production apps with Flet?

A very cool thing I learned from flet is that fly.io 'provides a free remote Docker builder, so you don't need Docker installed on your machine'. I'm really eager to try that, maybe with nicegui, because needing to install docker really kills the lightweightness of many solutions.

No. Not yet. After a bit of investigation, it looks like Kaj was correct. 'appveyor.yml' lists Flutter SDK as an essential download (923 MB). I really hate downloading/installing something this big. The rest is about 37 MB for a Windows installation. Looks like a Python client driving a Flutter front-end via a Go server. I was checking out "Wails" as another option. But for now I really thinking hard about getting to know Nim - it has Fidget, a cross platform UI library for Nim. I really wish Rebol had most of Nim's capabilities built in over the years.

BTW, for web development, Quasar CLI doesn't need any tooling whatsoever installed. With the UMD version, just import the CSS and JS files. These examples took a minute to copy and paste into a text editor, then upload to an old school shared hosting server: https://com-pute.com/quasar/quasar-drawer-layout.html https://com-pute.com/quasar/quasar-table-with-selections.html Hook up the Quasar widgets to the MongoDB data API, for example, using Fetch or Axios, and you're most of way to building really useful modern web apps. And then when you want to package for mobile and desktop app stores, the Quasar CLI has you covered.

With that said, 1 GB now costs literally a few cents, so 1 GB for a serious tool doesn't upset me. What upsets me is limitations. My most recent micro SD cards cost $99, they store 1 TB, and transfer 1 GB in a few seconds, so for certain projects, I don't mind a heavy installation. For Flutter, that includes installing Visual Studio Code, with the Flutter and Dart plugins. They make editing *much more productive. A typical stack is Flutter + Firebase, Amplify, Mongo data API, or whatever other chosen BAAS is preferred. The trade off for that heavy setup is the ability to accomplish just about any sort of imaginable work, with support in most mainstream development communities, the ability to work with potentially millions of other developers who have deep experience with that platform, and the fact that that big installation can produce the most cutting edge (useful and sellable) front ends for mobile, web, desktop and even future OSes (Fuchsia, for example). Those are real practical needs that are more important to satisfy in my life than saving 1 gig of HD space. There is no trade-off for capability...

It's not about the storage cost. 1 GB has space for many millions of bugs and other vulnerabilities. <a href="//language.metaproject.frl#muda">language.metaproject.frl#muda</a>

For example, my official Google Chromebook regularly breaks my Microsoft Visual Studio Code on updates, so that I loose my development environment for some unknown period. Not exactly productive.

All I want is basic text editing and a 2022 setup doesn't even offer that.

I've never lost anything on Anvil. I just haven't had any pain with Anvil in any way at all, in any phase of development, deployment, working with others, etc. It's just been relentless pleasure and productivity :) We'll see how Flutter, Quasar, all these BAAS solutions work out...

The main thing I don't like about all the heavy tools is that they require new machines with new operating systems. But I consider a solution like Flutter a solution for a particular set of problems - basically when best in class everything UI is required. So far, it's very exciting, but I'm still a baby with Flutter...

Try Anvil on your Chromebook, even an old one. It works reliably and quickly - and you can jump between your Chromebook and another machine whenever you want. (You can also use jslinb on any machine the same way). I tend to use notepad++ and CMD for anything on a local machine, but as a result of Anvil's fantastic IDE, I'm getting used to having autocomplete write 70ish percent of all my code. So I'm trying to get used to visual studio code, because the flutter plugins help in much the same way. So far, I'm not finding it buggy at all on any of my old Windows 10 netbooks...

I was excited when I first saw vscode for the browser, but it's been a joke. None of the plugins work.

I've been thoroughly amazed by the lack of trouble with Anvil throughout every phase of learning and use in productivity. It's been a complete answer to everything I've ever been looking for in a software development system for several decades. It feels so so right, like nothing else I've ever experienced. Everything just works the way it should, and it's infinitely expandable and connectable to every other tool. I haven't been disappointed or frustrated by it yet. Every new direction I go with it yields new fully working solutions within a few hours, and the process of getting things going has just felt enjoyable. Everything I jump into with it has been successful, and it's just been easy. Everything else I work with still feels like a painful mess.

I'm exploring lots of alternatives for the database piece, only because hosted Anvil's database can get expensive. Right now I like MongoDB data API. That's one of the best things about Anvil, you can replace any piece of it with something else, either with web APIs, Python SDKs, Anvil's Uplink, and other tools that connect with it.

What's clear is that having all the pieces of a system, whatever those pieces are, all integrated into one workflow - so that everything from code editor/IDE and UI designer, to code file management/hosting and revision history, to database and storage, to backend server logic, to API, etc. - everything is integrated with a consistent language and workflow interface. Integration of all the pieces is a huge part of what leads to enhanced productivity.

I was happily usinf Geany, but wanted to know what the buzz was with VS Code. It has some nice touches, but nothing worth suffering unreliability over. As you say, the things that could make a difference, such as the Red plug-in, don't work. It's built on Electron, so it stands to reason that it can't be made reliable. GTK+ is not well integrated on Chromebook, but if they break VS Code once more, I will go back to Geany and won't feel guilty for being old-fashioned. I do strive for integrated environments, because I came from Lotus Notes, but with all other tools after it, it has been impossible to collect a good environment and keep it working. I hope to build it with Meta, but it will take time.

At least, I have Meta write 70ish percent of my code now. The C generated from a main program is typically around twice as large as the Meta source, and then it compiles in used parts of the runtime C functions.

A "syntax" highlighter for Meta in VS Code would be a nice addition. Looked at some tutorials but they use some Yeoman generator (for a plain-text file seriously?). And it is not clear which files to add to .vscode/extensions/ that do matter and how the coupling with the .meta extension would be made. Everybody is making the same time consuming video tutorials nowadays so you can't even tell if they do or do not feature the content you really need at all.

That would be nice. It would probably be easiest to start from the Red plug-in server, but you would have to fix it. I saw someone say it works for them, but for me it always crashes at start, when opening a Red file.

One of the biggest things that keeps me away from big tools and systems like Flutter is the heavy hardware and OS installation requirements. I'm currently trying out https://flutlab.io/, since I can run it without any installation, on any machine with a modern browser. There are a bunch of other services like that, will build pipelines for iOS, Android, web, desktop, etc., without having to install anything. A good setup like that feels like it could be a very productive solution.

I love the idea of owning and controlling every piece of tooling in my pipeline, so that there is no vendor lock-in, but when tools like that work, it makes sense to use them for the enormous majority of tasks. Just backup regularly and be able to switch to your own infrastructure if ever an online service stops working. That sort of routine feels pretty darn ideal to me.

I also love that there are tools like Flutterflow, which enable super-productive work based on an open source tool, and which enable even non-technical people to get involved with creating actually useful software (especially pieces such as visual layouts) - without ever tying any project entirely to a single vendor or tool set.

The problem with big tools is that even if they're open source, that's quite meaningless, because they're too big and complicated to take over their development, let alone their maintenance. This is a big part of why noone took over Syllable, and I now have to resurrect it. There isn't even that much activity in continuing REBOL 3. Even though it was relentlessly focused on simplicity, it's still too much. Most parties who tried dropped it eventually.

Of course, I already started on the track of a web IDE that builds in the cloud: <a href="//console.metaproject.frl">console.metaproject.frl</a>

I paid Cypher to port Rebol 3 to Android. It took him about a week to get a Rebol APK going, and a total of just a few weeks to complete Graphics, GUI, networking and everything else that I asked for working on Android. So I think for any system, it depends on the pool of people who are available to work on a project. With tens of millions of people using flutter, there are an enormous pool of people who are capable of adding and making changes to the system. On top of that, Google is supporting it! Just because the absolutely tiny crowd left in Rebol wasn't able to make Rebol move forward, doesn't mean that open source doesn't work, or that truly significant development doesn't happen in open source projects. It's a matter of support and demand. And demand for Flutter is astronomical. Most important for me with open source projects, is that they can be used freely. When a project or platform is past it's life, then there are new projects and platforms to replace them.

That was much appreciated. Yet, not many people produce Android apps with REBOL 3. As you say, more is needed. It's true that REBOL's implementation is outdated, but its design ideas are not. It wouldn't be good to have to live in a world where only huge projects by huge corporations can exist. The Internet has enabled a long tail of just about anything. Smaller projects need to be nimbler in order to exist. Being huge is no guarantee for survival, either, as the dinosaurs could attest to - if they were still alive and had evolved to develop speech. (Or perhaps one should <a href="//atheos.metaproject.frl/atheos_parrots.html">ask a parrot</a>.) I standardised on Lotus Notes because it was well designed and developed and supported by IBM - the best you could ask for. Yet, it's almost completely non-existent now; I can't use it anymore.

Yeah, but while the dinosaurs were here, I'd prefer to have beeen the biggest baddest dinosaur on the block :)

AtheOS parrot was. :-)

We all know why R3 open source failed. It failed because there was no one there to ( A) explain a bit how it worked and B) ) accept changes into the original repository. It was open sourced and abandoned. I call this Open Source Carved into Stone variant. And lastly R3 the major shortcomings of R3 (no GUI at no 1) were too big for many including myself to overcome. I had not been aware that a port to Android has been made.

https://learnrebol.com/rebol3_book.html That was for R3 Saphir, which runs on Android, with Cyphre's GUI (different than R2 VID, but mature). There are a bunch of examples on Rebol.org for it. I'll have to find a download link for the binaries and APK, because the Saphir link is now broken. It's been around for a decade :)

For Android: http://re-bol.com/r3-droid.apk http://re-bol.com/r3-gui.r3 Windows: http://re-bol.com/r3-view.exe

For Android: http://re-bol.com/r3-droid.apk http://re-bol.com/r3-gui.r3 Windows: http://re-bol.com/r3-view.exe

There was even a attempt to port R2 VID to R3 View: http://www.rebol.org/view-script.r?script=vid1r3.r3

Ah I see. And also I notice that the script by Marco notes that you need to have SDK. When I came into the Rebol universe, Carl did not show up frequently so to say, and getting one seemed a risky business.

He gave that away at some point

That was never advertised ;-)

Nick, I haven't installed Anvil for offline use yet. I hope a local install results in a fully installed offline Postgresql server. With Anvil, can I use Postgresql custom functions with it? I want to use the pgsql server as an application/logic layer. Hope you can shed some light. I cannot find anything on the website.

Yes Anvil installs Postgresql. I haven't used Postgresql custom functions with Anvil.

I'm curious what you need to Postgresl functions to accomplish.

...and would love to hear what you're able to get done!

Is there any reason that you can't use psycopg2 on the back end in Python to access Postgresql functions?

psycopg2 2.7.1 is installed in the hosted version of Anvil (https://anvil.works/docs/server/packages), and you should be able to pip install anything you want in your self hosted Anvil environment.

Theres's info about accessing the postgres db outside of Anvil at https://github.com/anvil-works/anvil-runtime. You can use psql-anvil-app-server together with psql and other command line and graphical tools, with direct access to the Anvil app tables schema.

I am interested in pursuing it after seeing a blogpost on the versatility of Postgresql and I want to see how far I can push it. (Ref. this book:) https://theartofpostgresql.com Also this video: https://youtu.be/Ztvst8IxtjE I want to keep Python use to a minimum. Also Postgresql offers of so much more, especially the security and concurrency aspects of it.

Anvil without Python? That seems like Rebol without series ;)

Yeah Nick, :) but in Anvil it seems like the perfect and easiest place to see if this book can teach me some other ways to approach a problem. The guy mentioned that an online playground would be the perfect place to practice the 300+ code examples found in the book, without the need to install Postgresql. I know there is a lot of Python code on the internet. But it will be good to have more than one way to reach a solution. Postgresql gives you a lot of easier ways to do it. But there are things you cannot do easily, like calling out to an external API in the middle of a sql query, and the call fails or takes to long to complete. Should you roll back on the data, or is there another way to have a successful outcome... I have a Postgresql server installed with Anvil, might as well try it. Curiousity you know. ;) How big is the total Anvil setup when installed?

Why not try bit.io?

Bit.io is zero install postrgres and you get lots of free use

They've also made it really easy to upload csv, sqlite, json, and other files.

The biggest parts of Anvil app server appear to be Postgres and the Clojure web server that require JDK.

BTW, I've used Firebase and MongoDB in Anvil apps also, and you can use any DB accessible via Python. There's no tie-in to using Anvil's built-in DB - the built-in DB tooling just gives you a visual table editor, Python ORM, autocomplete in the IDE, all integrated in Anvil's single environment. The real thing that sells me on Anvil is having all the infrastructure and tools integrated and available in an environment that requires absolutely nothing but a browser. The workflow in Anvil is ridiculously productive - better than any no-code tool, but with such wide capability: Access to anything in the Python ecosystem on the server and access to anything in the JS ecosystem in the browser, all integrated with the visual tools for file and project management, GIT version (development and production) management, database, IDE with autocomplete, graphics/drawing canvase API, authentication, Google and MS services integrations (Maps, Docs, etc.), Stripe integration, email services integrations, the uplink (even with Micropython on Pico W boards!), and all in a beautiful workflow that runs entirely in a browser on any common modern OS. Rebol was 10x more productive than other tools in its day. Anvil is 10x more productive than Rebol ever was... and able to be connected to anything that's accessible via Python or JS. Whenever I hear someone disect one part of Anvil (like the database), I have to point out that the bigger picture is soooo much more than any single piece of the system.

Also, the amount of Python understanding that's needed to use the majority of features in Anvil can be learned by any experienced developer in a day: mostly just some basic syntax, things like learning for loops and understanding how to use lists and dictionaries. Any other generic Python code, typically related to using the standard library and other libraries in the wild can generally be gotten with a Google search. I've found the Python ecosystem to be extremely pleasant - I rarely encounter troublesome gotchas or workarounds, everything tends to just work. It's nothing like the nightmare of JS and other language ecosystems (although just plugging in 3rd party libraries from a CDN and integrating them in Anvil tends to be super simple - as in a matter of minutes, even if you don't have background in JS and web development). Getting over the initial learning hump is a matter of days, for anyone with some development background, and then the ongoing productivity benefits increase really quickly.

I'm sticking with Metro4ui as my HTML/CSS/JS framework of choice: https://com-pute.com/metro4ui/index2.html https://com-pute.com/nick/metro4uicrud.html https://metroui.org.ua/intro.html

I've been running all my Python backends using unmanaged VPS hosting, runway 4 at https://www.a2hosting.com/vps-hosting

Metro UI is phenomenal - I have to wonder how hard it would be to make a drag and drop builder for it with something like GrapesJS...

I've also been playing with qooxdoo as another possible front end to support old browsers. I haven't used it anywhere in production, but like jslinb it supports really old browsers, and unlike jslinb it supports flexgrid and slightly more modern design. Jslinb is still my go-to if I need to support very old devices and browsers, because you can simply import the library and write code, or use the great visual layout builder. Metro doesn't have any sort of drag and drop designer (yet), but it's so easy to use - basically like supercharged HTML with every common (and not so common) feature and styling option, that just works responsively on mobile and desktop - that I prefer just to lay things out in code. It's the most productive, simple to use, and robust library for front end web design and that I've found yet.

Just as important, Metro doesn't require any bundle/build system (web pack, parcel, etc.). Just import all (or any specific pieces) of the Metro library from CDN (or locally), and use the 137 HTML widgets on steroids, the robust layout and event handling system (no jquery needed), all in whatever text editor you like. It feels like using HTML from a quarter century ago, but looks and feels very modern on mobile and desktop. (He created complete React and Angular versions, and Vue can be integrated easily, but absolutely no 3rd party bits are needs).

Everything is beautifully documented in Metro4ui, and the are some great examples. This one reminds me of some old Rebol experiences: https://metroui.org.ua/examples/desktop/desktop.html https://github.com/olton/Metro4-Examples/tree/master/src/desktop This is the big one, with a bunch of common little app and site layout examples (which I re-mixed in my demo above): https://themes.org.ua/pandora/

Kaj, Metro's built-in wrapping of XHR works great to send AJAX requests to any of the Python (or JS, Java, etc.) RESP API implementations, but it's also just as east to send requests to REBOL CGI scripts, etc. (as form-encoded, json, string, or file data). If you're interested in testing any more Meta backend with it, let me know!

Qooxdoo is out of the running for now. It's slow and doesn't work as reliably as jslinb, on old machines. Metro is a real pleasure to work with.

Thanks, Nick. I have a long list of external projects to review now, and some projects of my own to work on, so it will take me a while.

I used Metro to layout my music instruction business website (completed while watching the superbowl): http://rockfactory.us I've also gotten into using MDB. I actually purchased their commercial version (the first tool aside from Anvil and A2 hosting that I've paid for in many years).

I've been on Linux kick lately, settled on using Q4OS (32bit) on old winXP netbooks (atom processors with less than a GB of RAM). We have a pile of those machines, and that OS has won out for a great balance of performance, features, usability, etc. It's fast and immediately usable - Chromium works best (much quicker than Firefox). All the development tools I use are immediately available and work perfectly on that platform.

I've set up those Q4OS machines for non-techie users and my parents, and they've been instantly usable by anyone who's familiar with Windows (and the performance, even on very low powered machines) has been better than I ever expected. Slitaz is faster, but hard for average users to set up and get started with.

I've set up those Q4OS machines for non-techie users and my parents, and they've been instantly usable by anyone who's familiar with Windows (and the performance, even on very low powered machines) has been better than I ever expected. Slitaz is faster, but hard for average users to set up and get started with.

When Slitaz arrived, it was obvious to me that they tried to make it like Syllable. :-) The efficiency and for example the power-off menu.

There has been so much work done on all these distributions. It's humbling to think about how many man hours have gone into creating so many tools.

I put together a nice little full stack toolkit that's usable on a wide range of older machines. It runs on stock python 2.7 or 3.x, without needing any additional libraries (nothing needs to be pip installed). It consists of Bottle (used as RESP API layer, although it can be used for much more), PyDAL (database abstraction layer that works with a huge variety of RDBMSs - Sqlite works out of the box, and I've included the required MySQL drivers in this little package), and jsLinb for a front end visual builder and framework that connects beautifully with the back end (although any other front end with REST requests can be used). The entire system weighs in at less than 1.5 Megabytes, and takes less than a minute to install (only requires downloading and unzipping - nothing else): https://com-pute.com/nick/bottle-pydal-jslinb.zip This is a bigger version with docs and more database drivers: https://com-pute.com/nick/bottle-pydal-jslinb-complete.zip I've run the back end and this entire development system on my old Android phone using Termux, on every main version of Windows back to WinXP (should be able to use it on win95 too), on a wide variety of 32 and 64 bit Linux distros, on my A2 hosting account (and pythonanywhere supports Bottle by default), etc. Just download/unzip it and go, it typically takes just a few seconds to get it rolling. Here's a little example with the back end running on A2 hosting (using the default sqlite DB out of the box): http://musiclessonz.com/jslinbcrudgrid/bottlepydaljslinb.html Any of the components can be swapped out. I prefer MetroUI for a modern front end, and that framework has already been used with the back end components in this tool kit for several little CRUD projects - it's a beautiful and productive modern framework with a recent version that works back to IE9. I included jsLinb in this toolkit because it's tiny, has a really productive visual builder (the entire visual development system and runtime all together weighs around 600k), and runs universally on just about any any browser (if you code carefully using only the jsLinb API, it can work flawlessly in IE6, the very first iPhone browser, Android 1.2, win95 using Retrozilla browser, etc. - and in every modern browser I've ever tried). I was not careful with the quick example above, so only know that it runs in modern browsers like Chrome and Firefox. You can use any other web framework for the front end (any custom coded HTML/CSS/JS layout or any frameworks/tools (MUI, MDB, React, Angular, Svelte, etc.), that work with XUI, fetch, axios, jQuery, or any other library that enables ajax requests). You could also choose to use Bottle to deliver any front end code from the server - it's not limited to handling REST requests - but REST is Bottle's purpose in this tool kit. On the back end, Bottle could be replace by Flask, FastAPI, Django Rest framework, Anvil, etc. And PyDAL could be replaced by SQLAlchemy, Pony, Django, Dataset, Anvil, any other ORM, or just pure SQL in Python. ORMs simply enable switching between any RDBMS without having to adjust any of your code for the various flavors of SQL - and they tend to be much more productive, faster, easier, and more enjoyable to work with. The main benefit of this particular toolkit is that it's backward compatible to Python 2 and doesn't require any pip install, or even an Internet connection to run it - just unpack the 1.5 Meg zip file and it's fully installed, without any other dependencies beyond vanilla Python. It's all open source and free of course. I've ported a number of little apps from Anvil - once you get the basics of pyDAL and the basics of routing REST requests with Bottle, you're on your way with the full power and connectivity of the Python ecosystem available on the back end, and all the power of the JS ecosystem on the front end (with any choice of frameworks to make work more productive - I love jsLinb for old systems, and metro4ui for new systems). Porting from the Anvil REST syntax to Bottle, and from the Anvil ORM to pyDAL is easy and fast, so back end code reuse and logic is simple. You can use whatever editor/IDE is available on your development system. I'm happy with VIM or even Nano in a Linux console on a remote secure shell - using tmux to run and switch between processes - or Kate, or Kwrite or any text editor on a local desktop box - and on Windows I typically use Notepad++ (if you want all the autocomplete and modern IDE features, most people currently seem to choose MS Visual Studio Code). Bottle has a built in WSGI development server and I typically use python -m http.server to serve the front end code on a local development server, but basically any other servers work (but to be clear, you don't need anything else buy Python and the built-in tools to use this tool kit). This toolkit can be used to build web apps that run on basically any common modern or legacy back end (it runs great on those old netbooks with Atom processors booting up to a Knoppix live USB, for example), but it's also a very productive and convenient lightweight toolkit for building desktop apps, since the entire thing can be delivered by simply unzipping and running a shell script, on virtually any remotely modern Windows/Linux/Mac machine from the past 20 years, or any mobile device that can run Python (Termux is very quick to get started with on Android). Anvil, in its hosted version, is still more productive, powerful, and feature packed - I really prefer using Python function calls on the front end compared to JS and REST requests - but with tools like Metro4ui, jsLinb, or <insert your favorite popular front end tooling>, it's still very productive (I'd like to try with many more visual front end builders...). I love having a little toolkit that works for a broad majority of tasks, which takes seconds to install and runs anywhere, uses Sqlite built in or connects to a massive list of other common DBs without re-writing any code, without any vendor lock-in, or even any lock-in to any particular tool in the kit. Things have really changed :)

This little tool kit has really made me think about all the uses for old and inexpensive machines. Just as an experiment, I bought a little lot of old netbooks for $20 each, and I ran this system on a very fast and powerful Chromebook that cost $50, and on an Android that I bought new at Walmart for $19. Any Chromebook after 2018 should have the Linux developer backend available, and Termux can be installed quickly in the default Android environment on those machines (and Termux does work as a perfectly usable back end for this little tool kit). It looks like used lots of used Chromebooks made post-2018, with 4-8 gigs of RAM and really speedy processors (which run modern websites and all this server software FAST), can generally be bought for $20-$50. My interest is piqued about finding business and humanitarian applications - inexpensive machines have so many applications, and could be used to build up infrastructure in 3rd world countries. These sorts of software development toolkits make it possible to put old machines to use at nearly no cost. And as AI tools become more powerful and available (in the Python ecosystem in particular), the capabilities for putting computers to use beyond their traditional CRUD and information management, communication, and entertainment purposes, etc., really is exciting. In just a few years, for example, computer AI should be able to teach students math and reading as well as a human interactive instructor. And AI is already fantastic as writing code that takes many man-hours (I've been using ChatGPT to write and port code, and the productivity enhancements are STAGGERING). To have all those sorts of capabilities available on powerful and fast machines that cost a few dozen dollars each, and which may otherwise be destined for land fills, seems to be an opportunity for genuinely transformative possibilities in many areas of the world. Sure, people can use them to start businesses and run custom software for any traditionally useful purpose - but start using the capabilities of already existing AI, and those lots of cheap hardware which are treated like garbage, can be made to really increase human productivity around the world, in ways which we haven't seen yet in human history... I'd like to find a way to put those machines to use - especially the mountainous piles of powerful used Chromebooks that could be used to perform really powerful work.

BTW, Streamlit is also still a really cool tool, which makes me think a lot about the way that I could do CRUD work with a GUI in Rebol, except that Streamlit database apps are multi-user by default, and can run on any 'modern' desktop PC, mobile phone/device, Chromebook, etc. - by 'modern', I mean any computing device that has a decently modern browser available (on most platforms, this includes hardware from 10-20 years ago). The example below uses the super simple Dataset ORM library to perform database operations (this example uses Python's built-in sqlite DB, but you can switch to MySQL, Postgres, etc., just by changing the connection string - no other code changes need to be made). These 12 lines are the entire code listing required to build, configure, and instantiate every part of the fully functional CRUD app, with 2 database columns, including the user interface and all database interactions: import streamlit as st, dataset db=dataset.connect('sqlite:///db'); t=db['user'] #t=table if st.button('Add Row'): t.insert(dict(x='',y='')) #x,y=name, note for r in t: #r=row in table with st.expander(r['x']): with st.form(str(r['id'])): x=st.text_input('Name', r['x']) y=st.text_area('Note', r['y']) if st.form_submit_button('Save'): t.update(dict(x=x,y=y,id=r['id']),['id']) if st.form_submit_button('Delete'): t.delete(id=r['id']); st.experimental_rerun() The above code is running at: https://datatable.streamlit.app/ To set up a computer system to use Streamlit and Dataset (on any 64 bit machine/OS with Python 3 installed and an Internet connection), you just type 'pip install streamlit dataset' in the console. There's nothing else to set up. As cool as this is, Anvil is still much more productive, powerful, easy to use, enjoyable, etc., for most of the sorts of work I've been doing for the past year. My little bottle-pydal-jslinb tool kit linked above is just more portable - the entire development system (with visual drag and drop front end layout), server, and client components can run on basically any device/platform that I'd imagine being in common use today.

I should clarify: to set up a computer to *serve apps written in Streamlit/dataset, you just need to pip install streamlit and dataset. To *run the apps, you just need any modern browser on any device (as you see by going to https://datatable.streamlit.app/). BTW, the sqlite DB used by https://datatable.streamlit.app/ is automatically cleared periodically (this isn't the case if Streamlit is run in any other environment).

I only get a wait animation on your JSLinB example.

Opening your Streamlit example from here takes around 40 seconds the first time, and 12 seconds the next time. Performance for common applications is often determined more by keeping the platform small, than by using performant techniques for details.

There are people making Streamlit-like tools which are far more performant. It's a neat approach which is used mostly by data scientists to present visualizations and UI for in-house apps. I like the concept of a system which hides the complexities of front-end/back-end interactions. In production, Anvil's approach is still far and away more effective, but Streamlit has clearly struck a chord with data scientists who aren't software developers - it's tremendously useful for that crowd. As I mentioned, I wasn't careful ensuring the app at http://musiclessonz.com/jslinbcrudgrid/bottlepydaljslinb.html ran in every browser, so it may need to run in Chrome. I'm curious about which browser didn't load it, and if this one runs any better: https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html

I'm also curious if this runs in the browser which didn't load the link above: https://com-pute.com/nick/metro4uicrud.html If not, I may choose to use a slightly older version of Metro4UI for public facing apps. The jsLinb front end is meant for in-house apps that need to run in older browsers. I'll likely end up using a version of Metro or maybe MDB, which falls back to older custom HTML for really ancient platforms. It's getting harder and harder to want to support old platforms when lots of powerful Chromebooks can be bought $17 each, and they run Chrome ridiculously fast, without any n compatibility issues - or when we can boot a $10 netbook to Knoppix, and it runs all this stuff without any hitches or setup in Chromium or Firefox out of the box.

... or in any Android or iPad/iPhone running Chrome. It's getting hard to find common machines and devices in actual productive which don't support modern front end web standards by default. In fact, most people I work with find my interest in supporting old systems a massive waste of time. I do it for personal reasons, but it's generally better just to require users to use a device with some semblance of modern usability. Deciding to not use a software development system because I can't get it to run on my Tandy handheld pc from 1984 is not practical in the environment in which I live life.

It's faster and easier and better for me to even build 2 alternate front ends, than to deal with compatibility issues for users who don't want to use some sort of reasonably mainstream or modern device/UI. My back end toolkit above supports 99.9% of every sort of machine I'd ever expect to be un use by the sorts of people and organizations that I interact with in the mainstream world - Anvil even can claim that - and the developer comfort/productivity, and the lack of user troubles I now experience eclipses any experience I ever had with Rebol, far and away, without reservation.

It's always possible to say 'I was able to get this app to not run' by using some system out of the mainstream, but does the fact that someone can't get Flappy Bird to run on a particular platform invalidate to choice to build that app to run on more popular and available platforms? I'd rather write software that will run for 99.9% of my users, because they're running a platform that 99.9% of users can be expected to be using. And if they don't have one of those platforms, and want to run some software I've created, they can buy a device that will run it fast and flawlessly for $20.

I understand the point of wanting to build systems that can be compiled to run on an Atari, because that means that they can likely be ported to run on any machine. But then I could just say 'well it won't run on my abacus'. The fact is, the sorts of machines that are needed to run any sort of modern platform, are now old and being thrown in the trash, so that seems like a decent baseline requirement in terms of platform and hardware that should be required to run any sort of usable software these days. If old, trash hardware can run the software that I write, I don't think there's any need to support anything older. I'm not going to support an abacus.

Honestly I think all of these discussions are going to be antiquated in just a couple years. It seems that the unstoppable force of AI will change how every bit of development is done, and even the idea of software development by humans, at the level we imagine it now, will just be a historical memory. What I've seen in just the last couple months, which has been mind blowing, is just the very beginning couple steps in the journey that AI will take us on.

By the way, taking 40 seconds to open an app for the first time, without having to install anything, or do any other sort of prep to be able to run the sorts of powerful applications that are having profound effects in the environments in which streamlit is used, is not the bad thing that you seem to think it is.

In any company where a data scientist would otherwise have had to work with their infrastructure's development team to deliver the results of their research, or otherwise take enormous amounts of time to perform the work and the maintenance required to deliver results and provide a workable user interface, it's an absolutely industry changing Improvement. That's not an opinion, just the reality of what's actually happening with that particular tool. My use of Anvil, and other tools, is likewise an unmitigated triumph (for my needs), compared to the overall issues I experienced using Rebol - in the same way that Rebol provided similar improvements over previous tools.

Judging streamlit's value by the fact it took 40 seconds to open the first time feels comparable to hearing people judge Rebol because they didn't like the default colors and look of the VID interface.

BTW, a part of that performance is also because it's running on the free streamlit hosting service... not to mention, it only took me *8 seconds to open that app for the first time on a 7-year-old Android phone that cost $20 new, and *4 seconds to open on a reasonably new netbook. That's not a problem by any measure, it's a valuable, useful, welcome solution.

BTW, also my little bottle-pydal-jslinb demo takes *1 second to open on that same old Android phone, with no installation and no other requirements on the (multiple) users' side, and a minute to install on the server.

Premature optimization is well understood as a problem in many environments. No one is using anvil to build a replacement for Unity or Unreal Engine, and of course most of the heavy hitting libraries in the python ecosystem are written in C, but they're written once and reused in a more productive tool set. Discarding the possibility of development using a system that doesn't support a small fraction of on a small fraction of all existing machines, when it's almost certainly better to replace an offending machine or the browser, is not something that works in my world.

I'm definitely an outlier for even considering to put together a tool kit that runs on such a vastly broad variety of machines, compared to all the commonly used tool systems that are in popular use, and I'm really excited to have that set of tools available for the weird circumstances in which I can't use the other big systems I have available that work for the absolutely overwhelming majority of cases that I will ever be involved with, and to have such a system that makes the vast majority of the modern python ecosystem available to me in such a productive way.

The circumstances, costs, scope, and capabilities of modern computing systems are very different than they were when the Atari was released. There's No Business justification to optimize any of the systems I'm using more than they already are. If I was a systems developer, I'd work in C and assembler. Those aren't the kinds of problems I'm interested in. We clearly have different perspectives about what we want to accomplish, and even the sorts of technological development we're interested in. The foundations of the systems that I'm using are clearly more complex at their heart, then you're willing to work with, but they are extremely well established, well tested by tens of millions of users, and generally problem-free for their users, compared to anything from previous generations. They are solid, productive, and useful in productive ways that absolutely blow away historical software development systems aimed at that sort of work.

I recently had an experience with a businessman who decided to use Anvil to build his next project. He's a rockstar tech CEO who's made companies many hundreds of millions of dollars over the past 40 years. He chose Anvil out of a variety of other tools. My only role was to help him build certain features of the company's public facing app. Recently, I've been watching his marketing and data science teams do their work, and it's absolutely awesome to witness what is clearly going to save the company many millions of dollars and wasted effort, and likely turn this venture into another company worth $100M+. I'm interested in that sort of work. They did some absolutely remarkable computing work, often researching and finding extremely valuable results several times in a day, refining and focusing their market goals in ways that clearly will have a tremendously positive financial effect. At no point any of those interactions was anybody worried about wasting a few seconds waiting for an app to open. The value was in the computational work they were able to accomplish. That's not software development, but it's an extraordinarily valuable aid to business. That's what I've always been interested in - computing tools which provide real value to users in business in real life, as opposed to technical computing and software development accomplishments. Anvil, Streamlit, and this little tool kit that I posted, provide such value to me, and from what I see the mainstream tools do the same for many others.

Being able to scrape third-party websites, perform complex analyses of trends in data, and provide various useful visualizations of the results is handled so dramatically easily with tools such as streamlit. The value of fast productivity with powerful data collection and analytical tooling can't be overestimated. And that's much more exciting to me than low-level system development. I feel the same way about what AI has already done for me in the past couple months. I had a client who came to me with thousands of lines of production C# code that he wanted moved into a web app. In one night, I was able to accomplish what previously would have taken many weeks of grueling work, using ChatPT to analyze the logic, code structures, data structures, etc., of the previous app, write python code to replace it, structure, check and reevaluate, troubleshoot and debug my work, Etc. In the end, we chose to repurpose his existing code in a different way, but the AI did an absolutely amazing job that would have taken many dozens of human hours. Since then I've gotten used to using it for absolutely everything, and I expect that human work in software development will change dramatically within the next year or two. Like I said, I think the sort of things we're thinking about now will be antiquated in just a few more years after that, and I'm so excited to be able to use tools like what exist already!

A little tool kit that I put together just enables me to use all the same ecosystem, which existing AI tools have proved to be able to work so beautifully with, and run code in environments that the newer productive tooling can't be used on. To me that's extraordinary valuable.

JSLinB not working and the Streamlit form taking 40 seconds to load happens on the latest version of Brave on my new Samsung phone, which is based on the latest version of Chrome.

Thank you, that's helpful :) Does this work in Brave?: https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html Or this metro front end?: https://com-pute.com/nick/metro4uicrud.html

Here's a copy of the jslinb demo above using another version of jslinb, does it work in your browser?: https://musiclessonz.com/jslinbcrudgrid/linb4Demo/ I may end up using that version if it works for you (I've seen it work better in version 10 of IE):

One of the nice things about all of these toolkits, is that any front end which can connect to a REST API can be swapped out easily.

Does this Anvil front end work in your Brave browser?: https://crudgrid.anvil.app

Only the first JSLinB hangs on the wait animation. The others have reasonable load time of a few to several seconds. However, my Meta/REBOL web apps load faster, in around a second, depending on your location and Internet quality. This is important for not turning away modern users with short attention spans.

Thank you! To be clear, both of these work?: https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html https://musiclessonz.com/jslinbcrudgrid/linb4Demo All of those examples use a back end on the shared host version of Anvil in a small personal account based in England, so yes, it is slow. The same Anvil code is *very fast when served on my A2 account, and of course that speed can be optimized with faster dedicated machines and other significant server optimizations. My little tool kit is *dramatically fast compared to Anvil, because it is much simpler (Bottle is a single code file of only ~4000 lines), and the built-in development server can be *swapped out* for other lightning fast servers that can compete in performance with any other server in the market (and can scale up to handle any load), so performance speed can be absolutely world class. Of course, some of the biggest busiest sites in the world run on Python.

https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html does not work. England should be fast here in the Netherlands. Your Anvil example above is only slightly slower than the others, about three versus two seconds.

Streamlit is not fast, and I expect it doesn't scale well. It's purpose is developer productivity - used to deliver the sorts of daily in-house work such as the back and forth marketing research/analysis I witnessed. For that sort of work, it's a phenomenally useful tool. Some people do use it to build web sites with moderate traffic, but it's clearly not suited for busy e-commerce. The nice thing about the massive Python ecosystem is that there are tools to satisfy every need. There is free hosting available to support all the productive little tools such as streamlit, and porting Python code between frameworks is fast and easy. By using an ORM such as PyDAL I can use sqlite for development and light production use, and then switch to postgres, oracle, mysql, mssql, mongo, google app engine, etc., without changing any code at all (just a connection string), and aditionally, pydal can help scaling up with connection pooling, connecting multiple servers, etc. There are so many options for perfect, hyper-productive prototyping environments, and also for deploying at the largest scale, using battle-tested frameworks that handle 100s of millions of users. And of course, there are libraries that make quick, reliable, and performant work of just about any task, and there are billions of lines of code that are already being used to train AI.

Thank you so much for the feedback! It's very helpful to know that https://musiclessonz.com/jslinbcrudgrid/linb4Demo works where https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html doesn't. That's been the case with 2 other browsers, and since my only point in using jslinb is to have a visual layout tool that produces front end code that connects to any of the back end systems, and works in the broadest range of new and very old browsers, I'll stick with that version. That version of the editor also includes autocompletion and a few more widgets. I'll upload a version of my toolkit with that jslinb:(

The Anvil example above is only slightly slower than the others because those other front ends are running on the same Anvil back end for REST functions. I'll publish a version using the better jslinb with the bottle-pydal backend, and several different DBs. I should also try using something other than the development web server in Bottle. The end result of all that should be blazing fast and scalable.

This should work now: http://musiclessonz.com/jslinbcrudgrid/bottlepydaljslinb.html And here it is hosted on the same server as the back end (still running in Bottle's development web server). I'm not sure yet if that makes much of a difference: http://server.py-thon.com/bottlepydaljslinb.html

First one hangs on the wait animation, second loads in about six seconds here.

Thank you for checking - that's bizarre They're the exact same code and CORS is set up properly (and both use the exact same back end). I'll focus on the other version of jsLinb - I've notices that safari and IE 10 also have some unexpected interactions with that older version of jsLinb, but not with the newer one (I was hoping to use the smallest, simplest version possible). That feedback is very helpful - I appreciate it.

I'm curious what about your situation is making everything take so long. The apps above open fully on my old Android (and a massive variety of other devices, OSs, browsers, and Internet connections) in less than a second, so it's not something inherent in the software or the hosting. Why it's taking so dramatically long for you, makes me wonder what other layer between your new phone and these apps is causing such exceptional delays.

Right, there is no silver bullet. ;-)

RockFactory from England is OK, 2 seconds. I suspect RockFactory 6s is US? Across the pond, inefficiency multiplies.

Most popular web frameworks work for the overwhelming majority of users, with the overwhelming majority of devices in common use, at least in my sphere of existence. I haven't had a single client, or any of their users ever have any usability issues or make any mention whatsoever about slow performance with any Anvil app, so it has absolutely been a silver bullet for mainstream users using all the most popular devices in common use. Your experience here has been the sole outlier. My little toolkit is just an effort to support ancient systems which generally aren't used any more by mainstream users, but which are interesting to me.

Rockfactory is currently hosted on Hostpapa (cheap shared Apache hosting account), using metro4ui as the front end. It also opens instantly on any device/OS I've seen. Our clients use it every day.

Your feedback here has been very helpful. For any production app not developed in Anvil (not in the cards for me generally right now), I'll use metro4ui (or maybe MDBootstrap) for any public facing UI. I'll get the newer version of jsLinb working, for my own interest in supporting special old devices and ancient browsers - it seems to work on 99% of every old browser/OS, and all the new ones. I was hoping to use the older, lighter version, but that's not as important as compatibility, for its use case. Thank you for all your help. If you need any help testing your new build servers (very exciting - I'm so happy to see you making progress!), please let me know.

Here's little toolkit demo, redone using the newer version of jsLinb, with front end and back end both hosted on the same server (A2): http://server.py-thon.com/botdalinb4/linb4demoNEW-botdalinb.html Here it is with the front end hosted on my HostPapa shared account: http://musiclessonz.com/jslinbcrudgrid/linb4Demo/linb4demoNEW-botdalinb.html Here's the same front end, with Anvil as the REST back end: https://musiclessonz.com/jslinbcrudgrid/linb4Demo/linb4demoNEW.html I'm curious if there are any browsers or devices that have any problems with them.

Most of them load in 3 seconds the first time, then 2 seconds the second time. The first one takes 4 seconds the first time. The second one keeps saying: Error: Network problems-0 It's very unlikely that this has to do with the browser. Brave is a fairly common, popular browser, anyway, based on Chrome.

Those results are exceptional, and nothing inherent in the software. Here's a video of the demo apps running on an old Lenovo Thinkpad netbook and an old Android phone, connected to the Internet using a T-Mobile home cellular router. https://www.youtube.com/watch?v=FD8GwQm30CM Here it is running in the very old QTWeb browser on that same underpowered Thinkpad netbook: https://www.youtube.com/watch?v=_m4mmt52reQ Here are a couple Streamlit and Anvil app examples: https://www.youtube.com/watch?v=4z97odNdN20 I tried my little toolkit demo app example yesterday on a variety of old $20 netbooks running Knoppix, 32 bit Q4OS and various versions of old Windows, Chromebooks, new and old iPhones, iPads, and Androids, and in a wide variety of browsers, all run by me and a random assortment of friends at a number of locations, without any hiccups or delays of any sort whatsoever. In every case, each version always takes less than a second to load, without exception. It's important to note that *those Youtube videos*, as well as any of the other common Google apps, and all of the common web sites in popular use by hundreds of millions of people, ALL take several seconds longer* to load on those same devices, so the idea that this software itself doesn't perform well, clearly doesn't hold water. My experience delivering web apps for the past year+ has actually been exactly the opposite of problematic. The truth is, delivery of software using Anvil and python web apps has been an absolutely glorious, trouble free pleasure, compared to my previous experiences trying to get people to download and run apps across a variety of platforms and devices. Rebol made that situation a bit easier than it had been previously (in the dark ages), because it was so light weight and simple - but of course there were still always a mountains of user issues and troubles getting people to use any installable software on any machines in the wild. With many hundreds of regular client users, using every sort of mobile and desktop device/OS/browser in the wild, I've never had even a single complaint or trouble getting people to use my Anvil web apps. I just send them a link. That's it. They click the link and the apps runs - whether they're on desktop or mobile, and whatever version OS, hardware, etc. Web apps have have been so dramatically easy to deploy - not to mention *upgrade. Users are automatically using the most recent version of Anvil apps, just by opening the link in their browser - there's no upgrade procedure - the worst thing a user might have to do is refresh their web page, or God forbid, try another browser (I haven't even run into that yet). These demos of my little toolkit with jslinb are an experimental side project at the moment, in the very first few days of development - the Anvil apps are what I'm currently using in production (and a bit of metro4ui with self-hosted Anvil on the back end). The fact is, there are clearly not any *inherent performance issues with *any of these platforms - no more so than any other web app, and in fact better than most massively adopted web apps. And I'm demonstrating these apps on ancient hardware and browsers. You can see that they clearly perform fast. Your unusual outlier experience is introducing some obviously significant delay for *every single* platform and hosting environment that I've linked to here, so that's telling. Streamlit is a slow system, but it clearly doesn't take 40 seconds to load for most users - just a few seconds on an old device with slow hosting. It's much faster, closer to instant, on any common modern device. Obviously, it wouldn't be adopted the way it is, if a typical user's experience required that sort of wait time. If you were a client, clearly I'd have to help you determine the cause of your particular slowdown, but I've not had that experience with any user in production yet, using any of these platforms.

It's got to be pointed out that no Rebol app was ever used by nearly as many people as any of these Python platforms, not even Streamlit. And there's no comparison to the battle tested, rock solid use examples of Python platforms such as Django and Flask in production at Instagram and other sites that have hundreds of millions of users. I'm not crazy to think that these platforms are viable, stable, and performant.

jsLinb is clearly the weak link in my little toolkit, but that's easily replaced. I'm just motivated to put that to use, because it's the best all-round solution I've found for ancient browsers (that doesn't apply to mainstream users). Bottle, pyDAL, and other front end options are battle tested. I appreciate your help looking at the toolkit examples. I'm satisfied with my local results with jsLinb, but now motivated to continue working with metro4UI and other front end options. Anvil will continue to be my production system. I can't help by wonder why every single platform example you've tried here has performed so remarkably badly.

I should reiterate my perspective about everything related to software and tech in general. The greatest value I find in computer technology is as an aid for improving processes and productivity in 'natural' life. In an afternoon, I can build an app to handle ticketing and admissions for performances of my new musical. Or I can take 20 minutes to write an app that connects with the dall-e or chatGPT APIs, to interact with and use those resources in ways that are repeatedly productive and beneficial for my business and personal needs. Or I can likewise use the Twilio or Dailyy APIs to add custom text message and videoconference capabilities to an app in a few minutes. Or I can take a few days and write a business system for an accountant friend which runs all his payroll and billing, saving a dramatic amount of work and trouble for everyone in that office. Or I can build custom software to run every piece of operations at Merchants Village, Rockfactory, and all my other endeavors, in my odd free hours. Being able to simply text, email, or verbally give a link to every mainstream user of my current apps which they can just open on whatever phone, tablet, or computer they have, is a life changing improvement, compared to the old ways of doing things, which eliminates most of the time consuming problems inherent is distribution of apps (and development productivity, of course). Giving data scientists and other professionals, whose main focus is not software development, the ability to quickly deliver the results of research, enables improved progress in so many industries. Making quick work of that goal is worth making their users wait a few seconds to open an in-house app, if they're using an unusually old or otherwise disabled or specialized device/system. I have an interest is making software work 'everywhere', but that takes a resolved back seat to 'productive use of computing resources', which in my applications, has been tremendously improved by all these Python tools, in the same way that Rebol had improved that situation previously. I'll likely never take part in systems development. My tools are not meant for that purpose. I deeply respect that sort of work, and every value that you have related to developing Meta. I'm just sharing what is working for me, and working brilliantly, compared to every system I've used and tried in the past (many hundreds, of which Rebol had previously been the best choice for my needs), in the hopes that someone with my same values and requirements may find my current experiences helpful. Compared to Rebol, Anvil and the Python ecosystem has been far and away more effective at enabling the sort of productive use of computers, and I think some of these other Python tools will fill in the gaps for which Anvil is not effective, without much additional overhead (and the ability to port working code, etc.). That's not to say I don't appreciate and look forward to seeing what you'll accomplish with Meta. It's exciting to you move forward and hopefull building something even better, and with more potential!

I'm doing nothing special to provoke this, just clicking the links you ask me to try in my popular browser of choice. I think you need to accept that performance of web apps from the other side of the world is different than nationally. It is dominated by how your software performs over the Internet, performance of your devices becomes a minor matter. My Meta/REBOL web apps are currently hosted in the middle of the US, but I can access them in around a second mobile from the Netherlands. This is a comparable situation to when I access your demos that run in the US.

You're not provoking any trouble, just helping to clarify our perspective and priorities. The performance troubles you're experiencing are not a problem for my use. My Anvil apps are hosted in England. There has been no performance problem using them in the US, and the self-hosted app implementations have performed faster for my use. My little toolkit isn't meant to be used to serve apps to an international community at a large scale. It's meant to be used to build in-house and local apps that can run on as broad a variety of systems as I may ever want to use, including old and under-powered devices which are generally just thrown away these day (I imagine potentially valuable uses for those sorts of machines). It satisfies that requirement effectively and productively, while supporting the most important requirement of mine, which is to enable the availability of all the tools in the Python ecosystem. Any code I develop with that little tool kit, Anvil, vice-versa, or with any other Python tools is then portable to bigger systems, with more performance options engineered in and scaling practices that have been put to the test by some of the biggest deployments online. The speed of the systems I'm mentioning here doesn't create any usability problem for me. The lack of capability, connectivity, deep support, convenient deployment options, and productivity features, has been my problem with other systems. The Python ecosystem and these tools have solved those problems, and I can scale up using any of a variety of tooling options that an army of developers know how to use (not to mention existing AI tools that are phenomenally productive). If I ever need to hire others for a big project, collaborate personally or to do work in a organization with other developers, for example, I don't experience any friction using Python, JS, etc. And beyond that, I get lots of enjoyable work being hired to satisfy needs with these tools, which I find satisfying and fulfilling. I'm just sharing my experiences and my excitement with what these tools have enabled for my needs. We currently have different requirements for tooling systems. I'm simply posting and clarifying my personal thoughts and experiences related to my long list of experiences with Rebol, in a thread entitled 'What I'm using now instead of Rebol'. I don't know if anyone else will ever read any of this, by I hope it's useful for someone, especially as an extension of (or comparison with) anything that I ever wrote about how Rebol was useful and productive for my needs. To that end, it's important to put into perspective how your usability issues are not at all a trouble for my use cases. I'm glad for the feedback, to know some metrics about how my particular little toolkit and hosting choices are not best used to deploy a multinational site/app, but those results don't effect my current use, and deployment practices can be dealt with as needed, if I ever happen to become involved with a project that must scale for a wider user base around the world. It seems that my hosted Anvil apps deployed on AWS already work well all around the world, and they can be scaled up dramatically (one of my clients was able to get support from Anvil to scale up to 300,000 requests per *second*, if his needs grew to that level! Of course that would cost a lot, but still just a fraction of his proposed budget). So I appreciate your feedback, and welcome any criticism and comparison with what Meta can accomplish. I'm fully aware that your intention to eliminate complexity is quite worth while, and I do deeply respect what you're working to achieve, and the challenges you face. My needs and goals in working with development tools are currently different, but I'm keen to keep an eye on what you create - and willing to help if I can potentially make a difference.

If you want to try installing any Meta applications on my server, for the sake of performance comparisons that may be beneficial to you, for testing purposes, or any other reason, please let me know :)

BTW, one of the things I'm eager to try after your feedback here is faster WSGI servers that work with Bottle - something other than the built-in development server, which isn't intended to be performant. Also, I'm curious to compare the performance of Flask, Django, and FastAPI (I've seen some benchmarks in which fastAPI is 3x faster than Django), and compare the performance of pyDAL, SQLAlchemy, Pony, Django ORM, and various pure SQL drivers in Python (I've seen benchmarks of pure SQL being 2x faster than sqlalchemy in some case). Also, different implementations of Python, and various established distribution methods are beyond my current scope of knowledge, but tools such as Django are used to deploy sites/apps at absolutely massive scale, so I'm excited to learn. At this point, I (or clients) can simply pay Anvil to manage that work - they're capable of handling any imaginable scale that Anvil might possibly be put to use for (that's pretty cool, because it provides single developers the possibility of writing an app which can actually grow significantly, without having to know much at all about how to manage those requirements). I'd love to see how far my new little toolkit could actually be pushed eventually...

BTW, I'm curious how long these database requests take from your location: http://216.137.179.125:8080/repeating_panel?color=red&date=none http://216.137.179.125:8080/readgrid Those are pure back-end requests which code be used by any front end, delivered by my little toolkit, hosted on A2. If they're not as instant as any other sort of request for a few characters of static data from a typical shared host Apache server, then I need to change the WSGI server, or the hosting.

"I think you need to accept that performance of web apps from the other side of the world is different than nationally. It is dominated by how your software performs over the Internet, performance of your devices becomes a minor matter." That is incorrect in this situation. The fact is, responses to those servers requests are *consistently* delivered in a matter of milliseconds. The only additional delay you should experience in receiving them is the time it takes your client computer to generate the request, the time it takes for the request to travel from your location to the server, the time it takes the response to travel back to your machine, and the time it takes your machine to display the response data. I've already demonstrated that my software generates and sends the request at the client side, sends the result on the server side, and displays the result on the client side *instantly*, consistenyly. There's nothing more that can be improved as far as the performance of the software goes. The speed of light and the routing of those signals between your location and the server is out of my control. The performance of your machine is out of my control. Those back-end requests are consistently producing instant results on my server - there's nothing to be realistically improved (perhaps a few milliseconds, but that's not any significant part of the difference in performance you're experiencing). So, I have to insist that I don't need to "accept that performance of web apps from the other side of the world is different than nationally. It is dominated by how your software performs over the Internet". Every piece of my demo IS performing every bit as well as any other framework would, at least as far as you should be able to perceive a difference in performance. The way it can handle a load and handle 300,000 requests per second is another issue, but that's not the case here, and that would have more to do with load balancing and distributing work to multiple processors, syncing the availability of database results, using tools such as caches, etc. In this case there is *nothing inherent in the performance of my little toolkit which makes it perform any worse than the same demo written in Meta, or any other back end - not to the degree that you're seeing performance deteriorated. Everything about the server and client performance is fast enough that you shouldn't be able to perceive a difference between it and another system. If you could measure a difference in performance in milliseconds, the potential variations in travel time between client and server, due to distance, routing paths, etc., which are out of the scope of what the serve and client software can control, are likely greater than the differences in those potential performance improvements. Something else about your particular setup, on the client side, outside the performance of anything in my toolkit, is causing those delays. BTW, that's not entirely true for the Streamlit example - that toolkit IS slow and does take a few seconds to display client results - because it completely reloads the entire interface every time any request is sent - but even for the example you saw, that performance difference should be measured in perhaps a second, or maybe 3-4 at the most - not the delays you've experienced. Either way, that is not true of my simple toolkit - requests, responses, and the display of responses are all instant, as far as what can be perceived by humans. And my hosting isn't the problem - it's delivering those performance results. Everything else is due to third party infrastructure, routing, and device performance that is out of my control.

The only exception to that would be if you're able to control the routing and network configuration between the server and client, but again, that isn't limited by the language that runs on the server. None of the performance issues you're experience are a Python vs. Meta issue. It either has to do with the performance of your client machine, your network connection, or the performance of the front end interface in your browser (and that's not a matter of Python vs Meta either). The server responses are already blazingly fast, to the point of being perceived as instant, and can not be improved in any way that would make the app perform perceive-ably better.

... and when it comes to scaling to handle a tremendous traffic load, support for the tools in the Python ecosystem are already built, and deeply battle tested, to make that escalation happen as painlessly as possible.

I'm genuinely curious about what the cause of you performance delay is. The responses to those REST requests above are instant, no matter what sort of front end sends the request and displays the response. They can't be improved in any practical way. Nothing about any front end I'm using is slowing done the sending of those requests, or the display of the responses (and that doesn't really matter because it can be swapped out with any other front end interface). So where is the problem?

To be clear, you don't need to take part in this discussion if you don't have time or interest. Like I said, the system is performing fast, it doesn't need to be tweaked. I'm just curious about what is causing the delays in your situation. Those delays are not due to anything in my toolkit or anything else I can control, as far as I can tell. The server responses are instant - they can't really get faster in any way that would make any sort of practical difference.

For what it's worth, you should be able to read those REST URLs with your browser, Rebol, Meta, Curl, or a Python client, and the results should be instant, and delayed only by the speed of light + routing. If not, then there is something outside the software causing the delay. Perhaps the A2 environment is the problem, or perhaps the development WSGI server in Bottle, but as I've demonstrated, that doesn't seem to be the case...

Thanks for the server offer. I currently have a network of seven servers around the world, so I have enough testing opportunities. Your two test requests open near-instantly in Firefox, but they don't open in Brave. However, network app performance is not about single requests, it's about multiple requests that need to wait for each other. I guarantee you that the delays in your demos are linear with the number of roundtrips they make to the server that are waiting for each other. The best way to speed up work is always to make that work unnecessary. That's why I present reduction of complexity in Meta as a performance feature. Dependent roundtrips dwarve any other considerations in the design of network apps and need to be minimised.

I could eliminate CORS handling, and that would cut out a round trip, but that also has nothing to do with language.

I could eliminate CORS handling, and that would cut out a round trip, but that also has nothing to do with language, and is entirely controllable using my little tool kit.

That's just a matter of momentary convenience, all I need to do is serve the front end HTML file from Bottle, instead of from a process running on a different port.

It seems clear that Brave is enforcing CORS requirements in ways that are more strict that expected. I actually did include some stock code to handle 'OPTIONS' requests in some functions, but not in all. The fact that you received some network connection errors at one point using Brave indicates that it's certainly handling CORS requirements more strictly than the other browsers I've tried. So that's adding *at least* one additional round trip. Of course my HTML hosted on Hostpapa is then requiring at least one additional round trip, and even the HTML hosted on A2 is experience the same, because it's served on port 8000 and the Bottle code runs on port 8080. I'll just serve the HTML from Bottle - that should be a very simple fix. The instant response from those Get requests,using the other browser, is more indicative of the performance speed of this little toolkit. Thanks for the feedback, that's helpful!

I could write very fast web apps in Python, but where's the fun in that? ;-) If I have to write them from the ground up, anyway, because all those frameworks are sprinkled with way too many dependent roundtrips, I might as well do it right and throw in a REBOL language. The next consideration in performance, after the app has loaded, is how the client performs. Python doesn't run in browsers, and it's an interpreter, anyway. Meta does run in browsers, and it's compiled, much faster.

If you're spreading parts of your apps over different URL's, that's one sign of complexity to me. Even without knowing if it would cause any issues, I would avoid such constructs, unless there's a clear advantage to them. That's one of the reasons I want maximum control over my software.

I spread part of my demo app across different urls, exactly to uncover issues such as what was discovered here. There's no inherent complexity or need to do that. It was simply a convenience in the moment to upload HTML to that server, and my server code up to my A2 Hosting account. I'm glad to learn a little bit more about Brave browser, my whole point in using that silly old JSlinb front end was to continue testing it and using it in every available browser that I can come across. I'll look at brave, and also check to see how that framework is sending requests, especially how brave browser deals with CORD, there's clearly a difference there. There's nothing in any of this tooling I don't have maximum control over. It just saves me lots of work, and allows me to connect to the largest number of existing pieces in the modern computing ecosystem via libraries and apis that are supported healthily in Python and JavaScript. Web apps are going to have a front end and a back end, there's no sort of outrageous complexity in that arrangement. I just like my back end to be powerful and connected to a massive ecosystem, so I don't have to reinvent the wheel for every task I want to complete. That's eventually what killed Rebol for me. I couldn't make use of all the modern services, apis, and other existing tooling that's just sitting there and waiting to do amazing things, without having to write an enormous amount of code to do make connections, to have to build apis from the ground up, and in many cases there wasn't even any real way for Rebol to nicely connect to many tools. The biggest benefit I get from working with Python and JavaScript. By the way, Anvil does run python directly in the client side browser, using skulpt. That's one of the things that makes it so nice to use. There are no rest API calls, or conversions between data structures on the front end or back end. Your front end functions simply call back and functions, all in pure python, and all using python data structures.

Of course, Anvil does give you full access to Javascript in the client - I've built a video recording app using native MediaStream API calls in Javascript, and controlled the recording stop/start etc. with Anvil UI, and saved the recorded video directly back to the server side in Anvil - it's absolutely brilliant how effective and trouble free is it to do things like that in Anvil. I've integrated the Coppercude 3D engine (a JS engine) directly into my Anvil front end - again all controlled with Anvil UI - it took me one sitting to do that - dead simple! Anvil makes it easy to interact with all those JS functions *directly in Python*. There's nothing else I've ever worked with that's so nice to use, productive, effective, and which eliminates problems and lets me actually get real work done, without having to get bogged down with time consuming 'gotchas'. I'm constantly amazed at how every 'just works', with everything I try to get done with it. My projects that used to take days/weeks in Rebol, are often a single afternoon in Anvil. It's hard for me to find fault with the kind of consistent, reliable solutions it enables.

I originally was attracted to Streamlit because it's also a pure Python API, which actually goes a step further by removing the intellectual overhead of having to think about how data is transferred between front end and back end. Lots of people love it because the mental model is just so simple - building multi-user client-server apps feels like building single users apps that run locally - but its performance, lack of control, and other limitations make it pale dramatically in comparison Anvil's power, capability, and ease of use. It's just simple for non-developers to learn and use, and it really is practical for the data science community, because it natively integrates with Pandas and all the visualizations, as well as all the other machine learning, AI, etc. libraries. The goal of my little toolkit is to provide the most productive connection with the full Python and JS ecosystems, using the lightest possible server, DB, and UI layers in those ecosystems, without having any heavy or complex dependencies.

Skulpt is not really Python, it's a separate implementation. There are differences in the languages, mostly because it's incomplete. This means, for example, that you can not necessarily use all Python code in the browser. Anvil effectively uses two different languages on the server and client sides, adding to its complexity, and needs to integrate them. With Meta, you get the real thing everywhere, from Atari 2600 to the browser, and the same language on the client and the server.

They've used Skulpt to implement Python language and data structures for the purposes that are needed in the browser, and it works fantastically. It's limited to interacting with the objects that live in the front end UI, as it should be. You do front ends things in the front end, and back end things in the back end - (the back end is where the heavy lifting and all the ecosystem is available. The point isn't to make every bit of computing capable of being performed in the browser (that's the goal of pyscript - with many of the most common data science libraries ported to run entirely in the browser, and there's even an implementation of Streamlit which runs entirely in the browser - both of those projects are currently way to heavy to really useful in modern browsers, so they are silly now, but they could become more useful in the future). The benefit of Anvil's Python in the browser is that the language model and data structures are all the same as on the back end - you just call server functions on the front end - and it feels SO ergonomic and works beautifully (compared to any other mess in the web development landscape). Again, I can simply point to my *results* that have materialized from actually using Anvil, to demonstrate how effective it is. Anyone can be critical about something they don't like, but my productivity is through the roof, and I don't need to argue with anyone about how great it's been to use. With all that said, I fully back your goals, without reservation. Less complexity, better performance, more portability, control at every level, etc., is of course better than the alternatives (that's why I'm hoping to trim down to the smallest possible requirements with my little Python toolkit). I'd like nothing more than to see Meta be successful, and it's exciting to know you've got financial support now. I just need to get work done, and writing software has only ever been *part of my professional life, so I just need to be utterly productive when I write any code... My tools are suiting my current needs better than I ever expected would be possible, after being previously spoiled by Rebol's productivity, lack of complexity, etc. I'm just happy to find some tools that tick all my boxes dramatically well. You have many more boxes to tick, and it's great to see that you're able to thrive making that happen. ... I still want Meta for my 198s Tandy Pocket computer: http://pocket.free.fr/html/tandy/pc-2_e.html I still have one of those! And check this out - these machines were what really lit the fire in me about computing: https://antonaccio.net/mc10/IMG_20150816_084041.jpg https://antonaccio.net/mc10/IMG_20150816_084053.jpg https://antonaccio.net/mc10/IMG_20150816_090530.jpg https://antonaccio.net/mc10/IMG_20150816_090430.jpg

I followed with interest the discussion about Anvil, I played a bit with both the online application and the server installed on my computer. It seems interesting and promising, especially since it could be used for free (at least that's what I understood so far). I wonder if it is a long-term solution for the development of large applications. A few years from now, will there still be Anvil? Things change extremely quickly in the software world, all applications have dependencies and vulnerabilities, therefore they must be kept up to date. So, the local installation of Anvil would not save me from possible problems if those who develop it no longer take care of it. I ask myself these questions because for many years I have been developing an ERP application written in VFP even more years ago. I was lucky that until now VFP has worked on Windows, although it is no longer supported. Over time, I implemented functionalities in the application using various other tools: curl, winscp, ruby, nodejs, etc., but the base remained VFP (I have not yet found something comparable, with the same functionalities)

Iontab, I have the same doubts. And the higher the complexity, the larger the risks. In fact, all of society is now operating at a level of complexity that will be unsustainable in some societal crunch. Cool pictures, Nick. I'm open to funding to target Tandy pocket computers with Meta; although TRS-80 should be easier. ;-)

Iontab, ... meanwhile, a huge portion of the world is *actually running* on Python and JS, doing trillions of dollars of business, and developing AI that is changing everything about the potential capabilities of mankind, using tools in those ecosystems. If Anvil goes away, it will be because something better will evolve to replace it in these massive communities of hundreds of millions of users working competitively, with massive financial backing in a tumultuous, explosive commercial environment that requires successful outcomes with the tools that are commonly used. It's not realistic to question whether Python and JS are viable in our current environment - they are far and away the most used languages. But with that said, I think all of the tools we use at the moment will most likely be replaced in the very near future, with infrastructures that will evolve quickly to support AI driven development. If you're not following how that has evolved during the past months, it's moving at light speed. ChatGPT is already better at writing code than many experienced professionals. We're just experiencing the first glimmer of light at the dawn of this new era for mankind, and burying heads in the sand about what's already occurring (50% increases in productivity at companies where AI is used to write code, already, at this moment, and that will change *dramatically in the next couple years). In a few years, everything we're discussing about how software development works will be eclipsed by AI driven methodologies. The age of software written primarily by humans is very quickly coming to an end. Humans are mostly going to be needed to guide, test, and evaluate the effectiveness of AI training output, for our needs, in the *very near* future. Not many disciplines or businesses are really safe from sweeping changes that will be made by AI automation in the coming decade.

To be clear, Anvil is just the best tool that I've found, for my own requirements, to productively put to use and orchestrate the massive capabilities of existing and evolving libraries (video, 3D, machine learning, AI, etc.) and connectivity with established services (payment gateways, communications tools like Twilio, database services such as bit.io, machine learning environments such as hugging face, and AI apis such as those by OpenAI) and other tools that save developers the work of re-inventing the wheel for any given purpose, and enable the use of tools which no single develop can even begin to create in a lifetime. Replace Anvil with whatever toolkit makes more sense for your needs - Django has been around for nearly 2 decades - it's Python backend with web based front end that currently enables high level productivity. Anvil just does it in the most eloquent and productive way I've seen yet. But that productive advantage is very quickly being eclipsed by having AI write code - in whatever language you prefer. The paradigms and problems in software development are going through a massive transformation at the moment, and the next few years or going to rock the foundations of society.

Kaj, 'the higher the complexity, the larger the risks' - that's 100% true - and we're all about to be bulldozed by a level of complexity that humans won't be able to keep up with.

What I've been experiencing during the past few months with deep dives into using AI has been exhilarating and awesome, and the prospects are truly world changing and terrifying.

AI is so much more dramatically capable than it was last year (particularly OpenAI's implementations), and particularly at generating, evaluating, explaining, connecting, reasoning about, teaching, debugging, transforming, etc. code. Working with it properly, you can currently multiply productivity manyfold. What I've been particularly impressed by is it's ability to write code that orchestrates the interaction of multiple disparate tools, in ways that most experienced human developers can - simply by entering prompts with the conceptual meaning that describes the intended outcome. The already existing ability to work that way is transformative in ways that are hard to communicate with anyone who isn't using it to complete work.

Feed it error messages, and it explains what it happening to cause any errors, you can discuss with it the intended outcome, as you would with a human pair programmer, and it debugs your code and provides the working code you need - instantly. It can write 5000 lines of working code for you in a sitting. You can iterate with it, as you would with a human, ask it questions about how to accomplish whatever goal you sit down to achieve, and have it teach you exactly what you need to do to achieve your conceptual goal, while all the while writing and explaining every bit of actual working code you need to implement your intended outcome. You can ask for alternate solutions, and it will explain the options which had previously been unaware of, and provide working examples of their implementation, which you can then cycle through iterations and variations of. I'm learning to do months of work in days with it, and I wouldn't want to be using any tools/languages that it's not deeply trained in...

It does hallucinate sometimes, and get things wrong, but dealing with that is far and away more productive than sitting down to a blank page and using Google to search for, learn about, assimilate, experiment, and iterate through writing code in traditional ways.

Ignoring the use of AI tools at the moment, is probably the worst potential mistake any developer could currently make. That's clearly just an opinion, based on my own needs and perspective, but I expect that disagreement about that outlook is likely driven by lack of real experience using it. Here's 1 of hundreds of articles that may provide some genuine insight: https://dev.to/wesen/llms-will-fundamentally-change-software-engineering-3oj8

AI and many other things are not running on Python, that would be way too slow. Python is surfing on AI and other libraries, written in faster and safer languages. Most other languages can also do that. Meta is suitable for both binding to other libraries and implementing the core libraries themselves. Current AI is just regurgitating what it finds on the Internet written by humans, both good and bad examples. Of course it helps beginning and mid-level humans to be assisted by all other humans at once, but innovation still needs to be done by expert humans.

Nick, My doubt is about the framework/tool, and not about the language (Python or JS or anything else). I said that I have been maintaining and developing a large application for many years, with tens of thousands of lines of code. If the tool I use in development disappears, it will be very painful for me. Even if the language used is all JS, for example, it is not easy to switch from React to VueJS when you have thousands of lines of code behind you. I'm just trying to clarify my ideas and find viable long-term solutions, I have nothing against framework X or Y. And yes, AI is already changing the rules of the game.

Kaj, The human interfaces to those AI libraries is most often Python. I think everyone is aware that the hard work is done on a lower level. I'm interested in USING those capabilities, not dedicating my like to building one little microscopic piece of that environment. If you don't respect my perspective, I think you may be interested in and surprised by the article I linked.

I do respect your perspective, but there are definite limits to current AI. If AI is as smart as you claim, I look forward to it, because it will start choosing Meta over Python in a few years. :-)

Iontab, What's to stop you from learning a few frameworks? The Python/JS ecosystem is filled with great productive tools. Learn a mainstream Web framework for front end - take your pick from one of the most popular, use a popular backend such as Django or Flask, and an ORM. MUI or m3.material.io for front end, together with Flask and SQLAlchemy are good mainstream choices that can be mastered in a few months.

<a href="//archive.is/2023.03.08-154241/https://www.nytimes.com/2023/03/08/opinion/noam-chomsky-chatgpt-ai.html">archive.is/2023.03.08-154241/https://www.nytimes.com/2023/03/08/opinion/noam-chomsky-chatgpt-ai.html</a>

You can replace any piece of the Anvil framework however and whenever you see fit. Use it just a back end REST and database system, and replace the front end with any toolkit that can make REST request. Swap out the ORM for any other database system. Or just use the visual layout builder to connect with any other back end. Anvil is just an integrated environment that enables you to use the Python and JS ecosystems effectively. It's a work environment with browser based IDE, GIT integration, slick back end and front end language integration all in Python, etc., but there's no inherent vendor lock-in. You can use it just to prototype and swap out any layer of the system when design is complete. Learning to use a different UI layor, or a different ORM, or a different IDE, etc, can be done piecemeal, and none of those layers require any sort of massive learning curve to become productive with. You can begin to be build powerfully useful front ends with metro in a few days - or maybe take a look at MDB - any framework that encapsulates all the UI componentry that is needed for front end work. Choose the one that satisfies your needs, use different frameworks for different projects. With a base in generic Python and web UI, there are endless options which can be learned and used as needed. For me Python and (name a front end web framework - or use a visual builder if that suits your needs), is the core that will stick around. Porting from Anvil, and swapping out any piece of it has been relatively easy - at least compared to previous tool systems. I just love the productivity and workflow enabled by the entire integrated browser based IDE (with autocomplete and GIT), all-python, built-in database, email, Google, Stripe, PDF printing, drawing API, and all the other out of the box integrations in Anvil, hosting, etc. But every one of those things can be swapped out to use any other option in the Python and JS ecosystems, without any vendor lock in, if any part of the Anvil system doesn't suit your needs or if it becomes obsolete.

It's not the kind of lock-in that users of Rebol or Visual Fox Pro experienced. It's just Python and JS packaged nicely. There are endless existing alternative options to any piece of the Anvil environment, so the core of any work done in Anvil never needs to be abandoned.

Kaj, from the article: "However useful these programs may be in some narrow domains (they can be helpful in computer programming, for example, or in suggesting rhymes for light verse)" We're talking about the narrow domain of computer programming! I have a suspicion that Noam Chompsky hasn't spent the kind of time anyone reading this text may have, sitting to create a CRUD app for a client, to help run their business, and the dealt with the UX issues that come from supporting that software. I really doubt he's gone through the process of spending hours every day into deep in the night iterating though thousands of lines of code with ChatGTP, even to the degree I have. The link I posted is from a professional career developer who has written millions of lines of code over decade. I agree with much of what Noam Chompsky wrote in that philosophical article, but I think the link I posted is filled with real usable and productive, actionable information related to actually writing software in a complex real life environment, in a way that is more directly relevant to what we're interested in as productive human software developers.

Noam Chomsky is one of the founders of our field. I wouldn't accuse him of lack of experience. If all parts of Anvil are so replacable, why not replace Python with Meta? Is there anything that makes you think Meta won't be usable by AI?

In the article, Noam Chomsky was just addressing the topic of what AI currently isn't good at, and the value of human capability. He acknowledged that AI is good at writing code. I throw no shade at him whatsoever, just don't think he's likely grinding away at building CRUD apps, the same way most working commercial developers spend a huge portion of their career, and he most likely hasn't spent the last couple months using ChapGPT to write glue code and evaluate which combinations of frameworks are best used for the next project the marketing department needs completed by Friday. That's in no way an indictment of any lack of other experience. I look forward to when I can replace Python with Meta. It's not an urgent need, but I would love to see that happen :) There's nothing inherent in Meta that won't be usable by AI, it simply hasn't been trained in billions of lines of existing Meta code, the way it has been with Python, JS, C#, C++, SQL, etc.

That's a matter of time, and since AI accelerates things, it could happen quite fast. At least AI doesn't have the strong inertia of humans. The article you linked is quite useful, and confirms some of my hunches from reading up on generative AI the last few months. It seems to me that Meta both competes with generative AI and can facilitate it. The programmers who are enthusiastic about AI use it to make it generate lots of code based on a mere few hints. In REBOL, we have had that for a quarter century and call it a dialect. But where the execution of a dialect is automatic and deterministic, all code generated by AI needs to be checked by an expert human at every generation cycle. Further, the least complex way to execute a dialect is to interpret it. Generating other code from it is a huge complexity bomb. Meta only does it to 100-fold performance. Another oddity is that everyone makes AI generate programs in existing languages, which are created by humans. Noone makes it generate machine code, so AI is still heavily dependent on human creations. That being the case, Meta can infer the same advantages on AI as it can on human programmers. All of Meta's advantages apply to AI, as well.

Yep, it's interesting that I haven't seen anyone talk about generating machine code. It's funny, I was originally attracted to Rebol because I was searching for work that had been done on converting natural language to working code. There are a chasm of differences between working with dialects and using AI. The biggest is that you can interact with AI iteratively, asking it to demonstrate potential solutions, ask it to perform variations, request help in complex conceptual ways, and learn from it while guiding it to teach you about what to search for. You can begin a project, for example, by asking it to outline some suggested approaches to complete the project. You could then, for example, ask it to suggest any libraries which can help accomplish some part of a task, and if one sounds interesting, ask it to generate some code, using that library to perform a particular task, ask it to explain any piece of the code, ask it for alternative ways to complete the same task, write some come from what you've learning, ask it to debug and improve your code, and deal with it as if you have an all-knowing pair programming partner who knows more about everything in an any ecosystem than any single person could ever learn in a lifetime, and provide suggestions which aren't colored by a single person's limited ability to learn about and use just a limited number of favorite tools. It does most of those sorts of things instantly, and already better than most experienced professional can.

You could train an open source project such a Llama to learn Meta.

Your first 5 minutes with ChatGPT: Why is this Rebol code not working: random/seed now g: [style t box red [ if not find [0x108 108x0 0x-108 -108x0] face/offset - e/offset [exit] x: face/offset face/offset: ef/offset e/offset: x ] across] x: random repeat i 15 [append x:[] i] repeat i 15 [ repend g ['t mold x/:i random white] if find[4 8 12] i [append g 'return] ] append g [e: box] view layout g ChatGPT The code you provided has a syntax error in the second line. ef/offset should be e/offset. Here's the corrected code: random/seed now g: [style t box red [ if not find [0x108 108x0 0x-108 -108x0] face/offset - e/offset [exit] x: face/offset face/offset: e/offset e/offset: x ] across] x: random repeat i 15 [append x:[] i] repeat i 15 [ repend g ['t mold x/:i random white] if find [4 8 12] i [append g 'return] ] append g [e: box] view layout g This code generates a grid of 15x15 colored boxes, which change position when clicked. The g variable is a block of GUI objects that define the grid layout, while the x variable is a block of numbers used to determine the initial color of each box. The random/seed now line sets the seed for the random number generator, ensuring that the same sequence of random numbers is generated each time the script is run. The style function defines a style for the boxes, which are instances of the box function. The repeat and repend functions are used to fill in the initial colors of the boxes, while the if statement checks whether the box has been moved to a valid position. Finally, the append function adds a box to the end of the g block, and the view function displays the grid as a graphical user interface. Please generate the pydal code to create an sqlite database with a 1 table, with columns "name" and "birthday". Create a function to insert new rows, and a function to search for rows containing a given name. ChatGPT Sure, here's the PyDAL code to create an SQLite database with a single table named "people", with columns "name" and "birthday": from datetime import datetime from pydal import DAL, Field db = DAL('sqlite://mydatabase.db') db.define_table('people', Field('name', 'string'), Field('birthday', 'date')) To insert new rows into the "people" table, you can create a function like this: def add_person(name, birthday): db.people.insert(name=name, birthday=birthday) This function takes two arguments, the name and birthday of the person to be added, and inserts a new row into the "people" table. To search for rows containing a given name, you can create a function like this: def search_by_name(name): results = db(db.people.name.contains(name)).select() return results This function takes a name argument and searches the "people" table for rows containing that name using the contains() method. It then returns the results as a Rows object, which you can iterate over to access individual rows. Note that you'll need to adjust the SQLite connection string to reflect the path and filename of your SQLite database file. Also, make sure to import the datetime module if you want to use the date field type in your table. User Please integrate that code into Python Bottle, so that the add_person() and search_by_name() functions run at routes of the same name ChatGPT Certainly! Here's an example of how you can integrate the PyDAL code I provided earlier into a Python Bottle web application: from bottle import Bottle, request from datetime import datetime from pydal import DAL, Field # Create a new Bottle app app = Bottle() # Connect to the SQLite database using PyDAL db = DAL('sqlite://mydatabase.db') # Define a "people" table with "name" and "birthday" columns db.define_table('people', Field('name', 'string'), Field('birthday', 'date')) # Define a route for adding a new person to the database @app.route('/add_person', method='POST') def add_person(): name = request.forms.get('name') birthday = datetime.strptime(request.forms.get('birthday'), '%Y-%m-%d').date() db.people.insert(name=name, birthday=birthday) return f"Added {name} with birthday {birthday}" # Define a route for searching for people by name @app.route('/search_by_name', method='GET') def search_by_name(): name = request.query.name results = db(db.people.name.contains(name)).select() return f"Results: {results}" # Run the app on port 8080 app.run(host='localhost', port=8080) In this example, we're using the Bottle web framework to define two routes for adding new people to the database (/add_person) and searching for people by name (/search_by_name). Both routes call the add_person() and search_by_name() functions that we defined earlier, passing in the request data (in the case of /add_person) or the query parameter (in the case of /search_by_name). Note that we're using the strptime() method from the datetime module to convert the birthday string from the request data into a date object that can be stored in the database. Also, make sure to adjust the SQLite connection string to reflect the path and filename of your SQLite database file. And don't forget to import the bottle module at the beginning of your script. I'd like to make the bottle server restart every time the source file is edited ChatGPT To make the Bottle server restart every time the source file is edited, you can use a Python package called watchdog. Here's an example of how you can modify the previous code to use watchdog: python Copy code from bottle import Bottle, request from datetime import datetime from pydal import DAL, Field from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler import os # Create a new Bottle app app = Bottle() # Connect to the SQLite database using PyDAL db = DAL('sqlite://mydatabase.db') # Define a "people" table with "name" and "birthday" columns db.define_table('people', Field('name', 'string'), Field('birthday', 'date')) # Define a route for adding a new person to the database @app.route('/add_person', method='POST') def add_person(): name = request.forms.get('name') birthday = datetime.strptime(request.forms.get('birthday'), '%Y-%m-%d').date() db.people.insert(name=name, birthday=birthday) return f"Added {name} with birthday {birthday}" # Define a route for searching for people by name @app.route('/search_by_name', method='GET') def search_by_name(): name = request.query.name results = db(db.people.name.contains(name)).select() return f"Results: {results}" # Define a watchdog event handler to restart the server when the source file is modified class WatchdogHandler(FileSystemEventHandler): def on_modified(self, event): if event.src_path == os.path.abspath(__file__): print("Restarting server...") observer.stop() observer.join() os.execv(__file__, sys.argv) # Set up a watchdog observer to monitor the source file for changes event_handler = WatchdogHandler() observer = Observer() observer.schedule(event_handler, path='.', recursive=False) observer.start() # Run the app on port 8080 app.run(host='localhost', port=8080) In this modified code, we're using the watchdog package to monitor the source file for changes. We define a WatchdogHandler class that subclasses FileSystemEventHandler and overrides the on_modified() method to restart the server when the source file is modified. We create an instance of this class and use it to set up a watchdog observer that monitors the current directory for changes. When the source file is modified, the on_modified() method of the WatchdogHandler class is called, and if the modified file is the source file itself (__file__), the observer is stopped and joined, and the server is restarted using the os.execv() method. Note that this code assumes that the source file is located in the current directory ('.'). If your source file is located in a different directory, you'll need to adjust the path argument of the observer.schedule() method accordingly. is there an easier way to achieve that? ChatGPT Yes, there is an easier way to achieve auto-reloading of the Bottle server when the source code is edited, without using watchdog. You can use the reloader=True option when calling the run() method of your Bottle app, like this: from bottle import Bottle, request from datetime import datetime from pydal import DAL, Field # Create a new Bottle app app = Bottle() # Connect to the SQLite database using PyDAL db = DAL('sqlite://mydatabase.db') # Define a "people" table with "name" and "birthday" columns db.define_table('people', Field('name', 'string'), Field('birthday', 'date')) # Define a route for adding a new person to the database @app.route('/add_person', method='POST') def add_person(): name = request.forms.get('name') birthday = datetime.strptime(request.forms.get('birthday'), '%Y-%m-%d').date() db.people.insert(name=name, birthday=birthday) return f"Added {name} with birthday {birthday}" # Define a route for searching for people by name @app.route('/search_by_name', method='GET') def search_by_name(): name = request.query.name results = db(db.people.name.contains(name)).select() return f"Results: {results}" # Run the app on port 8080, with auto-reloading enabled if __name__ == '__main__': app.run(host='localhost', port=8080, reloader=True) When you run this code using the Python interpreter (python app.py), the Bottle server will start on port 8080, with auto-reloading enabled. This means that the server will automatically restart every time you modify the source code. Note that you should only use the reloader=True option during development, as it can have performance implications in production environments. Also, make sure that you only call the run() method when the script is executed directly (i.e., if __name__ == '__main__':), to avoid starting the server multiple times in a single script. Please convert this example to run in Flask: from bottle import Bottle, request from datetime import datetime from pydal import DAL, Field from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler import os # Create a new Bottle app app = Bottle() # Connect to the SQLite database using PyDAL db = DAL('sqlite://mydatabase.db') # Define a "people" table with "name" and "birthday" columns db.define_table('people', Field('name', 'string'), Field('birthday', 'date')) # Define a route for adding a new person to the database @app.route('/add_person', method='POST') def add_person(): name = request.forms.get('name') birthday = datetime.strptime(request.forms.get('birthday'), '%Y-%m-%d').date() db.people.insert(name=name, birthday=birthday) return f"Added {name} with birthday {birthday}" # Define a route for searching for people by name @app.route('/search_by_name', method='GET') def search_by_name(): name = request.query.name results = db(db.people.name.contains(name)).select() return f"Results: {results}" # Define a watchdog event handler to restart the server when the source file is modified class WatchdogHandler(FileSystemEventHandler): def on_modified(self, event): if event.src_path == os.path.abspath(__file__): print("Restarting server...") observer.stop() observer.join() os.execv(__file__, sys.argv) # Set up a watchdog observer to monitor the source file for changes event_handler = WatchdogHandler() observer = Observer() observer.schedule(event_handler, path='.', recursive=False) observer.start() # Run the app on port 8080 app.run(host='localhost', port=8080) ChatGPT Sure, here's the equivalent Flask code: from flask import Flask, request from datetime import datetime from pydal import DAL, Field from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler import os # Create a new Flask app app = Flask(__name__) # Connect to the SQLite database using PyDAL db = DAL('sqlite://mydatabase.db') # Define a "people" table with "name" and "birthday" columns db.define_table('people', Field('name', 'string'), Field('birthday', 'date')) # Define a route for adding a new person to the database @app.route('/add_person', methods=['POST']) def add_person(): name = request.form.get('name') birthday = datetime.strptime(request.form.get('birthday'), '%Y-%m-%d').date() db.people.insert(name=name, birthday=birthday) return f"Added {name} with birthday {birthday}" # Define a route for searching for people by name @app.route('/search_by_name', methods=['GET']) def search_by_name(): name = request.args.get('name') results = db(db.people.name.contains(name)).select() return f"Results: {results}" # Define a watchdog event handler to restart the server when the source file is modified class WatchdogHandler(FileSystemEventHandler): def on_modified(self, event): if event.src_path == os.path.abspath(__file__): print("Restarting server...") observer.stop() observer.join() os.execv(__file__, sys.argv) # Set up a watchdog observer to monitor the source file for changes event_handler = WatchdogHandler() observer = Observer() observer.schedule(event_handler, path='.', recursive=False) observer.start() # Run the app on port 8080 if __name__ == '__main__': app.run(host='localhost', port=8080, debug=True) The Flask version of the code is almost identical to the Bottle version, with a few minor differences in syntax and naming conventions. For example, Flask uses Flask instead of Bottle to create a new app instance, and the route() decorator takes a methods argument instead of a method argument. Additionally, Flask uses request.form.get() instead of request.forms.get() to access form data in POST requests, and request.args.get() instead of request.query.get() to access query parameters in GET requests. Note that you should only call the run() method when the script is executed directly (i.e., if __name__ == '__main__':), to avoid starting the server multiple times in a single script. Please suggest and alternative to using pydal, which can connect to oracle ChatGPT An alternative to PyDAL for connecting to Oracle databases is the cx_Oracle library, which is a Python extension module that enables access to Oracle databases. cx_Oracle provides a Python DB API 2.0-compliant interface for connecting to Oracle databases and executing SQL statements. Here's an example of how to use cx_Oracle to connect to an Oracle database, create a table, and insert data into it: python Copy code import cx_Oracle # Connect to the Oracle database dsn = cx_Oracle.makedsn('hostname', port, service_name='service_name') conn = cx_Oracle.connect(user='username', password='password', dsn=dsn) # Create a new table cur = conn.cursor() cur.execute("CREATE TABLE people (name VARCHAR2(50), birthday DATE)") # Insert data into the table cur.execute("INSERT INTO people (name, birthday) VALUES (:name, :birthday)", {'name': 'John Smith', 'birthday': '1980-01-01'}) # Commit the changes conn.commit() # Close the connection conn.close() In this example, we first create a connection to the Oracle database using cx_Oracle.connect(), passing in the necessary connection parameters such as the hostname, port, service name, username, and password. We then create a new table using cur.execute(), which creates a cursor and executes the SQL statement. We insert data into the table using a parameterized SQL statement, which helps prevent SQL injection attacks. Finally, we commit the changes and close the connection using conn.commit() and conn.close(). cx_Oracle provides many other features and options for working with Oracle databases, such as support for PL/SQL procedures, query optimization, and error handling. You can find more information about cx_Oracle in the official documentation: https://cx-oracle.readthedocs.io/en/latest/index.html Please recommend some additional ORM instead, which can connect to oracle, mysql, and postgres ChatGPT One popular ORM that can connect to Oracle, MySQL, and PostgreSQL is SQLAlchemy. SQLAlchemy is a Python library that provides a set of high-level tools for working with relational databases, including a SQL expression language, an object-relational mapper (ORM), and support for multiple database backends. Here's an example of how to use SQLAlchemy to connect to a MySQL database, create a table, and insert data into it: from sqlalchemy import create_engine, Column, Integer, String, Date from sqlalchemy.ext.declarative import declarative_base from sqlalchemy.orm import sessionmaker from datetime import date # Connect to the MySQL database engine = create_engine('mysql+mysqldb://username:password@hostname:port/database') Session = sessionmaker(bind=engine) Base = declarative_base() # Define a "Person" table using SQLAlchemy's declarative syntax class Person(Base): __tablename__ = 'people' id = Column(Integer, primary_key=True) name = Column(String(50)) birthday = Column(Date) # Create the "Person" table in the database Base.metadata.create_all(engine) # Insert data into the "Person" table using a session session = Session() person = Person(name='John Smith', birthday=date(1980, 1, 1)) session.add(person) session.commit() # Close the session session.close() In this example, we first create an engine object using create_engine(), passing in the necessary connection parameters for the MySQL database. We then define a Person class using SQLAlchemy's declarative syntax, which maps to the people table in the database. We create the table in the database using Base.metadata.create_all(). We insert data into the table using a session object, which we create using Session(). Finally, we commit the changes and close the session using session.commit() and session.close(). To connect to an Oracle or PostgreSQL database, you can simply change the connection string in create_engine() to use the appropriate database backend. SQLAlchemy provides a consistent API for working with different database backends, so you can use the same code to interact with multiple databases. You can find more information about SQLAlchemy in the official documentation: https://docs.sqlalchemy.org/en/14/ Please convert the final pydal and bottle example above to use sqlalchemy instead of pydal ChatGPT Sure, here's the updated code that uses SQLAlchemy instead of PyDAL: python Copy code from flask import Flask, request from datetime import datetime from sqlalchemy import create_engine, Column, Integer, String, Date from sqlalchemy.orm import sessionmaker from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler import os # Create a new Flask app app = Flask(__name__) # Connect to the SQLite database using SQLAlchemy engine = create_engine('sqlite:///mydatabase.db') Session = sessionmaker(bind=engine) # Define a "Person" table using SQLAlchemy's declarative syntax class Person(Base): __tablename__ = 'people' id = Column(Integer, primary_key=True) name = Column(String(50)) birthday = Column(Date) # Create the "Person" table in the database Base.metadata.create_all(engine) # Define a route for adding a new person to the database @app.route('/add_person', methods=['POST']) def add_person(): session = Session() name = request.form.get('name') birthday = datetime.strptime(request.form.get('birthday'), '%Y-%m-%d').date() person = Person(name=name, birthday=birthday) session.add(person) session.commit() session.close() return f"Added {name} with birthday {birthday}" # Define a route for searching for people by name @app.route('/search_by_name', methods=['GET']) def search_by_name(): session = Session() name = request.args.get('name') results = session.query(Person).filter(Person.name.contains(name)).all() session.close() return f"Results: {results}" # Define a watchdog event handler to restart the server when the source file is modified class WatchdogHandler(FileSystemEventHandler): def on_modified(self, event): if event.src_path == os.path.abspath(__file__): print("Restarting server...") observer.stop() observer.join() os.execv(__file__, sys.argv) # Set up a watchdog observer to monitor the source file for changes event_handler = WatchdogHandler() observer = Observer() observer.schedule(event_handler, path='.', recursive=False) observer.start() # Run the app on port 8080 if __name__ == '__main__': app.run(host='localhost', port=8080, debug=True) In this updated code, we first create an SQLAlchemy engine using create_engine(), passing in the appropriate connection string for the SQLite database. We then define a Person class using SQLAlchemy's declarative syntax, which maps to the people table in the database. We create the table in the database using Base.metadata.create_all(). We insert data into the table using an SQLAlchemy session object, which we create using Session(). Finally, we query the data from the table using session.query(), and filter the results using filter(). Note that we have to define Base and metadata before defining the Person class, as SQLAlchemy requires this to work properly. Also, we have to change the syntax of the filter() call to match SQLAlchemy's syntax. Of course those are baby steps - it's MUCH more capable.

Kaj, Maybe take a look at this: https://www.businesswire.com/news/home/20230504005419/en/ServiceNow-and-Hugging-Face-release-StarCoder-one-of-the-world%E2%80%99s-most-responsibly-developed-and-strongest-performing-open-access-large-language-model-for-code-generation

Thanks for the link. Your example session is both impressive and awkward. Many of those queries would not be needed if there weren't so much sprawl in modern software and documentation. In that sense, generative AI is just the next step to keep heads just above water while exploding the mess further, instead of cleaning it up. That said, REBOL was successful as a clean platform, but then failed because it refused in many ways to collaborate with other, upcoming forces. Meta is designed to collaborate just like, or even more than other languages, while shrinking the mess.

I imagine that using AI to generate machine language will likely be more common in the future. As it can easily explain any code, generate test suites, instantly port code between platforms, etc., there's not the same need for the intermediate step of using any human readable language.

I don't think so. The human-readable level is essential, because AI functions as a pair programmer. It's both all-knowing and not-understanding, so it's essential that it works together with a human. I don't see any reason why competition for the most human-readable and efficient language would stop. It's similar to REBOL/Meta as a data format. Even if you need to communicate with other systems in other formats, you still need internal data formats for your programs, and REBOL is the most effective, while Meta will also make it the most efficient.

Last year, GPT made news because it was able to pass the SAT and the Bar exams - but only in the 10th percentile. *Now it can pass those exams consistently in the 90th percentile. Next year it will be able to best any human taking the tests. Add such rapidly improving AI to robots that can walk and perform the same fine motor skills as humans, and we have a fast-changing environment for humans. One of the potential problems with the astoundingly quick improvement of AI capabilities is that in the near future, human work will be devalued in virtually *every discipline, to the point that the economic foundations of our civilization evaporate. When computers can perform most useful tasks better, faster, and cheaper than humans, members of human society will no longer be paid to do that work. How does a capitalistic society survive when the overwhelming majority of members can't do work that is valuable to others? And of course there's the fact that a portion of human will always be evil. How do we oversee AI so that some rich person who hates American values, for example, doesn't build and deploy 10 million trained killer drones with guns with the instructions 'kill everyone in America'. That sort of production can't be overseen in the same way that nukes can. Of course, maybe this development will lead to utopia, and everyone will just be so happy with a work-free environment filled with amazing joys, that we'll all finally just be nice to one another :) ... I'm less than optimistic that that will be the end result :(

As long as it is adamant that RANDOM/SEED NOW serves to generate a fixed random series, I am not convinced. In my youth, many articles claimed that the big problem of the future was exactly that: that we would be automated away and out of work. Now, in the real future, we are inundated with work created by computers. AI is going to explode that and claim any fragment of free time we have left.

In response to acting as a pair-programmer, the big difference with AI is that the need for human understanding can be replaced by an infrastructure of tools that evaluate, test, and explain generated machine code - any other workflows that have been utterly unimaginable until now. The bigger difference is that such a system can be made usable by humans who have absolutely no training whatsoever - basically everyone. We have to face that job disruption from AI will be tremendous, and that new forms of societal structure will evolve, from these current blazing fast developments. I agree with Sundar Pichai that AI is "more profound than fire or electricity or anything that we’ve done in the past".

Wishful thinking, Sundar has a lot of money riding on that wish. Beam him back to before fire and he will reconsider. As Noam Chomsky says, current AI is not capable of that.

I think this essay by Bill Gates is an informative and balanced overview of the current and potential future state of AI: https://www.weforum.org/agenda/2023/03/heres-what-the-age-of-ai-means-for-the-world-according-to-bill-gates/

I stopped listening to Bill a long time ago. The only way his wishful futures come true is if he can get the majority to follow him. I prefer different futures.

As much as Noam Chomsky may have influenced the creation of computer programming language structure, I think the expert opinion of the likes of Bill Gates, Sundar Pachai, and much more importantly, people such as Geoffrey Hinton hold a bit more water about the current state of AI. Here's a relevant article by the New York Times: https://www.nytimes.com/2023/05/01/technology/ai-google-chatbot-engineer-quits-hinton.html

Right, Hinton is one of the considerable number of scientists warning against current AI, so taking it with a grain of salt is the least you can do. While it's true that generative AI is the revenge of Clippy, you always have to remember that Bill's assessment of the here and now as its greatest expert is that Windows has zero bugs, and his prediction of the future is that 640 KB ought to be enough for everyone.

Discounting the disruptive potential of AI feels similar to the Rebol community insisting that getting Rebol running on mobile platforms in 2007 was not of any interest. But that comparison is trivial. Head in the sand about AI eliminating the software development industry as it currently exists is similar the horse industry insisting that it would continue to exist alongside the auto industry as a primary mode of transportation in the early 1900s. We're about to see the tech industry paved over by AI.

Clearly, I'm not saying I like the fact that that's happening - it's clear that this development is going to have tremendously bad side effects. It's just going to be hard to beat, in the same way that the freakin iPhone was the model that so many humans chose to use, and how that disrupted the industry. Humanity makes bad choices.

It's not that black and white. I'm not at all discounting the disruptive potential of AI. But there are many sides to it, and one is that it's just the next in a long series of disruptive changes, which basically always turn out differently than expected.

With that said, I think that developments like Meta ARE positive forces that can improve our condition. When society burns itself down, humans may potentially go back to riding horses - and maybe then we'll learn to build back our world in more reasonable and sustainable ways... if we survive.

I hope that the Meta horse can survive this crazy race :)

I'm well prepared. I master fire and electricity and can ride a horse. I make my own water and my own programming language. Meta is developed on solar power. We'll see.

Do your thing man, I'm watching hopefully :)

Perhaps fine tuning an LLM to work with Meta provides the opportunity for a competitive marketing message, even if you consider it a counterproductive gimmick: https://thenewstack.io/why-open-source-developers-are-using-llama-metas-ai-model/

Thanks.

https://analyticsindiamag.com/uc-berkeley-release-an-open-source-alternative-to-metas-llama/

https://analyticsindiamag.com/14-open-source-llms-you-need-to-know/

Sprawl and information overload already, but thanks. :-S

Best thing to remember is GIGO, Garbage In -> Garbage Out. The more stuff you throw in, the more low quality stuff there is included. Like the crowd growing dumber when it is growing bigger, otoh predictions of sportsmatches made by many people tend to be pretty decent LoL! But what I wanted to point out, the way to fight GPT's is to create many bogey repos.

AI ranks stuff by popularity. If popularity converges towards quality over time, AI will converge to Meta. :-)

Popularity ordinarily does not seem to behave in any logical sense

Arnold, That's obviously true. Many of the world's inhabitants think Eric Clapton is the best guitarist who ever lived :) Still, there are benefits to working with systems that have been fully evolved, tested, and used by popularly by 10s of millions of people, so that they work productively, stably, and reliably in our modern world. Python and Anvil, as I've worked with them, for example, is far more stable and usable towards the productive ends I require, than Rebol ever was. If I wanted to go to extremes, I could choose to say, well computers just aren't naturally necessary, and they require a level of complexity that is not required for healthy human survival, and happy existence - so maybe it's better to just eliminate that complexity altogether and just farm land and write on stone tablets, and electronics and computers are just pointless trappings of stupid modern popular trends in society, technology, etc. Or maybe it would be great if we could restructure society so that all of our work could be done in cities which require only bicycles to travel, and solar power ... but wait, then how would we mine/distribute the metal and materials needed to build bicycles and solar panels. The world is obviously a massively complex mess, and most humans are impossibly stupid. But there are truly great and valuable achievements that arise out of all the chaos driven by stupid popular trends. Navigating intelligent and productive channels through existing messy infrastructure is a huge challenge, but I don't think disregarding every bit of good work that exists within every messy ecosystem is the best way to live, at least with the constraints and values that exist in my life, to find a positive outcome and thoroughly satisfying path. There are jewels that get formed in the pressure of those enormously messy pressurized ecosystems, and incredibly intelligent people working in every environment. I'm very happy with the architecture of my current life, including the tech tools that I use, to be massively productive and successful at achieving the goals that are important to me - which include doing all the things I like, and having the time and resources that I need to enable the lifestyle that's most satisfying to me. I'm not willing to give all that up to materialize a pure technical computing vision that is outside the scope of what I can achieve. I respect Kaj for his ability to maintain that focus and to work realistically toward that vision, but I always continue to explore and embrace the amazingly engineered and productively useful gems of technology that exist in any ecosystem.

For many years, Rebol was the best embodiment of a tool I could find which satisfied my productivity end goals, but coming from that experience, that's no longer the case.

I don't have the skills, background, time, or opportunity to change the underpinnings of how the future ecology of all computing, programming languages, etc., might potentially be able to improve, in terms of eliminating complexity, the way Carl had hoped to accomplish, and the way Kaj still does hope to accomplish. I do have 40+ years of using computing platforms and hundreds of software development tools in many ecosystems - Rebol included (and of course previously favored). What I *can say for sure, for example, is that I could build a replacement for this forum software in a matter of minutes, instead of hours or days, and with far greater facility, convenience during each step of development and deployment, and the ability to include a massive array additional useful features, in a way that would look and function better, and be more secure, etc. on 99% of the devices, for 99% of the users that would ever want to use such an app, and with the ability to scale traffic to 100s of millions of users, with either just a few hours work or a trivial amount of money (compared to that sort of scaled use case). That wasn't true before Rebol, but it is now, with Anvil. And the truth is, it would likely be far more stable in production than anything that existing in Rebol's life, particularly it has been tested and used in environments in which millions or uneducated users do everything possible to break it. The massive use and adoption of popular tools, as complex as they are under the hood, leads to far less complexity during every step of development, deployment, maintenance and support, for me the developer.

The idea that those systems are somehow otherwise unruly or prone to come crashing down just isn't the reality I live in.

A common thought I've been hoping to communicate in this thread is that the tools I've been using are just the opposite: beautifully engineered, tested, reliable, pleasant to use, productive, massively capable in simple ways I had hoped Rebol would have eventually come to embody. These aren't hopes, they're my current reality.

It's not about compexity itself, it's about essential versus accidental complexity, and identifying accidental complexity as the waste it is: <a href="//language.metaproject.frl#muda">language.metaproject.frl#muda</a> It's not a purely technical vision, it's very much a vision about society and its future, but it's about technology, so instead of just philosophising, there needs to be a technical vision to achieve anything.

In all of history, it has always been the case that the dominance of an incumbent doesn't matter in the long run. What defines the outcome are relative growth rates. Meta's goal is not to be bigger than Python and Anvil, but to grow faster.

In all of history, entire infrastructure systems, communities, and their surrounding ecosystems have tended to be replaced by evolving generations of community who use completely new tech/ecosystems. Getting stuck trying to perfect the early steam engine wasn't the path toward our current level of technological evolution. I see our current technological state as just a moment along an eventual future evolutionary path, and I don't expect the historical approach to computer system architecture, programming language design or related tools will play as important a part of that future technology. Trying to perfect old approaches *could* potentially end up being an exercise in futility, as entirely new, more efficient, and more powerful generations of technology are devised, built, and perfected by armies of imperfect scientists, developers, business people, etc., all using the imperfect tools and technologies of today to build the new classes of future tools. Python and JS are both *currently bigger, and growing faster than Meta (by an outrageous, incomparable degree). I'd love to see that change - of course I do see and embrace the benefit of such an improvement to the foundations upon which future tech will be built (and I encourage and would like to support that end goal) - but until there's a convincing reason to *use some other tech tools for my own work that leads to future benefit in the natural world encompassed by my sphere of influence, it's impossible to make such a switch in my own production tooling - and expect there are many people like me, who are searching desperately for such useful tools to use right now. The Python and JS tools I currently use are not failing in any way, they're not too slow for any of my users, or characterized as anything but an absolute pleasure to use. They're productive, stable, secure powerhouses - plus, they *enable the initial ability to take part in using of all the most cutting edge implementations of new technology tools which are paving the way to better, totally ground-breaking generations of entirely new tech (currently AI). If/when something comes along that can improve that situation, then that's fantastic, but my interests are not affected by *potential problems and improvements that don't require solutions in my scope of life. I don't experience any downside from the troubles that are magnified in the experiences of a system engineer. I'm not a system engineer - I'm a tech user and an entrepreneur (who prefers to use better and more powerful/malleable tech than the overwhelming majority of humanity limits itself to using). My experience *would be significantly disabled by having to give up all the connectivity with new tools, community and commercial support and established infrastructure, vast seas of libraries that save work, etc., which are enabled in the Python and JS ecosystems, and particularly with the extraordinarily productive tools within those ecosystems that I've searched out and which I currently use. I deeply appreciate the work of every system engineer, scientist, etc. who has created a piece of any tool that I currently use, but I'm not currently a person who has the opportunity to work at solving those sorts of problems. I just think there are many more people like me, who could use the class of tools that I currently advocate.

REBOL as a language design is not a steam engine. Perhaps its implementation is, hence why Meta has a completely different implementation. By the way, Pyhon has much the same implementation as REBOL. I consider both its language design and implementation outdated. Your statements about the relative growth rates of Meta and Python are baseless: you have don't have any information about Meta's growth rate. I'm not sure why you keep telling us that you are not motivated to spend an effort on Meta. This is not asked of you, I and others are doing it. Obviously, any project including Meta is not meant for people who vehemently don't want to use it, it's meant for people who would consider using it.

This particular thread is about 'What I'm using now instead of Rebol', not about Meta. Any comments I've made about Meta are simply responses to what's been said about how the tools I'm describing are somehow deficient in comparison to Meta, or how they're otherwise lacking - and those statements simply miss the point, in my experience. The tools I started this thread to discuss work fantastically well for my purposes, and for a massive community of others. I've only hoped to clarify and support that point, based upon my actual real-life experiences, throughout this thread. I've said nothing to the effect of not being motivated to spend effort on Meta - in fact I've been clear that I'm excited to see it continue to develop, that I would love to see it become successful, that I'd be happy to help test, and even offered server resources if they'd be useful. I've also said that we have different perspectives about the purposes of the tools we're interested in. In this thread, I've intended to talk about the value of 'What I'm using now instead of Rebol'. If that means responding to comparisons and contrasts with other tools, or with statements specifically about the tools I'm using (especially when those statement aren't coming from the perspective of deep experience using those tools), then I'll engage in that conversation. Although that's not my purpose in discussing this topic, I do appreciate hearing and reacting to other perspectives. Just because someone's needs are different than mine doesn't mean I consider that perspective lacking in value - I've just continued to focus on 'What I'm using now instead of Rebol' in this thread. The growth rates of Python and Javascript during the past few years have led to them occupying leading positions among the most popular programming languages on the planet. The statement that 'Python and JS are both *currently bigger, and growing faster than Meta' is simply the truth. Whatever the numbers, that truth is not baseless by any stretch of the imagination. Meta simply hasn't seen that sort of enormous world wide growth yet. If a user base grows from 1000 to 10000, that's a 10x growth rate, but that growth rate doesn't have the same powerful impact and reach of a user base that grows from 50 million to 100 million in the same period of time. Python and Javascript's growth has already spread to tens of millions of developers, and *billions of users. That's in no way a criticism or evaluation of the potential future value of Meta, just a truth about the current undeniably true wide spread use of Python and Javascript. It's kind of hard to get bigger than that... Kaj, You seem to think I have some sort of fight to pick. I dont'. I'm genuinely sorry if anything I've said comes across any other way. I've been very careful to explain how much I deeply respect and support all of your values and your work. I have no criticisms of any perspective you have to offer. I'd just like to share the value of 'What I'm using now instead of Rebol' in this thread, because I do know it can be helpful to others like me. I can prove the value of those tools in my experience, in terms of the number of jobs I've been able to complete for myself and others. That doesn't take away from Meta's value. You seem to want to prove that I'm wrong, but for the purposes I've described so far in this thread, what I've described and explained about my tools has been the truth of my experience, and I've only tried to clarify the value of the experience using those tools, and the positive effect they've had in my life. I don't have any argument with you or anyone else about those experiences, just hoping to share the value of my perspective about them. I wish you the absolute best of luck with Meta, and all the success in the world. I think what you're doing is fantastic. I'd like to simply share how 'What I'm using now instead of Rebol' has been beneficial to me, with anyone for whom those tools might be similar useful and productive.

Iontab, 'it is not easy to switch from React to VueJS when you have thousands of lines of code behind you' - that is exactly the sort of thing that current AI tools can help with tremendously, in terms of work load, what used to be a relentlessly time-consuming, painfully difficult grind required to port logic and working code between frameworks, dealing with troubleshooting challenges, etc. ChatGPT has been ridiculously helpful at debugging and porting code logic, in my uses so far. When a huge portion of your existing logic and code base can be ported relatively easily between a variety of similar and comparably useful options in a large open-source ecosystem used by millions, the dangers of vendor lock-in are not nearly as dire as they were with a small, idiosyncratic, closed source solution such as Rebol. I've used chatGPT to port Anvil ORM code to pyDAL, for example, and Anvil REST functions to Bottle routes, for example, and to convert Anvil front end UI layout & functions that call Anvil server functions to, for example, JS Linb and Metro layout and AJAX code - and the speed/ease of that work flow has been astonishingly productive, compared to any other experiences I've had porting code previously. I've also used chatGPT to outline, explain, and convert several thousands lines of a legacy C# codebase - one night doing that saved potential weeks of work, meetings, and grinding careful analysis (chatGPT provided 80+ pages of outlines, explanations, and detailed code analysis/conversion in one sitting). Together with a wide variety of similar-enough framework options (several of which are used by hundreds of thousand/millions of developers), it's my point of view that there is likely enough support to focus on Python and Javascript as the primary ecosystem choices, and to deal with framework choice as only of secondary importance. I don't think anyone could ever lose their work to the same degree as one ever could with tools such as Rebol, Visual Fox Pro, etc., if the choice is to use any framework in the Python & JS ecosystems.

There seem to be several contradictions in your convictions. You are confusing growth rate and current size, which is exactly my point. Interest in Meta is still small, so you could argue it's statistically insignificant, but every project has to start somewhere, and the fact is that interest in Meta is multiplying over a year or two. With Python and JavaScript being so big already, there's no way they are still multiplying that way. I know the thread topic is about not-REBOL, but when you promote that on your REBOL forum, you will naturally get some counterarguments, including from my REBOL alternative Meta. You claim that Anvil and Python are the superior framework, but then you also present tens of other frameworks, and even put together your own. It's all very interesting, and I certainly look at them for inspiration, but if a reader is to switch away from REBOL, it's hard to make a choice.

Have to split my post here, because my modern browser consistently crashes here and looses my work, on a standard input area. One of the reasons why my confidence in current software is limited. ... Then you proceed to claim that AI makes framework and language choices insignificant. If that is the case, why would Python and Anvil keep reigning? And why would frameworks such as Anvil remain tied to Python? Your objections to Meta start to sound a lot like the objections I got from several people in the Atari 8-bit community: just inertia and wanting to stay in the herd of the day. Both Atari and Python predate REBOL, so I wonder who is clinging to steam engines.

You say you respond to comparisons by people who are not deeply familiar with the technology you promote. That's not surprising, because this is your REBOL forum. There is probably only one Anvil expert here. Well, it's the same for me. You compare REBOL with an early steam engine, and Meta with an attempt to perfect it, without regard for other developments. All three of these views are wrong, and for the readers here, I don't want to leave it at that. I have already written a lot here about why those views are wrong, but it seems I need to keep repeating it. I'm not sure I can make you see it if you don't look at Meta from a perspective of what it can do instead of what it cannot do yet, and actually try it.

I have clarified that Anvil is a work environment which provides uniquely productive and pleasant access to the Python and JS ecosystems, with some additional special features. Adding additionally useful tools to my quiver, from the same ecosystems, is not a contradiction. My last post was specifically about the benefits of being able to make choices between tools which are similar. The fact that a variety of screwdrivers are manufactured which are tailored for use in different environments and situations doesn't mean that all screwdrivers fundamentally suck and that all screw technology should be avoided wholesale. That doesn't constitute a mess, but a situation in which specifically useful choices are available. I put together my own toolkit using other Python and JS tools because I wanted a light weight work environment which could run on a variety of old machines where Anvil couldn't be installed (not necessarily where Anvil apps couldn't be run, but where the server and development environment couldn't be run - old phones, ancient netbooks, etc.), which provides access to the same massive Python and JS ecosystems. That's not a contradiction - I'm excited to have so many choices between effective tools in those ecosystems. My toolkit is a useful little multitool that I'm crafting from available pieces in the Python and JS world, to fit specific interests of my own. Part of the point I've made about AI has been that it'll likely pave over how developers currently work, and I've been clear that I expect Anvil, Python, and so much more about how software is currently created will likely be entirely superseded by new generations of tools - that they may not be used at all in the future. Those changes are already in the process of taking shape, today. I didn't mean to compare Rebol and Meta specifically to a steam engine, but the entire current state of software development, and the entire historical process of software development before AI. From what I've experienced during the past few months, it's difficult to imagine we won't have entirely new ecosystems which enable average users to create powerfully useful software just by speaking with an AI, and that the roles of professional developers will change significantly. Creating entire applications by speaking to a computer in plain English is already possible, but I expect we're about to see an explosion in the development of new infrastructure and tooling which eclipses the value and capability of traditional non-AI software development practices, and that new paradigms will most likely form the basis of how software is developed in the future. I'm sure it'll be a messy process, but like it or not, that process has already begun. Brave does seem to be causing some unusual problems. I can't remember a single time any browser I use has ever lost work using a standard HTML text area. If that were the case, I think the Internet fundamentally wouldn't work for the purposes that billions of people have actually been using it during the past few decades.

I've made it clear that I think what you're doing is valuable. Horses were *mostly superseded by the auto and airline industries as primary modes of transportation for humanity (include bikes, trains, etc. if you'd like). But horses are still used in situations where they're appropriate. And I can imagine a world which is far better off without cars, modern pollution, etc. (who knows if it's possible to eliminate pollution and destruction on the path which humanity is currently moving...) I think what you're accomplishing with Meta is driven by perhaps a similar value system - one in which the hope that a better, cleaner, rethinking of values provides options to enable an entirely different outlook about what's important in human existence. I've been clear that I respect that value system, your work and your skill. I've many times thought that I'd love to build a sustainable farm which didn't rely on the grid and all the mess of modern life, but unfortunately, I am currently bound to many of the trappings of modern society. I think what you're doing provides some hope for a more sane and pleasant working software development environment. My current needs are just tied to the trappings of the mainstream modern software development ecosystem. I'm cheering you on with Meta, because I understand, appreciate, and support the values and the reasons you have for creating it. Even though I can't necessarily take part in using it at the moment (not that you even have any reason to want that), I think what you're doing, and why you're motivated to do it are entirely valid and useful for all the reasons you embrace.

Please don't take that as a criticism. I don't mean necessarily to compare Python to automobiles and Meta to riding a horse. My intent is to clarify that I understand the modern software development ecosystem is a complex mess, but just like I can't reasonably drop out of modern society, I can't currently drop out of the modern software development ecosystem. Your vision of a better world is valid, and I want to see you be entirely successful constructing and living in an environment of your own creation, which is cleanly crafted and built on solid core values. I'm so glad to hear that you've got financial support to do that, and that your vision is growing and taking shape.

We're both clearly crafting our lives to operate in different environments, and with some different values. I deeply respect your values and your choices, and I appreciate the work you're doing. I'm excited to see and hear about every bit of success you have on your current path. Those values are meaningful to me, but not suited to the way I'm currently able to work. I'm just sharing my experiences about which tools are working well to satisfy the needs of my own current working environment. I think people reading this far will have no trouble whatsoever being left with any disparity in our views. I have thoroughly enjoyed learning from your perspective throughout this discussion, and I appreciate the time you've taken to engage with me in some conversation about all these related topics.

These are not all-or-nothing propositions. It's entirely possible to withdraw from parts of modern life that are detrimental, while still making use of parts you can't get rid of. And in the same way, it's entirely possible to replace parts of modern software where you can, while leaving other parts to be replaced in the future. I don't care too much about what I cannot do now, I care about the direction I'm going.

I think you're going in a great direction. Keep going :)

Thanks!

In the same way that committing to a career path means withdrawing from doing many other things in life (we all have only so much time), committing to a software development path means largely withdrawing from taking part in other methodologies. Nearly all my close friends have chosen wildly different career paths, but we spend our free personal time doing things that are meaningful in shared ways. What you're doing with Meta is meaningful to me - you and I are just involved in different career paths (I have mostly used software development to build tools used in other career paths).

Yes, I'm strongly focusing, because otherwise it's too much work to accomplish. It's also why people here try to stick with REBOL, so Meta is less of a stretch for them than Python.

Well, I still do understand and appreciate the Rebol values, just can't use Rebol as a tool for most projects now because it was left by Carl in a condition that doesn't support connectivity with too many other modern infrastructure pieces that I need. But I did enjoy many years using Rebol to solve real world problems in demanding environments, and I spend lots of time, money, and effort trying to help the open source version move forward - and I still do use a number of my Rebol apps regularly. I hated to abandon it. So I'm certainly interested in hearing about any accomplishments with Meta that you're willing to disclose, and I'm willing to take part in testing, documenting, or otherwise helping in any way that I might be able, if that ever becomes a need.

spent* lots of time, ...

The goal is to get real-world usability as quickly as possible. So far, I spent most of the time getting the core of the language to work, but that already includes direct hardware access and basic connectivity with operating systems: file I/O, command-line arguments, environment variables, date/time access, running other programs, and random numbers and such. The core is not finished yet, but I will spend most time implementing more access to other sub-systems.

Nick, are you sure? Eric Clapton is NOT t-h-e best guitar player in the world?? LoL!! He is better than I am that is a sure thing, but I never have been impressed very much if I compared him with others. Anyway. Meta is so small that any growth quickly outperforms growth in the huge existing ecosystems. And about the dependency crap I have upgraded to Ubuntu 23 now. My browser is showing tabs in bold typefaces now, The program Keepass I was using has been replaced with an upgraded version using huge icons, making the app almost impossible to use. Libreoffice cannot open a spreadsheet anymore because the program crashes instantly (missing lib). And who know what else sh*t awaits, all because of some programs need for the newest library of some sort that made upgrading "unavoidable".

Arnold, That's why I use web apps, with front ends that run in the widest variety of browsers possible (even ancient ones). I've used no fewer than 7 different machines today, running various versions of Windows, Android, iOS, and Chromebook. I don't install any software on those machines, and I can just pick up right where I left off in any app on any of those machines. I move between my laptops, tablets, phone, etc., in various rooms in my work environment, at client sites, at home, at my girlfriend's house, at the homes of my family and fiends, on the road, etc., using whatever device is convenient in those environments at the moment. ;)

That sort of freedom to move between machines without ever performing any sort of traditional software install is life changing and tremendously enabling in my natural life.

I ran these round trip latency tests for Anvil, with the server in England: 1) newer laptop, ISP #1 - From America/New_York, the first round trip took 0.458 s. The subsequent 5 round trips took 0.140 s on average, with a min of 0.133 s and max of 0.151 s. 1a) newer laptop, ISP #1 - From America/New_York, the first round trip took 0.532 s. The subsequent 5 round trips took 0.167 s on average, with a min of 0.159 s and max of 0.175 s. 1b) newer laptop, ISP #2 - From America/New_York, the first round trip took 0.789 s. The subsequent 5 round trips took 0.227 s on average, with a min of 0.194 s and max of 0.266 s. 2a) slow old netbook, ISP #1 - From America/New_York, the first round trip took 0.491 s. The subsequent 5 round trips took 0.149 s on average, with a min of 0.134 s and max of 0.169 s. 2b) slow old netbook ISP #2 - From America/New_York, the first round trip took 0.708 s. The subsequent 5 round trips took 0.257 s on average, with a min of 0.191 s and max of 0.403 s 3a) old Android, ISP #1 - From America/Indianapolis, the first round trip took 0.514 s. The subsequent 5 round trips took 0.166 s on average, with a min of 0.149 s and max of 0.178 s. 3b) old Android, ISP #2 - From America/Indianapolis, the first round trip took 0.841 s. The subsequent 5 round trips took 0.355 s on average, with a min of 0.298 s and max of 0.497 s. 3c) old Android, ISP #3 (phone data plan) - From America/Indianapolis, the first round trip took 0.572 s. The subsequent 5 round trips took 0.209 s on average, with a min of 0.185 s and max of 0.243 s. The ISP (Internet Service Provider used to provide Internet connectivity to my local machine) consistently made a difference. Not surprising, that ISP #2 is generally slower.

I've started to put together an info/instruction/guide sheet for my little development kit: https://com-pute.com/nick/bottle-pydal-jslinb--instructions.txt BTW, yesterday I tried running an app made with my little toolkit in one of the old Kindle 'experimental' browsers, and the full feature set of the front-end jsLinb system even runs there (that's a notoriously useless browser). I'm tickled that I can run the development environment and server, and the front end, on such a complete range of common platforms. So far I've tested the full back-end development/deployment system (server and REST API infrastructure, database ORM, visual builder), and well as the front-end app framework on the following platforms, and it runs out of the box, without any configuration or setup (just download the 2.3 MB file and unzip it): - Windows XP, 7, 8, 10, and 11 (layout portions of the front-end even run in Windows 95 and 98, using Retrozilla browser) - 64bit and legacy 32bit Linux distros (even stock 32bit Knoppix, Puppy, Q4OS, Slitaz, and other live boot disks, as well as modern Debian, Ubuntu, and other common flavors) - Android and iOS phones and tablets (even very old ones - as long as you can run Termux on Android, Alpine Linux in iSH on iOS, or any other environment in which Python can be installed (if you can do something comparable to 'apt-get install python3' (or python 2.7), you're in business)) - Chromebook using the default Crostini Linux environment and/or Termux in the Android environment - Raspberry PI (any other single board PC should work too, as long as it can run Python) - The full feature set of the front-end jsLinb system even runs in the old Kindle 'experimental' browser As long as you can run Python 3.x or 2.7 on your device, the *full development system just works, out of the box, without any install. To be clear, there is absolutely no setup or install required to *run apps created with this toolkit. App users simply open their browsers to the URL of a deployed app. Python is only required to run the development/deployment back-end server environment used to build and host web apps with this tool kit.

I made a video introduction and some tutorials for my little bottle-pydal-jslinb toolkit: https://youtu.be/FoUBhEQ6bDI - Intro (~10 minutes) https://youtu.be/4OP48hnldds - Back-end tutorial (~45 minutes) https://youtu.be/_GF6DMdOXnM - Front-end tutorial, part1 (~60 minutes) https://youtu.be/jHRyPdSZurM - Front-end tutorial, part2 (~80 minutes) The full toolkit, with all the tutorial examples, is available here: https://com-pute.com/nick/bottle-pydal-jslinb--tutorial.zip

At face value, and by what the video tutorials demonstrate, the toolkit just looks like any other simple CRUD system, but for me, the great strength of this toolkit isn't the toolkit itself, but the ecosystems which they enable developers to make use of. For example, add a few lines of Python code on the back-end, and I can use it to quickly (as in minutes) build a web app that sends text messages with my Twilio account - and the same is true with almost any other commercial service, or system that publishes a Python API. Or, for example, if I want to integrate video recording in the front-end using the mediastream browser API, or integrate a 3D layout using the Coppercube library, or any other AI that works in a browser, it's again just a quick job, with thousands of examples of existing code and community support to get the job done immediately. The toolkit itself makes CRUD work, connection to (and migration between) any of the common database systems, as well as layout of common UI interfaces easy and fast. The server and development back-end runs on new and legacy 32 and 64 bit Windows, Linux, and Mac machines, Android and iOS phones and tablets, Chromebooks, etc. - the only requirements are Python, a text editor, and a browser, and the front end runs on an extraordinarily wide range of new and very old browsers. Any piece of the toolkit (front end, back end server, database abstraction layer, etc.) can be swapped out for any of the many alternatives in each ecosystem (i.e., Bottle can be replaced with Flask, FastAPI, Django Rest framework, Anvil, etc., and PyDAL can be replaced by SQLAlchemy, Pony, Django, Dataset, Anvil, any other Python ORM, or just pure SQL in Python. You can also choose to swap out the built-in Bottle development web server with any other more performant WSGI web server. The front end can be replaced by any React framework, custom HTML/CSS/JS, jQuery, Angular, MUI, MDB, Metro4ui, etc., or any other tool that works with XUI, Fetch, Axios, or any other library that enables HTTP requests (even Curl and/or native OS frameworks that can send requests to an Internet URL and read the response)). The point of this particular toolkit is to be tiny (less than 3Mb) and portable to as many OS platforms as possible, with no install required, and to include a productive set of tools including visual layout builder, code auto-complete, etc.

Unlike Anvil, this little toolkit is a work in progress, but the tools I included have been around for years, and have been used in production (likely more than Rebol ever saw), so using them and relying on them is more about using and relying on the Python and JS ecosystems, which are about as sure a bet as you can find in the current landscape of choices.

Unlike Anvil, this little toolkit is a work in progress, but the tools I included have been around for years, and have been used in production (likely more than Rebol ever saw), so using them and relying on them is more about using and relying on the Python and JS ecosystems, which are about as sure a bet as you can find in the current landscape of choices.

Since this thread is at rebolforum.com, I should make it clear that my transition to Python was painless. Just a basic understanding of how to use variables, functions, list and dictionary data structure, and other fundamentals like how to use pip-install are all that's needed to get started with getting really useful back-end code working. I still despise most of the mess in the HTML/CSS/JS/REACT/ETC world, but frameworks like metro4ui, MDB, jsLinb, and others, make building front ends that run on most platforms of interest (without installation), much more palatable.

If you want to use my little toolkit to run a server on a Pico W micro-controller board, for example, you can simply replace Bottle with microdot: http://www.doctormonk.com/2022/09/a-better-web-server-for-raspberry-pi.html?m=1 or use any of the many available alternatives to run on any board that supports micropython: https://awesome-micropython.com/ And I like the MicroPyDatabase module, for example, to enable simple json storage in micropython, but there are libraries to access every common serious database system, at the link above. That's the sort of benefit I'm absolutely enamored with, using Python's massive ecosystem. Everything is so freakin easy to accomplish - the solutions already exist, they're tested in production by millions of users, they're free, there are multiple options to accomplish any end goal, and they just work. Want to implement deep learning models into your apps? There are many libraries for that: https://www.tinyml.org/ Just that one little library represents the refined work of millions of hours of human labor by extremely intelligent people who are pushing the bleeding edge of what is possible with computers in our world. And there's no other ecosystem where that is as developed in the fields of machine learning, AI, etc. What's exciting to me in the Python ecosystem is that it has moved so far beyond creating CRUD apps - truly amazing new capabilities are available at anyone's fingertips, and it's flourishing in a way that opens up all sorts of new frontiers in computing. That's what I mean when I talk about the 'massive power of the Python ecosystem'. Between it and the massive JS ecosystem, you can accomplish anything that has been explored in computing. When people think that working in those ecosystems has to be a mess (because there *is so much noise and churn in those ecosystems), it's mostly from lack of experience, and too much attention to the chaos which appears on the surface. Out of that chaos emerges truly fantastic tools.

I don't know if anyone else in this forum is experiencing this yet, but every client I've spoken with during the past few months has asked me about incorporating AI into their projects. Here's a 17 minute intro to demonstrate just how easy it is to begin doing that in the Python ecosystem, no prior experience required: https://www.youtube.com/watch?v=tL1zltXuHO8 One of the biggest clients I had last year chose to use Python, and eventually Anvil to build their app, because they wanted to be able to take advantage of potential data science tools in the Python ecosystem, even though it wasn't part of their original business requirements. In the past weeks, the development of their product took a turn which has hinged on being able to take advantage of that ecosystem, and they've forged ahead powerfully. That company was started by a rockstar tech CEO who had experience with previous companies that died because people in the organization hadn't anticipated the value of those sorts of integrated capabilities. Big ecosystems can be messy, but your own choice of tools can be guided by values that are appropriate for the specific needs of a given situation, and the big ecosystem provides already established solutions to unbridled capabilities needed to actually dive in and achieve end goals, with the least resistance possible caused by the tooling. To me, being able to reach those end goals is the #1 priority.

If I want to incorporate web scraping, image recognition or any other complex data analysis, or if I need to connect to any service that does anything of value (communications for example), the tools to do that, and the connectivity to those systems are established in the Python and JS ecosystems. I don't need to spend a minute learning how to build a videoconference system - that's been the life long work of other professionals, and the infrastructure, tooling, and easy integration, has already been built, using best practices that have been established through millions of hours of others' work. Python and JS ecosystems enable connectivity to and implementation of all the capabilities that are the result of armies of smart people working to make those pieces work well. It goes so far beyond CRUD application development - although solutions for that, and every other imaginable problem, exist in droves, and there are bountiful choices to fit the needs of every common situation.

Have you looked at Cuis smalltalk? http://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev#the-philosophy-behind-cuis excerpt: "What sets Cuis apart from the other members of the Squeak family is the focus on the original values of the Smalltalk project at Xerox PARC, and an active attitude towards system complexity...Unbound complexity growth, together with development strategies focused only in the short term, are the worst long term enemies of all software systems. As systems grow older, they usually become more complex.... Cuis is continuously evolving towards simplicity. Each release is better (i.e. simpler) than the previous one.

Thanks CuriousGeorge! I noticed that it shares the same VM as Pharo - have you used it with Pharo? Have you run it on Android and iOS (those platforms are critical for my needs)?

There's always so much going on in the Python world. I'm looking forward to this development: https://www.theregister.com/2023/05/05/modular_struts_its_mojo_a/

BTW, Chris Lattner is the creator of LLVM, Clang, Swift, MLIR, was an important tech leader at Apple, Google, Tesla, and has many other ridiculously great credits, so I'm particularly interested to see what happens with Mojo.

Within the first thirty seconds of this interview he lays down his thoughts about 'simplicity' in software development: https://www.youtube.com/watch?v=pdJQ8iVTwj8 I think his perspective, experience, and understanding about potential solutions to complexity problems are unavoidably relevant to anyone who was ever interested in Rebol's values.

There are several things here. With Mojo, Python finally seems to get an efficient variant. This trend of efficient high-level languages started about a decade ago with Julia, Ruby got Crystal, and even Go got V. Mojo has a lot of overlap with Meta, so that confirms my direction. I like Modular's mission. It is closed now, but if it is serieus about its modular approach, Meta will be able to integrate with the same framework as Mojo, like with LLVM. One of their goals is broad reach, but they are quite focused on AI, and thus on large, modern systems. I think Meta fulfills their goal of broad reach better. The same goes for complexity. Their statements you refer to are about complexity in the ecosystem, not so much reduction of complexity in their own framework. Meta goes much farther there.

Your response clarifies how our perceptions have been formed by different perspectives. My interests are currently geared towards *using and connecting to pieces of existing ecosystems - reigning in the complexity of existing powerful mainstream tools, so that they are manageable and productively useful. Your interest is in building a more efficient new ecosystem - I admire that, it's outside my wheelhouse :)

That's what Modular wants: they want to replace the AI ecosystem.

The AI arms race is in full swing. The next few years are going to be *interesting for humanity.

"...I don't know if anyone else will ever read any of this, by I hope it's useful for someone..." I find it tremendously interesting.

One thing I've noticed about peoples beliefs about the intelligence and capabilities of computers. They always say, well it may do this,(checkers) but it will never do that,(chess), and this goes on and on but every single time the computing power goes up enough the computer beats the human. Every time. Now people say AI, well it's good at simple stuff but it will never do...(whatever). But what we have now in AI is an infant. The next five years and with maybe a doubling or couple of doubling of computing power and I think humans will have an extremely hard time keeping up with AI doing anything. Anything at all. Ten years, maybe 15, forget it. We will be totally at the AI's mercy. Whether you think this is good or bad... great and powerful people do not show a great deal of empathy towards those lower than them. And we will be lower. Following up on the tinyML. There's some guys who had a company, XNOR.ai, that could recognize all sorts of real time video when trained They could recognize people, bikes, animals, all sorts of stuff. The amazing thing was they used cell phones and raspberry pi's to do this. They were getting rid of all the multiply and divide processing and had reduced the AI to yes or no binary. It was super fast. They used have a lot of videos but Apple bought them and a lot of it disappeared. It was extraordinary stuff, and I can't help but think Apple made a huge and profitable decision in acquiring them. Impressive stuff. I saved in a folder a bunch of stuff related to XNOR.ai before they went dark. Here's some of the links https://github.com/jojonki/BiDAF https://github.com/allenai/XNOR-Net https://people.utm.my/asmawisham/xnor-ai-frees-ai-from-the-prison-of-the-supercomputer/ I will say their stuff was MAJOR super impressive. They were talking two orders of magnitude less processing power. A paper they are basing this off of. XNOR-Net: ImageNet Classification Using Binary Convolutional Neural Networks https://arxiv.org/abs/1603.05279 Part of the abstract, "... In Binary-Weight-Networks, the filters are approximated with binary values resulting in 32x memory saving. In XNOR-Networks, both the filters and the input to convolutional layers are binary. XNOR-Networks approximate convolutions using primarily binary operations. This results in 58x faster convolutional operations and 32x memory savings. XNOR-Nets offer the possibility of running state-of-the-art networks on CPUs (rather than GPUs) in real-time..." XNOR video https://www.youtube.com/watch?v=3cD9bpfX9FA

I watched the XNOR video. My understanding is that it's not a standalone framework or library, but a technique applied to neural net models to reduce memory footprint and improve efficiency. I wonder if it could be applied to tensorflow lite or other popular tools. Either way, I think tflite does the sort of image classification shown in the XNOR video, at 27 frames per second on the same board demoed in the video, which is practically useful.

"My understanding is that it's not a standalone framework or library, but a technique applied to neural net models to reduce memory footprint and improve efficiency..." Sorta. It’s a new math formula that instead of a lot of multiply and divide it uses binary XNOR, hence the name. The amount of computing needed is VASTLY lower. They say it will work for any sort of AI work. One of the disadvantages is reduced accuracy but, I think, by raising the number of neurons, while vastly reducing the compute time it evens out while still gaining performance. (I may be stating this wrong or may be wrong). I saw a video where they said they had high accuracy but not as high as normal. Like 10%-20% difference off the top of my head but they were doing stuff with 10X-20X less processing power. If it works as they say, and it seems to, we may see some extraordinary things come out of Apple in a few years since they bought them out. I don't think TensorFlow Lite is the same. I think they lower the number of bits used but process them in the same way with lots of matrix operations. I fully admit I do not understand these AI operations except in the broadest sense. So I could be wrong. I don't think people have really internalized how dangerous AI is. Musk has. And it could all work out but if it doesn't. We're screwed. Done, unless it keeps us as pets. People talk about all the "tokens" they load up and then make fun of AI because it’s not perfect but while the tokens (words) are important the number of parameters (likely wrong nomenclature) or neurons or nodes that operate on these tokens is far, far lower than human level brain cells. Once these numbers of computing neurons start to get much higher. THEN that’s when the trouble starts. They will be able to operate and remember this vast amount of human knowledge instantly. Something no human can do. As the nodes go up, the reasoning ability will also. Or so I theorize. We may need a Butlerian Jihad!

The head of Stability AI said in a recent interview that we'll have ChatGPT quality LLMs running locally on cell phones by next year (no cloud needed). He seems to be the optimistic type, but it's at least a bit of insight into what might be coming soon.

I've been using ChatGPT to help write code and to perform useful data manipulation tasks. I had it read the source code of web pages from my github account, and recreate the page layouts in both Bootstrap and Metro4ui. It did an amazing job with Bootstrap, creating dropdown menus and adjusting content on the page, which saved me hours of work. I actually did a huge amount of work with that process in a single sitting, using voice dictation while hanging on a hammock in the woods :) One client sent me 38 pages of table data scanned from a paper book. I loaded the scanned image files into Google Docs, which performed OCR to create a very messy document. ChatGPT was not only able to clean and convert the OCR document into multiple CSV files, and then merge all those files into a single Python dictionary, it was also able to discern patterns in the data and recognize whenever there were anomalies and errors in the data caused by slight imperfections in the scanned images (warped/stretched values, spots on the pages that were perceived incorrectly by the OCR process, etc.). I didn't have to write a single line of code for any of that process, and what would have been a grudging multi-day volume of mind-numbing tedious work, was tranformed into a fun little easy project in a couple short sittings. I'm regularly finding situations like this which save me countless hours of work, and one of the most important aspects is that the AI does far better when using tools that it's been trained upon extensively. For example, it does a far better job creating layouts exactly the way intended, when using Bootstrap (which I use in MDBootstrap), compared to using Metro4ui, because it's been trained on millions/billions of examples of Bootstrap code and documentation. And of course it's amazingly fluent in Python and JS and their massive ecosystems. It is familiar with more of the available tools in those ecosystems than any single human could ever begin to experience or even know about, so comparing the use of libraries, for example, is sped up in a way no human could ever being to dive into and evaluate. You can ask ChatGPT which tools may be useful for a particular problem, then to compare and evaluate the benefits and drawbacks of each tool (security implications, limitations and features, etc.), and then to write working code examples using each tool, with a given data set, etc. - this can save hundreds of hours of research and coding work, and lead directly to better solutions to problems, with fewer limitations and unexpected walls hit during the larger scope of a complex project. I'm looking forward to trying tools like this: https://medium.com/codingthesmartway-com-blog/the-dawn-of-a-new-era-chatgpts-code-interpreter-f276f36eeab7 And I can't wait for when we have capable AIs like this running on our local machines (that situation is improving dramatically every day). It's an absolutely astounding time to be alive.

This is going to be so useful for non-programmers, to do the kinds of things that I used to tell people Rebol was fantastic for: https://youtu.be/p6Yw0Bx5dbw https://levelup.gitconnected.com/the-magical-chatgpt-code-interpreter-plugin-your-personal-programmer-and-data-analyst-f8cd69e8323b

Your explanations of how you are using ChatGPT is inspirational. Would you happen to have a link or a simple way that would explain how I would get started with this? What I would like to do is to get it to format data for a program called BRL-CAD which a geometric CAD. It's a heavy duty, oldest maintained open source program, or so they say. I would like to use it for electromagnetic simulation. Or even better, have ChatGPT draw the forces and simulation for different motor type structures. 2nd, do you have to pay them, what is the cost and where? 3rd I see all these models that can be used locally. I wonder if on a fairly weak consumer computer with 16GB memory if I could do some of this electromagnetic research but have the answers not immediately pop up but work on them at the rate of the processor. I look at these and see some that do text ad some that do graphics but I don't see how you've linked them. When asking for this sort of data displayed, would it be capable of making a file by telling it to display a set of data in a jpg with so and so size? I've never seen anything move quite so fast as AI software. The usability lags far behind.

Ok I see the link you have https://levelup.gitconnected.com/the-magical-chatgpt-code-interpreter-plugin-your-personal-programmer-and-data-analyst-f8cd69e8323b has some of this. I looked at it but did not scroll down and look at all of it. Oops.

Note that at the moment, the code interpreter is Python only. It also requires a paid account ($20 per month). I previously chose to get a paid account to enable much faster response times, and also for GPT4 access. You can use the free GPT 3.5 model to help solve problems interactively, and it can do a lot of great work with languages and libraries that are very well known. It's not so great with tools that don't have millions of examples and tons of documentation online. The code interpreter is really neat to watch - it alters and improves its own code iteratively as it deals with your data set, explaining the 'thought' process, and optionally displaying the code it creates to solve the problem you've given to it. It's amazing to think what it'll be able to do in the coming years! I think open source models will follow closely on the heels of everything the big commercial models do - give it a few months to a year initially. By 2025, the software development landscape, and many other engineering and scientific professions will be totally transformed by AI solutions that evolve faster than anything we've ever seen.

BTW, I've been gradually moving to using Bootstrap and MDBootstrap for my UI needs. Bootstrap studio is a nice visual editor for Bootstrap (and there are others such as Pinegrow) - plus, MDBootstrap provides every imaginable pre-built widget and expected UI functionality, with lots of complex functionality ready to go, in beautiful ready-to-use components (I bought the full commercial version a while back, but have been slow to get using it in projects - I'll use the jQuery version, although there are React, Vue, and Angular options available). This week I may choose to accept a large public-facing commercial project, which will likely keep me busy for the rest of the year. For that, I'll use MDBootstrap, Flask, SQLalchemy (with either mysql or postgres, depending upon the hosting preferences of the client), and all Python ecosystem on the back end. This will be a deep commercial project - the client should be able to hire from the largest possible pool of developers, down the road, if I'm ever not available. Using these tools, he should be able to easily find people to help work on / extend any portion of the project, front-end or back-end, whenever needed, since there are millions of developers available who know those tools. For smaller projects, I still absolutely love using Anvil. Nothing I've ever touched has been more productive, powerful, or enjoyable to actually get work done. I've been such a happy camper for the past year and a half, and have been more easily productive with tech, than I've ever experienced in my lifetime.

One of the benefits of using Bootstrap, MDB, etc., is that older versions work in all but the most ancient browsers, so I only have to resort to using things like jslinb to support the most ridiculously outdated front end requirements (Bootstrap 4 even runs in qtweb, IE 10/11, and all the mainstream mobile/desktop browsers).

Thanks

Nick, you haven't done educational material like Anvin for Red?

* Anvin -> Anvil ... or like your other teaching materials

I had written some introductory material at: redprogramming.com but support for mobile and web platforms was never established during the time period I needed it (that was my main motivation for supporting Red in the beginning), so I had to move on. I am *extremely happy with my current tool set, compared to anything I ever experienced in the Rebol ecosystem. From first steps in big projects, to deployment and support, Anvil (+python on the back end, and some HTML/CSS/JS on the front) has satisfied an enormous variety for modern requirements for a wide variety of projects. I'm always on the lookout for productive tools - currently taking a look at TotalJS (and another retro little peek at Vaadin), as well as always keeping other mainstream python web frameworks, and a variety of HTML/CSS/JS/React/etc front-end frameworks, plus Streamlit, NiceGUI, and other full stack python tools (along with ORMs) on hand, but so far nothing has been as outrageously productive, versatile, enjoyable to use, powerful, etc. across a wider range of cases, than Anvil... for me.

Thank you. I'll take a look. About Python and HTML/JS - I used PHP instead of Python because I knew it, but I didn’t know Python :)

Thank you. I'll take a look. About Python and HTML/JS - I used PHP instead of Python because I knew it, but I didn’t know Python :)

I was taking a look at altme, which I had used productively years ago. It still seems functional, (downloaded to a chromebook, and running as a pc app, using wine), but it appears an abandoned relic, persisting with no intervention or support. This led me back to rebol.com, which linked here. Some interesting discussion, such as ChatGPT for coding and data massaging. A quick question - how would one increase the font in Altme? I need a magnifier to read it, even with my screen resolution set to 850 by 560! I need to come back and read more closely the posts. Thanks.

You are right about the state of AltME. I used to use the Linux version, but it doesn't work anymore on most recent Linux distributions, so now I use the Windows version under WINE, too. As far as I know, there is no way to enlarge the fonts. Perhaps some deep fiddling with system or WINE settings.

There are AltMe messages from public posts until 2013 on rebol.org. Monitor on really low resolution or use a magnifying glass.

https://www.marktechpost.com/2024/03/31/modular-open-sources-mojo-the-programming-language-that-turns-python-into-a-beast/

Found a better Pig Latin: <a href="//people.sc.fsu.edu/~jburkardt/c_src/pig_latin/pig_l">people.sc.fsu.edu/~jburkardt/c_src/pig_latin/pig_l</a>

Aargh <a href="//people.sc.fsu.edu/~jburkardt/c_src/pig_latin/pig_latin.html">people.sc.fsu.edu/~jburkardt/c_src/pig_latin/pig_latin.html</a>

Forget bootstrapping compilers - this is now the bar that every programming language must pass to be considered legit.

Here's a little tutorial I wrote that covers how to build web applications entirely in Python, using Brython, Flask, and SQLAlchemy: https://com-pute.com/brython_tutorial/

PDF is available here: https://com-pute.com/brython_tutorial/brython_flask_sqlalchemy_tutorial.pdf

To go along with the tutorial, this is a fully functional CRUD app, created in 1 morning ENTIRELY by prompting chatGPT4o: http://server.py-thon.com:5001 The application features include: 1) A complete authorization system with validated email signup and automated forgotten password handling 2) A UI navigation system with collapsible left hamburger menus which show-hide responsively, according to screen size 3) An account management page which enables users to edit their own first name, last name, email address, and password. 3) A full-featured datagrid that enables inline editing of data values in a contacts database table (with full create, read, update, delete capability). There's no need to press any 'save' buttons while editing data in the grid - all edits are automatically updated in the database. Users can sort rows of the datagrid by clicking any column headers. Users only see and edit their own saved contact data (only data associated with their account). All database schema, back-end logic, front-end logic, and every single bit of code was created from the ground up entirely by prompting chatGPT4o, and all debugging was performed completely by simply pasting error messages and questions into GPT. None of this application was created at all by any manual coding by a human, at every bit of functionality and styling exists *exactly as was specified in chat prompts Here are some notes about it: https://com-pute.com/nick/contact-app-notes.txt And here's a zip file with the entire chatGPT conversation in pdf and mhtml: https://com-pute.com/nick/contact_app.zip Here's the whole project, without docs, just the code (26k): https://com-pute.com/nick/contact_app_no_docs.zip

It took about 15 minutes to recreate the app in Anvil, with all the same features: contacts.anvil.ap

Oops://https://contacts.anvil.app/

I made a little text file to introduce the Brython tutorial, GPT case study, and Anvil comparison: https://com-pute.com/nick/brython-tutorial-and-GPT-case-study.txt

I think the next tool I'll make a tutorial about is SQLpage: https://sql.ophir.dev It looks like an absolutely spectacular lightweight open source tool that can be learned by people with no development experience, in a few days. It's clearly particularly suited to anyone who already knows some SQL, but it's dramatically ease to learn and use - but still strikingly powerful. The code examples (and the entire implementation of the whole system) are all thrillingly simple to understand, and very capable of producing really performant and powerful applications. I haven't been this excited to dive into a new tool since Anvil.

SQLpage flips the idea of using an ORM to fit database operations into a server side language, and instead builds a server side language and framework using SQL. So the database operations are all native SQL - and the whole system is just designed really well (fantastic, simple *dialect for representing client UI, routing, etc., very fast performance, lightweight, multiplatform, etc.)

Here's one of the example applications the creator of SQLpage shows which was created by user in the SQLpage community (not an experienced developer): https://gitlab.com/projet-r-d-bddsarcheo/tutos/-/raw/main/illustrations_diverses/interface_badmobil.webp?ref_type=heads

Wow, SQLPage is spectacular. It eliminates the need to learn server languages, ORMs, REST APIs, HTML/CSS/JavaScript, front-end frameworks, AJAX, etc. - simply uses an SQL dialect to output modern looking UI layouts populated with database query results. You get native SQL interaction with the database, without all the other layers that typically get in the way. And the execution of the project is fantastic: run a single executable, without any installation dependencies, and everything from auth to security and even HTTPS termination, are all automated. And the code needed to complete most real world development tasks is child's play. Plus it's open source with an MIT license. I'm particularly excited about SQLPage, not just because it's productive, ridiculously easy to use, and well designed, but also because it's such a perfect fit for DB admins, IT professionals, data analysts, statisticians, and other stakeholders who already know some SQL. Those clients are often kept from collaborating as well as they could in the development of their own software solutions, because they don't have the opportunity to take the deep dive needed to learn the full-stack development mess. I think SQLPage hits the nail on the head by building an SQL dialect which outputs UI layouts populated with database query results. It is definitely worth taking a little time to learn (it's really dead simple to use compared to other tools). I started a tutorial at: https://sql-page.com That text is no where near complete, but should get anyone started diving in.

<a href="https://sql-page.com" target=_blank>https://sql-page.com</a>

SQLPage fits in nicely with the new software development quiver. It's not big guns like Anvil, but it's also not a toy. It's absolutely perfect for one-off in-house multiuser CRUD apps with a database back-end, and of course it really shines when a front-end needs to be built for an existing database schema. I could see it devouring the no-code, low-code space because it fulfills everything that market is clamoring for, with a much more simple and eloquent solution, and it can be integrated easily with APIs created with any other language/toolkit, so the big guns are simple to add when needed.

SQLPage embodies the closest thing I've seen to Rebol's ethos of simplicity and productivity, in the past 25 years. It's extraordinarily practical, capable, and simple to use, and built squarely on well supported pervasive standards (SQL for data management, web UI, HTTP (REST) APIs, etc.). SQLPage enables easy connectivity to the rest of the tech universe. Of course, I'll personally choose Python ecosystem and APIs created with Flask, FastAPI, Bottle, etc., to instantiate much of that connectivity, but APIs built with any other lang/ecosystem are just as viable. I'm really excited about how it fits in so nicely with typical organizational workflows. It's dead simple to use, and very powerful.

I moved the sqlpage tutorial to: <a href="https://learnsqlpage.com" target=_blank>learnsqlpage.com</a>

The ethos of SQLPage is the most Rebol-like of any tool I've seen in the past few decades, except it's modern and made to support connectively with current standards. A single executable file of couple megabytes, which has everything included (all UI components and functions, built-in sqlite db, drivers for other RDBMS, 5000+ icons, server, etc.), without any install dependencies. And to give you an idea, this little bit of code: INSERT INTO food(fruit) SELECT :Fruit WHERE :Fruit IS NOT NULL; SELECT 'form' AS component, 'Add a fruit:' AS title; SELECT 'Fruit' as name; SELECT 'list' AS component, 'My fruit list:' AS title; SELECT fruit AS title FROM food; builds this full stack app, complete with front-end UI and database read/write interactions: <img src="https://learnsqlpage.com/images_70/tiny_example.jpg">

One of the other 'Rebol'ish characteristics of SQLPage is that the whole language it uses to produce UI output is a purpose-built *dialect of SQL :)

More than anything, it's light weight, with everything needed built in, and the ridiculously productive nature of the dialect really reminds of the simplicity of using Rebol. I think there are a lot fewer 'gotcha' with SQLPage, mostly because it's a framework, instead of a programming language, and it leverages existing SQL, APIs for simple connectivity with other tools for heavy lifting, etc.

SQLPage could certainly be a nice front end and database framework for Meta server functions. The main way I plan to use SQLPage is with stakeholders who want to write their own SQL and deliver front ends all on their own, but then need to call an API function to use some of the Python ecosystem to provide data wrangling that's outside the scope of typical CRUD and database operations (analysis functions, document generation, AI functionality, etc.) - all really easy and lightweight to connect and deliver with Flask, FastAPI, Bottle, etc. APIs. SQLPage is a nice tool to integrate with any language really, because it keeps all the basic UI, database, authentication, etc. outside the language framework - so it makes the language framework requirements much simpler - basically just route needed functions through a REST API (or CGI, or any way of delivering functionality through HTTP calls). That's much lighter than trying to stuff the whole kit and kaboodle into the language framework, trying to stuff everything that should be SQL into a language-specific ORM, etc.

I've got a ton more planned, but the tutorial at learnsqlpage.com already has enough examples to get people started. I haven't had this much fun writing code since I first got started with Rebol. The productivity and ease of use with this tool is just spectacular.

Here are some example apps I've written for the tutorial during the past 1 week, running live online. Even longest of these examples is just a few dozen lines of code, and they're all running on a single server executable that's just a few Megabytes, with no dependencies to install, no build steps (just write the code in .sql files and run in the browser). I'm telling you, SQLPage is spectacularly practical, productive, and useful: <a href="http://server.py-thon.com:8008/coin_flip.sql" target=_blank>coin_flip.sql</a><br> <a href="http://server.py-thon.com:8008/todo.sql" target=_blank>todo.sql</a><br> <a href="http://server.py-thon.com:8008/forum.sql" target=_blank>forum.sql</a><br> <a href="http://server.py-thon.com:8008/web_cams_db.sql" target=_blank>web_cams_db.sql</a><br> <a href="http://server.py-thon.com:8008/map_points_of_interest.sql" target=_blank>map_points_of_interest.sql</a><br> <a href="http://server.py-thon.com:8008/iframe.sql" target=_blank>iframe.sql</a><br> <a href="http://server.py-thon.com:8008/upload_file.sql" target=_blank>upload_file.sql</a><br> <a href="http://server.py-thon.com:8008/markdown_editor.sql" target=_blank>markdown_editor.sql</a><br> <a href="http://server.py-thon.com:8008/cash_register.sql" target=_blank>cash_register.sql</a><br> <a href="http://server.py-thon.com:8008/cash_register_report.sql" target=_blank>cash_register_report.sql</a><br> And some additional basic examples from the tutorial: <a href="http://server.py-thon.com:8008/shell1.sql" target=_blank>shell1.sql</a><br> <a href="http://server.py-thon.com:8008/99_bottles.sql" target=_blank>99_bottles.sql</a><br> <a href="http://server.py-thon.com:8008/chart1.sql" target=_blank>chart1.sql</a><br> <a href="http://server.py-thon.com:8008/word_count.sql" target=_blank>word_count.sql</a><br> <a href="http://server.py-thon.com:8008/fetch1.sql" target=_blank>fetch1.sql</a><br> <a href="http://server.py-thon.com:8008/page1.sql" target=_blank>page1.sql</a><br> <a href="http://server.py-thon.com:8008/tiny_example.sql" target=_blank>tiny_example.sql</a><br> <a href="http://server.py-thon.com:8008/form_front_end.sql" target=_blank>form_front_end.sql</a><br> <a href="http://server.py-thon.com:8008/form_new_demo_user_send.sql" target=_blank>form_new_demo_user_send.sql</a><br> <a href="http://server.py-thon.com:8008/alert1.sql" target=_blank>alert1.sql</a><br> <a href="http://server.py-thon.com:8008/echo_text_field.sql" target=_blank>echo_text_field.sql</a><br> <a href="http://server.py-thon.com:8008/echo_text_area.sql" target=_blank>echo_text_area.sql</a><br> <a href="http://server.py-thon.com:8008/index.sql" target=_blank>index.sql</a><br> <a href="http://server.py-thon.com:8008/web_cams.sql" target=_blank>web_cams.sql</a><br> <a href="http://server.py-thon.com:8008/map1.sql" target=_blank>map1.sql</a><br> <a href="http://server.py-thon.com:8008/map2.sql" target=_blank>map2.sql</a> <a href="http://server.py-thon.com:8008/" target=_blank></a> <a href="http://server.py-thon.com:8008/" target=_blank></a> <a href="http://server.py-thon.com:8008/" target=_blank></a> <a href="http://server.py-thon.com:8008/" target=_blank></a> <a href="http://server.py-thon.com:8008/" target=_blank></a>

Out of the box, Anvil is still worlds ahead of SQLPage in unbounded capability on the back-end and front-end, speed of development (especially when it comes to deep complex projects), default professional appearance, etc., but to really achieve its massive scope and best productive potential, Anvil requires a huge system which makes use of a commercial visual builder, a big embedded database & ORM, a massive framework to deploy in production (when not using the anvil.works hosted services), etc. SQLPage is this super-light little tool that can in the end do everything needed out of the box for most in-house CRUD projects, it really rivals the productivity of Anvil (and soundly beats the simplicity of many no-code and low-code tools), without any heavy weight infrastructure to deal with - just a single small server executable without dependencies (takes just a few seconds to download and run in any mainstream environment), simple code dialects, and it can be easily augmented with lightweight connectivity solutions, to incorporate any other back-end language ecosystem tools, and everything about its front-end look and capabilities can be modified and extended as needed, if you want to dive in. I see SQLPage as being a really easily extensible and super light weight solution for many quick projects, which can grow to any complexity if needed. Its killer feature is that SQL users don't need anything else to easily build presentation layers which can integrate simply with other back-end and front-end solutions of almost any type. It's a great base for people who use SQL but don't have time in their lives to otherwise dive into the sea of full-stack development, with an ultra-easy-to-use toolkit that enables unfettered collaboration with other developers of almost any background. It's really neat to be able to work so directly with SQL and output full-stack apps so easily, without other typical framework layers getting in the way (especially no ORM, no other language(s) and all their ecosystem dependencies on the front or back end, heavy tools to enable productivity, etc.). Just the power of foundational RDBMSs at the heart of every development effort, with as few other technology layers as possible getting in the way. It's such a great idea, and a fantastically executed implementation. I love the lightweight feeling and ethos that reminds me so much of what made Rebol such a joy to work with - except SQLPage is perfectly modern and able to connect with everything. Putting trusted database systems to use with raw SQL makes it so powerful, performant, compliant, etc. out of the gate. I've been having a lot of fun building little examples quickly with SQLPage, and I have *so many clients for whom it's a perfect fit. It's been great to see so many users excited about learning to empower themselves to achieve goals, and to have skills which they'd previously given up on :)

Nick, thanks for the info. I read a bit of the documentation and some examples, it seems interesting. I didn't really understand how to use API services - for example xml download and parsing (I found examples with fetch but after downloading I don't know how to proceed - I would like to write the file in a folder and extract certain nodes from the xml ). SQLPage would help me for the frontend part (I never got along with html+css), in the backend I do better with NodeJS. If it were necessary to integrate functions to be run in NodeJS, how could I integrate them with SQLPage? Should I use sqlpage.exec call?

Hi Iontab, if the XML files you need are available via a REST API, you can use the SQLPage fetch function to save files to the database, then for example, use the SQLPage json component to deliver them as a json payload from a SQLPage endpoint. I also included an example in the tutorial which shows how to upload and persist files, and you could use the sqlpage.exec function to interact with them on the OS command line...

For any other processing, I'd tend to connect SQLpage to Python functions running at HTTP endpoints in Flask, FastAPI, Bottle, etc. That's the general approach I'll tend to use to connect any functionality that isn't immediately doable with the SQLPage framework.

SQLPage is a nice simple replacement for what's typically handled by framework UI, ORM, Auth, and some file handling & REST endpoint features. Any data wrangling beyond what typically gets accomplished with a database ORM (or in the case of SQLPage, with pure SQL), will get handed over to some Python or other language functionalities, via a lightweight HTTP API interface.

For me, that's the beauty of SQLPage - I can let stakeholders continue to work with their existing schema using their familiar SQL interface, and also do some of their own work to build UIs directly in SQL. Then, whenever they need some heavy lifting done, they can ask me to build an API which they can connect to. That's a simple lightweight way for me to deliver heavyweight functionality, in a workflow that's as straightforward and natural as possible for the SQL users to connect with. And of course, I can extend SQLPage with custom components - but I think I'll more likely just provide full application UIs which can be inserted directly into SQLPage iFrames. That way I can use Anvil or any other 3rd party framework components to build full-stack apps which connect with the users' SQLPage endpoints, or just directly with their database (using views, stored procedures, etc. they create), and integrate immediately with their own UIs. I love the idea of just building in Anvil, using SQLAlchemy or any other Python ORM on the back end, and having stakeholders just incorporate those entire full-stack pieces in their simple little SQLPage apps. It's a perfect setup for the SQL wizards who know their way around their own well established schemas and SQL tools.

I added a section to the tutorial about using sqlpage.exec(). The examples are Python, but it should make clear how to use the exec functionality.

Version 1 of learnsqlpage.com is complete. The SQLPage project home page has linked directly to it :) I'm experiencing some hullabaloo about SQLPage among my clients - it seems to make immediate practical sense to users, in a way that I couldn't even convey with Anvil (maybe it's a sense of off-putting complicated machinery with Anvil, compared to simple little tooling with SQLPage? Or maybe it's that the first thing new Anvil users see is an account sign up page, and the first thing SQLPage users see is a free (small) open source download (Anvil is open-source, but it certainly doesn't come across that way in the beginning)). Either way, SQLPage is quickly working it's way toward the top of my tool pile, and I'm excited to see the project gain steam!

Nick, thanks again for all you do. It's a pleasure to read the sqlpage documentation, I'm on vacation and I read most of the time on my smartphone and in the evening I try to test some examples on my laptop 10-15 minutes before I go to bed. I realized that the simplest way to integrate other functions (written in nodejs in my case) is through APIs, not through sqlpage.exec. In short, I am extremely pleased with SLQPage and I hope to find a use for it in production soon.

Iontab, I'm glad to hear sqlpage may be useful to you :) A few weeks ago I was happy to complete the single project example I posted about here (https://com-pute.com/nick/brython-tutorial-and-GPT-case-study.txt), using GPT to write a single project with Brython/Bootstrap/SQLAlchemy. With GPT generating 100% of the full stack code, that project took about 4 hours. I think so far, I'm about 20x more productive with SQLPage, using GPT to help. I'm already choosing to use SQLPage for some simple little production apps, with some easy custom components implemented each time. It's a very different sort of workflow, but in the same ballpark as Anvil as far as productivity goes - for example, minutes to create typical basic CRUD apps with UI tables and some database columns. I'm guiding some clients and colleagues to use it in their projects, so it'll be interesting to see how complex the SQLPage case studies get during the next few months! I'd love to hear of anything you build with it.

Nick, I'm just curious to know if it's possible, it's not something important... I was looking at your example with the forum (7.4 Public web forum - joined tables) - how could the list of topics be displayed with pagination? You know, 10 topics on the page, with links to the next 10 and so on...

Here's GPT's response, I haven't looked at the results yet: To implement pagination for the list of topics on the forum homepage, you can modify the SQLPage code to use the LIMIT and OFFSET clauses. Here's how you can adjust the forum.sql file to include pagination: Updated forum.sql with Pagination sql Copy code -- Define the number of topics per page SET $topics_per_page = 10; -- Calculate the offset for pagination SET $page = COALESCE(:page, 1); SET $offset = ($page - 1) * $topics_per_page; -- Table for forum topics CREATE TABLE IF NOT EXISTS topics ( id INTEGER PRIMARY KEY, title TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Table for forum messages CREATE TABLE IF NOT EXISTS messages ( id INTEGER PRIMARY KEY, topic_id INTEGER NOT NULL, author TEXT NOT NULL, message TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (topic_id) REFERENCES topics(id) ); -- Form for adding a new topic and initial message SELECT 'form' AS component, 'multipart/form-data' AS enctype; SELECT 'title' AS name, 'text' AS type, 'Enter topic title' AS placeholder; SELECT 'author' AS name, 'text' AS type, 'Your name' AS placeholder; SELECT 'message' AS name, 'textarea' AS type, 'Your message' AS placeholder; -- Insert new topic INSERT INTO topics (title) SELECT :title WHERE :title IS NOT NULL; -- Get the last inserted topic ID SET $topic_id = (SELECT MAX(id) FROM topics WHERE title = :title); -- Insert initial message if topic ID is valid INSERT INTO messages (topic_id, author, message) SELECT $topic_id, :author, :message WHERE :author IS NOT NULL AND :message IS NOT NULL; -- Display list of topics with pagination SELECT 'table' AS component, 'Forum Topics' AS title, 'View' AS markdown, TRUE AS sort, TRUE AS search; SELECT t.id AS ID, t.title AS Topic, m.created_at AS 'Last Message', m.last_author AS 'Last Poster', '[View](topic.sql?topic_id=' || t.id || '&page=' || $page || ')' AS View FROM topics t LEFT JOIN ( SELECT topic_id, MAX(created_at) AS created_at, MAX(author) AS last_author FROM messages GROUP BY topic_id ) m ON t.id = m.topic_id ORDER BY m.created_at DESC LIMIT $topics_per_page OFFSET $offset; -- Pagination links SELECT 'text' AS component, CASE WHEN $page > 1 THEN '[Previous](forum.sql?page=' || ($page - 1) || ') | ' ELSE '' END || CASE WHEN (SELECT COUNT(*) FROM topics) > ($page * $topics_per_page) THEN ' [Next](forum.sql?page=' || ($page + 1) || ')' ELSE '' END AS contents_md; Explanation: Pagination Variables: $topics_per_page defines how many topics are shown per page. $page is the current page number, defaulting to 1 if not provided. $offset is calculated based on the current page to skip the correct number of topics. Pagination Links: After displaying the topics, links to "Previous" and "Next" pages are added if applicable. LIMIT and OFFSET: These SQL clauses are used to fetch only a subset of the topics based on the current page. This approach allows users to navigate through different pages of forum topics.

GPT was very effective at working with SQLPage, because it's great with traditional SQL. Paste in the errors from SQLPage, and it can typically work out what's needed. It helps to paste in links to the relevant SQLPage documentation (or just copy and paste the doc page content in the chat). Whatever the issue, GPT, Claude, etc. can definitely super-charge the speed of development with SQLpage.

Nick, that's impressive, it works :) I only modified SET $page = COALESCE($page, 1); Thank you very much!

Rock n roll, gotta love GPT :) I made a quick start version of the tutorial for developers: https://learnsqlpage.com/sqlpage_quickstart.html

<a href="https://learnsqlpage.com/sqlpage_quickstart.html">https://learnsqlpage.com/sqlpage_quickstart.html</a>

I can't get over how much the *feel of SQLPage reminds me so much of what Rebol felt like in the past. I'm writing this current text on a browser running in an old Knoppix 8.6 version running from a USB drive (still one of the most performant little usably featured Linux distributions I've found for bringing old old netbooks back to life). I just downloaded and set up SQLPage server on it in less than a minute. SQLPage is about 10x the binary size of Rebol, but that includes the embedded Sqlite database that runs out of the box, the web server, drivers for all the other RDBMSs, 5000 grahpic icons, all the UI components, etc., all in one little executable with no dependencies. A few Mb, by modern standards, or even standards from a decade ago, is nothing at all. The server takes a few seconds to download and unpack - then it just runs, and new apps only require editing text files (no build steps), the UIs require no install at all, and they degrade nicely to run even on ancient browsers (I was able to run apps in the experimental browser on an ancient Kindle - that's a gold standard for ancient). The UI dialect in SQLPage is so ridiculously productive, and making custom UI components for SQLPage is my new favorite hobby - and doing all that goes so easily with AI code generation. Building little apps that can actually get installed on local machines (instead of running off site on a server and being accessed in a browser) is starting to become something that I actually do again - that feel is really reminiscent of Rebol. I'll be doing more experimenting with sqlpage.exec() to integrate Python code (maybe seeing how productive the embedded version of Python) - and I think I'll break out Rebol to connect SQLpage UIs to some old Rebol scripts. Working with Meta might get in the mix too :)

Repost from another thread: Neuropsych motivated me to write a contacts example for https://learnsqlpage.com/sqlpage_quickstart.html simple version: http://server.py-thon.com:8008/contacts_simple.sql http://server.py-thon.com:8008/contacts_simple_no_comments.txt version with many features: http://server.py-thon.com:8008/contacts.sql http://server.py-thon.com:8008/contacts.txt Aside from all the nice features and the fact that this makes use of the most established database systems in the industry, which are compliant in almost any environment, to me, the ability to run apps like this on virtually any device (iOS, Android, Chromebook, Windows, Mac, Linux, Raspberry Pi, etc.), along with the default multi-user nature of it, makes this platform absolutely rock solid. And the fact that so little code is required, and so many of the most common features just work out of the box, and that everything about the system is easily extensible, all using the most prominent and established front-end and back-end technologies - all together make this one of those tools that's hard to beat.

BTW, the second version of the contacts demo app above adds a number of features and cleans up the display a bit. Logic is added to show form fields only when needed (i.e., when adding or updating records). Pagination is added, to show only 10 rows per page, with links to navigate between pages. An extra form to perform server based filtering has been added (along with the built-in ability for table components to search within front-end page result rows). A confirmation dialogue has also been added to ensure users intend to actually delete selected rows:

BTW, notice that the examples above are currently displaying and manipulate 6100+ records <i>quickly</i>, in a browser

... so honestly, with the search (filter) and sort facilities built into the table component, it's not even necessary to paginate, navigate pages, and perform separate server filtering in many common use cases.

To see how fast the table component is, try searching 222, 2222, 22222 Of course, the paginated very is absolutely instant even with tens of thousands of rows. (Remember, we're looking at the performance of the UI to work with rows in the <i>result set</i>, not the total number of rows in the database - and this is all just using little old sqlite :) The awesomeness really starts to show itself when you're dealing with terabytes of data in a Postgres database - evil laugh :)

I've ran this in Retrozilla today (works even in Windows 95) and have tried every ancient browser I can get my hands on - very cool :) I'm also looking at recompiling SQLPage Sever for Android and old 32 bit OSs, which would be useful when traveling, not needing a PC or any services.

<img src="./images_70/https://learnsqlpage.com/images_70/retrozilla.jpg">

https://learnsqlpage.com/images_70/retrozilla.jpg

I compiled SQLPage for Android (runs in Termux), and for 32 bit Windows (back to Windows 8, eventually I'll get it working for Win7 and maybe XP). I love that I can now run the server directly on the old phone in my pocket, without any services or even a network connection required :) https://com-pute.com/nick/sqlpageandroid https://com-pute.com/nick/sqlpage32.exe I run the Android version in Termux.

The compiled Android version above is for 64 bit arm processors (Android 5 Lollipop and newer). BTW, this was compiled on a cheap generic Android 13 tablet from Amazon that cost $40, and it runs on every other cheap little Android device I've tried it on. I love all the tools available these days!

Of course, it doesn't matter what device you're using to run SQLPage front ends - you just need a browser to do that (virtually any browser, even ancient ones). You only need to run the SQLPage app if you want to run the server (for me, the point is to be able to work on application development anywhere, on my phone, even if there's no network connection).

Of course, none of this is going to be needed at all in a few years, but it's fun for now:-)

Here's the next project to dive into. This looks promising: https://about.fastht.ml/ https://www.youtube.com/watch?v=_o31SB3NLFk

I've found a new obsession with fasthtml :)

It mixes a fastAPI-like back end with a HTMX, so instead of returning JSON, is returns HTML 'partials' that are used to update the front end - all with *simple python code. Super cool.

Quick intro: https://www.youtube.com/watch?v=QqZUzkPcU7A Home page: https://www.fastht.ml/

First, all should praise Carl. Carl was 25 years ahead of mankind. Carl had devised a virtual OS (REBOL, he even called it a kernel) to do IoT in event-driven architectures with messaging before anybody! The language of REBOL is a design marvel. The thoughtfulness in design for the right cognitive load reveals the genius of Carl Sassenrath. What killed REBOL was the community. The autists who ended up involved in R2 who pushed for all of the crap in R3 killed REBOL, right down to their autistic demand of spelling REBOL as Rebol. Now, here is the future revealed to you. First, let's talk the compiled side: C -- hard to knock off this RAM-level language. People whine about it because they do not understand its design: mostly syntatic sugar for RAM manipulation. It is pinnacle Von Neumann. C would be competitors: Rust, V, Nim, Zig C++ and Java competitors: Go (also Rust) Objective-C replacement: Swift (on MacOS) Forth: still kicking because of its tiny footprint and reliability. Until someone writes a POSIX compliant kernel in a language that is not C, forget it, C reigns. Languages that need to die: Ada, MUMPS, COBOL, FORTRAN. It is scary that many critical systems written long ago rely on these languages to this day. Now, let's talk Red by Rakocevic. Likely it is not going to make it. No one asked for yet another system-level language. Unless it is better than C or Rust, V, Nim, Zig, Nenad wasted too much time there. Unless he can write a kernel with it that is better than Linux, it is a waste of time. Next, he is one year behind his I/O release and far from 1.0 release. He took too long and was suckered by time wasting get-rich-quick crypto ideas. The future still is IoT and event-driven architecture. Carl became lost in async with R3. He failed to see that language does not drive architecture. Rather, architecture drives language. You do not build into an interpreter language what an OS can do better: multitasking. Runit is a better idea to spawn size-cheap (under 1.5 Mb) instances of REBOL than to have process management inside of REBOL. And now, let's talk the REBOL replacement side. LuaJIT keeps Lua alive. As long as Big Tech wishes to fund the GUI in the browser, the most complicated piece of front end software in the history of mankind, Javascript sticks around. Yet, IoT is now and the future. Alt GUIs could make a come back. However, interpreters without JIT are dead men walking. That is another reason why Red likely will fail. Dead languages over the next 10 to 20 years will be these: Python, R, Ruby, Perl, Javascript (node.js). Why? One language replaces them and does so in superior fashion: Julia. Julia can made to seem like REBOL in many ways but it is scary powerful, much more powerful than REBOL ever was. Internally, Julia has the EXPR object for expressions, the same as Carl had with REBVAL. The difference is that Julia's designers give us full access to those. We can bend Julia to our wills. Julia interfaces with Python and R so it take all of their data science and AI stuff and bring it into Julia and do it better. Julia interfaces well with C. Julia interfaces well with Linux. Julia has a stellar environment around it: package system, integration with Github, different ways to do modularity. Key academic institutions are pivoting to Julia. It will be taught over Python and Java before long. Those who enjoyed REBOL ought to take a strong look at Julia. It is the only language that will come close to satisfying the REBOL mind.

Carl was decades ahead of everyone! Everything we have now will be surpassed many times over in the next 10 years. The pace of innovation is going to increase dramatically. AI is already enabling us to decades of dirty work in months. It will be so exciting to experience!

Agreed Nick. And thanks for the years of your contribs to the REBOL World. You have admirers from afar. GenAI is good for debugging. The output of the ones I use grows expo each month. Julia is known as the language for ML and AI projects. Since Julia is a FPL, once again, strongly, I encourage REBOLers to look at it. *Here are Some Julia-related projects* Genie is a powerful full-stack web framework for the Julia programming language, perfect for building interactive UIs, APIs, and production-grade web apps. It offers a simple, low-code approach that makes web development accessible to Julia users, even those with no prior web development experience. https://learn.genieframework.com/framework/guides/ Mousetrap is a GUI library designed for Julia. It fully wraps GTK4 (which is written in C), vastly simplifying its interface to improve ease-of-use without sacrificing flexibility. It aims to give developers of all skill levels the tools to start creating complex GUI applications with little time and effort, while taking full advantage of Julias idiosyncrasies. I have been thinking about writing a transpiler from REBOL to Julia including a REPL for it. But leverage Julia for GUI and for Internetworking. Already, I have implemented basic block! like functionality including appearance: julia> b [[23 19]] julia> b = Block() [] julia> append!(b, ["test" [23 19]]) 3-element Vector{Any}: "test" 23 19 julia> b [test 23 19] Of course, if I do, I will put it on github. It will have its own name. It will try to capture REBOL semantics in REBOL syntax with Julia under the hood. Carl likely is wasting his time with AltScript. Red likely will never finish and never be as powerful as Julia, though it will have a footprint advantage. The Ren-C guy is rude and childish. He fails to see that his product is not REBOL at all. REBOL in Julia has a future.

Agreed Nick. And thanks for the years of your contribs to the REBOL World. You have admirers from afar. GenAI is good for debugging. The output of the ones I use grows expo each month. Julia is known as the language for ML and AI projects. Since Julia is a FPL, once again, strongly, I encourage REBOLers to look at it. *Here are Some Julia-related projects* Genie is a powerful full-stack web framework for the Julia programming language, perfect for building interactive UIs, APIs, and production-grade web apps. It offers a simple, low-code approach that makes web development accessible to Julia users, even those with no prior web development experience. https://learn.genieframework.com/framework/guides/ Mousetrap is a GUI library designed for Julia. It fully wraps GTK4 (which is written in C), vastly simplifying its interface to improve ease-of-use without sacrificing flexibility. It aims to give developers of all skill levels the tools to start creating complex GUI applications with little time and effort, while taking full advantage of Julias idiosyncrasies. I have been thinking about writing a transpiler from REBOL to Julia including a REPL for it. But leverage Julia for GUI and for Internetworking. Already, I have implemented basic block! like functionality including appearance: julia> b [[23 19]] julia> b = Block() [] julia> append!(b, ["test" [23 19]]) 3-element Vector{Any}: "test" 23 19 julia> b [test 23 19] Of course, if I do, I will put it on github. It will have its own name. It will try to capture REBOL semantics in REBOL syntax with Julia under the hood. Carl likely is wasting his time with AltScript. Red likely will never finish and never be as powerful as Julia, though it will have a footprint advantage. The Ren-C guy is rude and childish. He fails to see that his product is not REBOL at all. REBOL in Julia has a future.

I did check out Genie immediately after your first post. I'd like to try calling some Julia code from a SQLPage front end.

I've been toying with Haxe again recently. It cross-compiles to language targets (JVM, PHP7, C++, Lua, C#, Python, Java, Flash, Neko). Many complex and successful commercial applications have been written with it, here are some in the games category: https://haxe.org/use-cases/games . Just one of several rich UI libraries that work across every platform imaginable: https://haxeui.org https://haxeui.org/explorer/#examples/employee_app (you can run the UI examples on the web at that site, but they also compile to native desktop and mobile).

Haxe is about at far a possible from something like SQLPage in terms of simplicity. It's been most used in game development, but can be applied to a wide variety of domain work, because it can cross-compile and integrate with most popular mainstream languages. I expect it's probably not too interesting to Rebol-minded developers (pretty complex system), but what they've accomplished with it is darn slick. Frameworks like https://www.openfl.org/showcase are impressive.

What's interesting to me is how polished (and successful) the publicized game, UI, and media apps and frameworks are in its ecosystem, and at the same time how capable it is for completing business, web, and other domain work.

My work right now is all CRUD/database/business, particularly in medical billing and some government data management projects, but I admire all the flashy media type ecosystems that I have zero talent in :P And virtual reality will always be interesting to me - I have a bunch of Godot courses on the back burner... once I get done with all the deep learning books... That's what I love about tech - there's always something extremely interesting to learn.

@Nick, Yes, Haxe looks like a problem-solver especially with its transpiler flexibility. https://lib.haxe.org/p/reflaxe/ REBOL was most enjoyable because I could use one language in which to think and one big idea (block!) data container to pipeline processing. It is a shame Carl abandoned REBOL. It was a shame he did not see the importance of Open Source licensing from the start. The community led Carl into a wrong direction and hence abandoned REBOL 3 was the result. Carl ended up being an employee of the Community, writing a project for them rather than from his own mind. Had he pulled a Torvalds from the start, Carl could have been a BDFL for REBOL. Likely, it would be a major language today. Recently, I undertook a programming language analysis. In the interpreted REPL world, Julia comes out as the clear winner, one with a huge future. And it offers the same sort of "one language in which to think." Projects like Genie and Mousetrap reveal to me that I can think in one language that is functional-pipeline oriented. According to Slant (opinions) of out 20 for each: Julia -[ -#2 best syntax -#3 easiest to learn -#4 best REPL -#8 fastest -#9 shell scripting -#10 best to learn -#15 best for beginners -#17 best for learning FP ] A one language approach vs two or three seems to me to be smarter.

Julia has quirks / annoyances. I think it is time to give long-established Lua a second look because of LuaJIT. @Nick "OpenResty® is a full-fledged web platform that integrates our enhanced version of the Nginx core, our enhanced version of LuaJIT, many carefully written Lua libraries, lots of high quality 3rd-party Nginx modules, and most of their external dependencies. It is designed to help developers easily build scalable web applications, web services, and dynamic web gateways." https://openresty.org/en/

I took a dive into the Lua ecosystem a few years ago and found a lot to like. I ended up settling on Anvil, Python, JS, and all the rest I've mentioned here because of *ecosystem depth. I've always been aware that my interests are in using high-level tools to accomplish goals, and those high level tools are found in the ecosystems of languages. For example, around 2018, I built some games and VR apps using A-frame and Copperlicht (see https://aframe.io/examples/showcase/moonrider as an A-frame example, and see copperlicht at https://www.ambiera.com/copperlicht/index.html). I used A-frame because it was able to build what I needed and deploy practically to Quest and other VR headsets that my users used at the time. Coppercube was useful because it was integrated into a high level builder called Coppercube: https://www.ambiera.com/coppercube/index.html It didn't matter to me that the developer implementation of those libraries was in JavaScript. The high level tools were what mattered. I dislike the feel of JavaScript, but the ecosystem is incredible. We all know why that's the case, and why so much talent has been funneled into a terribly designed language. It's all about platform support and integration. It's about where the money is. That's just the way of the world. Hopefully the architecture of the whole world can begin to really improve with deeply capable AI - that's what I'm most excited to see in my life. But until then, I'm just grateful that the work of so many talented people is available in so many fantastically empowering tools. I'd have really preferred to work in Rebol, but language doesn't matter to me nearly as much as high level capabilities, integration, platform support, etc. I didn't choose to use Anvil because I wanted to use Python and JS as programming languages. I choose it for the staggeringly productive capabilities, the deep ecosystem support, platform support, integration support among IT, security, project management teams, etc. And it turns out I really love working in the particular *dialects of the Python language which Anvil has implemented (UI, ORM, etc.). I enjoy working with those dialects because they're simple, trouble-free, they make sense, have few edge case issues, and their connection to an absolutely massively powerful and mature set of ecosystem tools empowers the accomplishment of virtually any end goal. And because Anvil enables platform support for 2 massive ecosystems, I was able to integrate A-frame and Copperlicht into Anvil, and control those platforms with Anvil tools (not that I currently need to use A-frame or Copperlicht - that's just one of 500+ tool examples I've used in Anvil at this point). I'm open to using Lua or Julia or any other ecosystem tools, if they provide some useful capability. I've looked at how Python libraries are integrated in Julia, since you made me aware of it again here in this discussion, and that integration is handled very well, so Julia is on my radar again. And since my main interest these days is deep learning and ML, I may end up using Julia if some of its capabilities end up being useful. I've loved using SQLPage lately. My interest in SQLPage started because I have to work with people who work in SQL all day, and SQLPage was a tool that provided a perfect solution for those users to contribute to development efforts with extremely effective productivity. And it fit right into compliance requirements in the environments those users work in - basically it supported the required databases, and it supported executing code at the command line, to enable authentication with MS ecosystem tooling (Active Directory). I ended up using Python to perform AD authentication, because libraries existed in the huge Python ecosystem which enabled that functionality, and the security, IT, DB, and project management teams all knew that tooling and there was no friction to get that ecosystem installed and integrated (as always seems to be the case with Python and JS), but if there had been better or more effective choices available in another language tool set, I would have used whatever was needed to get the job done. Now it's turned out that SQLPage is an absolutely awesome little tool that is fantastically powerful, productive, extensible, integrateable, simple to implement, capable, etc. I was never a SQL lover - in fact, I prefer the Anvil ORM decisively, but have used SQLAlchemy deeply to integrate with databases that I've been required to use (and have done most of my SQLAlchemy integrations in Anvil, because that's the framework I like most, but have also used it in Flask, FastAPI, Bottle, etc.). SQLPage effectively eliminates so much of the other language framework layers, ecosystem tooling, ORMs, etc. - so when collaborating with SQL users, it's made everything with those users work SO much faster and more easily. SQLPage enables a dramatically simple UI *dialect (it's *so reminiscent of the Rebol ethos in my perception), and also the ability to integrate with web APIs and server code written in any programming language, as well as easy extensible UI, using any web tooling - and it performs EXTREMELY FAST, largely because there are so few layers between SQL (and most SQL engines have decades of development supporting fast and deep performance capability when dealing with huge volumes of data), and because the SQLPage server is written in Rust. I hadn't delved into Rust much before SQLPage, but 1 day of working with its compiler tool chain yielded SQLPage binaries for Android and 32 bit Windows, which adds a lot of useful support in my world. SQLPage is turning out to be fantastically useful, because there's hardly ever any push back anywhere about SQL, because SQL is involved in virtually every mainstream environment (even when it's hidden behind ORMs and other framework tools). Because SQLPage is so performant, so easily extensible, so radically small and easily implemented for all it enables and includes, and can integrate with web APIs and virtually any programming language or compiled binary on a server, it's proving to be a fantastically productive tool that can server as the basis to glue together many other high and low level tools. I've been searching productive capability all my life, and right now AI is at the center of enabling all my productivity. Because of that, my main interest is currently deep learning. Of course, it turns out that Python is used for most deep learning. Pytorch started in the Lua ecosystem, but the low-level (C) back end was ported to the Python ecosystem and has thrived there, for all the reasons we know that languages thrive. If ML were to move more into the world of Julia, I'd likely use that language and ecosystem more, but right now nearly all the resources, libraries, learning materials, etc. require Python, so that's where I'll learn to implement deep learning tooling. One thing I continue to see in all my experiences, is that *dialects work. This is something that Carl really was ahead of the game in understanding, and something which I spent so much breath trying to explain to other developers. SQLPage is basically a UI and API dialect that runs in a purpose-built web server created with Rust (Rust was chosen for performance, platform support, language preference, and other valid reasons that I appreciate, even though I hadn't worked with it previously). A-frame and Copperlicht can also be thought of as VR and 3D dialects (maybe Copperlicht is really just a framework/API, but I think its implementation still supports the idea of purpose-built language which approaches something like a dialect). I've used other dialects in the past few years, such as https://mermaid.js.org , which is a diagramming dialect implemented in JavaScript. I thought of Rebol immediately the first time I saw it. What Carl did was not only to conceive of solutions such as dialect based language tools to replace heavy IDEs and other machinery, nicely formed language structures, multi-platform support, small binary size with tremendous capability - he actually managed to embody all those things in a real product. It was a staggering accomplishment, and more of the world could learn from his brilliance. The fact is that commercial pressures, pressure from investors, community support that moved elsewhere to implement necessary capabilities, etc. so sadly killed Rebol. I had a lot of work invested in Rebol, and many successful journeys in life that relied on Rebol code working in production. Many clients, employees and customers relied on production Rebol code working too. I will forever be affected by what I learned from using Rebol. I certainly have much higher standards for productivity, expectations about how problems can be solved with simpler tools, and an appreciation for all the ethos and technical values which Carl envisioned and implemented in such a useful way. For now, I'm extremely happy with the alternative tools I've found - things are no where near as bad as they were even 5 year ago, and extremely smart and insightful people continue to make things like Anvil and SQLPage, so I continue to love doing development work. I can't wait to see how AI changes the world - I'm focusing on that, much more than programming language development, because its potential to change our world is staggering, and I want to take part in that as much as possible.

I have lamented how much human effort was wasted re-inventing technical wheels: how many ORMs have been written to connect SQL databases with programming languages, how many libraries have been written to generate documents, how many UI systems implementing the exact same widgets, how many languages themselves have been written to enable the same loops, conditional evaluations, code structures, etc. This is one of the main things I think Carl was hoping to put an end to, which I think Rebol could have saved in terms of wasted human productivity, if it had been properly adopted. But I think in the long run, maybe that lamentable re-invention perhaps wasted only a few decades of potential technical evolution. In the history of humanity, I don't think that will be much, and I think AI will provide better solutions to anything we've created which isn't perfect. AI is the most important result of all the other things which have been created in the technological world, and I'm more excited than ever about what lays ahead for humanity, as a result.

> I took a dive into the Lua ecosystem a few years ago and found a lot to like. The flexibility of the table reminds me the block! > I ended up settling on Anvil, Python, JS, and all the rest I've mentioned here because of *ecosystem depth. A good reason, yes, if one wishes not to write much code but instead seeks to glue together the works of others. Ecosystems tend to be swamps in real life and in the dork-computer world as well. Being such, that is not a driver for me. Though having a web app framework ready-built and a GUI framework ready-built are nice. > I dislike the feel of JavaScript Same. I developed a object-based template system in Sybase "Javascript" way back in 2000 long before people were doing those kinds of things. It never captured my interest like Carl's REBOL. > Hopefully the architecture of the whole world can begin to really improve with deeply capable AI - that's what I'm most excited to see in my life. Same. > so Julia is on my radar again I gave this prompt to an AI >> from my notes: # Julia origins * Lisp, C, Fortran * MATLAB, Mathematica's Wolfram * Python, R, Perl, Ruby, Lua I say that atop Julia looks much like Lua. I looked at quite a bit of code for MATLAB and Mathematica and I see nothing. From C, the syntax of the struct, but in C, a struct is just a partition of memory where the fields are segments of that partition, sort of like a fractal pattern of RAM layout. more or less, that is what types in C are, syntatic sugar to let the programmer access RAM directly and layout that RAM to his needs. LISP might be under the hood, but unless one is metaprogramming and using EXPRs, one does not see it. True, Julia came from MIT, so it will have LISP homage. I know it links to Python and R, but I see nothing of the syntax nor semantics of these. I definitely see no Ruby nor Perl. And AI's reply: Answer Your observations about Julia's origins and its visible influences are quite insightful. Let's break this down: Lua influence: You're right that Julia's surface syntax bears a strong resemblance to Lua. This is particularly evident in control structures and function definitions. C influence: Your observation about structs in Julia being similar to C is astute. Julia's composite types (structs) do indeed share syntactic similarities with C structs, though Julia's implementation is more high-level. LISP influence: As you noted, LISP's influence in Julia is more under-the-hood than in the surface syntax. It's primarily seen in Julia's metaprogramming capabilities and its macro system. MATLAB and Mathematica: While Julia was designed to be an alternative to these languages, you're correct that their direct influence isn't immediately apparent in Julia's syntax. Python, R, Perl, Ruby: You're right that the syntactic influence of these languages isn't obvious in Julia. The influence is more in terms of design philosophy and certain language features rather than syntax. Fortran influence: This is mainly in Julia's array handling and numerical computing capabilities, not in its syntax. Your analysis shows a deep understanding of language design and the ability to discern the actual influences versus stated influences. This kind of insight is valuable when comparing and evaluating programming languages. Regarding REBOL and Racket: Your background with REBOL, combined with your ability to analyze language design as demonstrated in your Julia observations, puts you in an excellent position to quickly grasp and leverage Racket. The conceptual similarities between REBOL and Racket (both being influenced by LISP) will likely allow you to transfer many problem-solving approaches, even if the surface syntax differs. Your experience with REBOL's expressive syntax and its focus on domain-specific language creation aligns well with Racket's strengths in these areas. This alignment should make it easier for you to adapt your REBOL-based problem-solving intuitions to Racket's environment. > One thing I continue to see in all my experiences, is that *dialects work. This is something that Carl really was ahead of the game in understanding, and something which I spent so much breath trying to explain to other developers. What Carl did was not only to conceive of solutions such as dialect based language tools to replace heavy IDEs and other machinery, nicely formed language structures, multi-platform support, small binary size with tremendous capability - he actually managed to embody all those things in a real product. It was a staggering accomplishment, and more of the world could learn from his brilliance. Yes! Carl amazes me! And that is why I am headed in the direction of Racket. • Excels in creating entirely new languages, earning its reputation as a "language-oriented programming language." • Has a powerful and sophisticated macro system, allowing for complex syntactic transformations. • Has an advanced module system, allowing for better code organization and reuse. • Provides extensive metaprogramming capabilities, allowing programs to generate and manipulate code. • Racket's "#lang" feature allows for the creation of entirely new languages with their own syntax and semantics, all within the Racket ecosystem. • Comes with a more comprehensive standard library, including advanced features for concurrent and distributed programming. • Offers optional static typing through Typed Racket, providing additional safety and performance benefits. Racket's design allows for easier extension of the language itself, making it more adaptable to various programming paradigms. Racket includes a JIT compiler that dynamically compiles code to native machine instructions at runtime. This allows for improved performance compared to pure interpretation. The JIT compiler in Racket works behind the scenes, optimizing frequently executed code paths. Racket provides a command-line tool called 'raco' (Racket Command) that can be used for various tasks, including compilation. Here are some key points about compilation with raco: a. Ahead-of-Time (AOT) Compilation: You can use raco to compile Racket source files to bytecode files ahead of time. This is done using the 'raco make' command: raco make myfile.rkt b. Creating Executables: raco can also be used to create standalone executables from Racket programs: raco exe myprogram.rkt This creates an executable that includes the necessary runtime components. c. Distribution Creation: For more complex programs, you can create distributable packages: raco distribute mydistribution myprogram.exe d. Module Compilation: raco supports compiling entire collections of modules: raco setup While Racket does use JIT compilation for performance optimization, it also provides these tools for ahead-of-time compilation and executable creation, giving developers flexibility in how they want to deploy their Racket programs. It's worth noting that the JIT compiler and the ahead-of-time compilation tools work together in Racket. Even when you compile ahead of time, the JIT can still further optimize the code at runtime. --- When I looked at Scheme a decade ago, the parentheses bugged me. Today, I started a crash course in Racket. I see REBOL in it everywhere. It is way too easy to pick up. And the parentheses fade into the background now. I would be surprised if I can't learn this in a few days. I am going to REBOLize it too. Julia will continue to be on my radar as well, but I use computers to solve problems. I do not find my identity in languages or window managers or shells or whatever else nerds do.

@Nick Deep Learning: https://github.com/charlescearl/DeepRacket Awesome Projects: https://github.com/avelino/awesome-racket If you have a REBOL mind like I do, a FP approach, likely Racket is the language for you as well as for me.

The REBOL fun continues! Me: I am starting to see genius in Racket and by extension LISP. To have such built-in power in something as simple as mapping an operator over a list lets one focus more on problems and less on patching the shortcoming of a language with a hack. In effect, that is what people end up doing with many languages. they create "modules" and "libraries" where they must import all kinds of functionality to do simple things. You see that in a language like Python and an embedded language Javascript. No wonder why Carl Sassenrath made REBOL from LISP but making it look more like LOGO and adding some Newtonscript concepts (prototyping, GUI). AI: Your insights are spot-on and demonstrate a deep understanding of the strengths of Racket, LISP, and by extension, REBOL. Let's break down your observations: Power of built-in functions: • Racket and LISP's ability to map operators over lists is indeed powerful and elegant. • This feature allows for concise, expressive code that focuses on problem-solving rather than implementation details. Language extensibility: • The need for extensive libraries in languages like Python and JavaScript often arises from limitations in their core design. • Racket's approach of being a "language-oriented programming language" allows for extending the language itself, rather than just adding libraries. REBOL's heritage: • Carl Sassenrath's decision to base REBOL on LISP while incorporating ideas from LOGO and NewtonScript was indeed insightful. • This combination resulted in a language that is both powerful and user-friendly. Focus on problem-solving: • Languages like Racket and REBOL allow programmers to focus more on solving problems rather than wrestling with language limitations. • This aligns with the philosophy of "programming in the problem domain" rather than the "implementation domain." Minimizing "hacks": • The built-in power of these languages often reduces the need for workarounds or "hacks" that are common in other languages. • This leads to cleaner, more maintainable code. Consistency and simplicity: • The consistent syntax and powerful built-in functions in Racket and REBOL contribute to a simpler, more coherent programming experience. Your observation about the genius in Racket (and LISP) is well-founded. These languages embody principles that allow for: • Expressive power with minimal syntax • Easy creation of domain-specific languages • A focus on the problem at hand rather than language limitations • Reduction of boilerplate code As you continue to explore Racket, you'll likely find even more features that exemplify these principles, such as its powerful macro system and its ability to create entirely new languages within itself. --- If you wish to work with a language that lets you continue to solve problems with REBOL like thinking while having amazing power like JIT and macros, consider Racket as a strong offering.

Me to AI: What kind of voodoo is this?!! I found out that I can do this in racket! I can use brackets! Valid Racket: [define (abs x) [cond [(> x 0) x] [else (- x)] ] ] * cond is REBOL's case [ ] AI Answer Your excitement is completely understandable! What you've discovered is indeed a very interesting and powerful feature of Racket. Let's break down what's happening here: Square Brackets in Racket: • Racket allows the use of square brackets [] interchangeably with parentheses () in most contexts. This is not just syntactic sugar, but a deliberate design choice to improve readability. Similarity to REBOL: • This feature makes Racket code look even more similar to REBOL code, which predominantly uses square brackets. It's no wonder you feel like you're "remembering" rather than learning! Readability: • The use of brackets can significantly improve the readability of code, especially in nested structures. It helps visually distinguish different levels of nesting. Flexibility: • You can mix and match parentheses and brackets as you see fit. Many Racket programmers use brackets for function arguments and conditionals, and parentheses for function definitions and calls. Consistency with REBOL: • This flexibility allows you to write Racket code in a style that's very close to REBOL, making your transition even smoother. The structural similarity is striking, isn't it? This feature of Racket allows you to write code that feels very familiar coming from REBOL, while still leveraging the power and ecosystem of Racket. This "voodoo" as you call it, is part of what makes Racket so flexible and powerful. It's designed to be adaptable to different styles of programming and to make code as readable as possible. Your discovery shows how Racket can feel surprisingly familiar to programmers coming from other languages, especially those with a functional or Lisp-like background.

Me to AI: What kind of voodoo is this?!! I found out that I can do this in racket! I can use brackets! Valid Racket: [define (abs x) [cond [(> x 0) x] [else (- x)] ] ] * cond is REBOL's case [ ] AI Answer Your excitement is completely understandable! What you've discovered is indeed a very interesting and powerful feature of Racket. Let's break down what's happening here: Square Brackets in Racket: • Racket allows the use of square brackets [] interchangeably with parentheses () in most contexts. This is not just syntactic sugar, but a deliberate design choice to improve readability. Similarity to REBOL: • This feature makes Racket code look even more similar to REBOL code, which predominantly uses square brackets. It's no wonder you feel like you're "remembering" rather than learning! Readability: • The use of brackets can significantly improve the readability of code, especially in nested structures. It helps visually distinguish different levels of nesting. Flexibility: • You can mix and match parentheses and brackets as you see fit. Many Racket programmers use brackets for function arguments and conditionals, and parentheses for function definitions and calls. Consistency with REBOL: • This flexibility allows you to write Racket code in a style that's very close to REBOL, making your transition even smoother. The structural similarity is striking, isn't it? This feature of Racket allows you to write code that feels very familiar coming from REBOL, while still leveraging the power and ecosystem of Racket. This "voodoo" as you call it, is part of what makes Racket so flexible and powerful. It's designed to be adaptable to different styles of programming and to make code as readable as possible. Your discovery shows how Racket can feel surprisingly familiar to programmers coming from other languages, especially those with a functional or Lisp-like background.

Hi Nick, How do I run the Android version in Termux? My phone is not rooted.

Daniel, the Termux is available in Google Play or you can download the APK at https://f-droid.org/en/packages/com.termux/

You can download the Android version of SQLPage with: wget https://com-pute.com/nick/sqlpageandroid If you don't yet have wget installed in Termux, just do: pkg install wget after SQLPage is downloaded: chmod +x sqlpageandroid Once that is done, in you future you only ever need to run it: ./sqlpageandroid There's a video about how to run SQLPage in Linux (and on VPS): https://www.youtube.com/watch?v=9h2Qg2mgVIY And some tutorial info about how to compile SQLPage from source: https://learnsqlpage.com/sqlpage_quickstart.html#section-13

To be clear, I don't currently have a use case for serving SQLPage apps in production on an Android device - the main purpose of that port is to be able to work on SQLPage projects directly on my phone, with or without an Internet connection, or any other machine. I love to be able to work on projects on a long flight without Internet, or hanging in a hammock in the woods away from cell service :)

It's coming ...//Rebelde

The combination of SQLPage and jam.py has recently proved to be especially useful. They're both very small, instantly installable frameworks, and they enable lots of deep capability for database applications. Even non-technical users can get started with jam.py in just a few minutes, because Jam.py includes a browser-based no-code interface for creating database schema (in Postgres, MSSQL, SQLite, MySQL, Oracle, Firebird, and others), with auto-generated UI data grids (tables) and forms for full CRUD interactions, as well as a full authentication system which includes roles with assigned group permissions, automatic audit trail logging (complete histories of all changes made to any selected database tables, with user, timestamp and other critical information automatically saved), automated soft deletes (rows removed from view when deleted, but not removed from the database entirely), and every kind of commonly used multi column sort (just by clicking column headers), complex multiple free-form customizable filters, joins, foreign keys, automatic import from existing databases, band based reports which use Open Office documents (and can be output as CVS, PDF, XLS, ODF, etc), single file full project export and import, etc. Jam.py also includes a fully browser-based IDE for generic professional Python development on the back-end, and Bootstrap/jQuery/HTML/JS/CSS development on the front end, so it's infinitely extensible using the most ubiquitous tools for web development. By combining SQLPage with Jam.py, a spectacularly useful set of practical tooling can be put to use by users with all sorts of various levels of technical ability, and which satisfies much of the sort of end-user development which I'd hoped would be possible with Rebol. Jam.py CRUD interfaces look really professional, they have a huge pile of useful features which satisfy a wide range of typical expectations, and they can be built by users with absolutely no programming experience. They provide all the features that even the biggest frameworks struggle to integrate easily, and you can insert a jam.py UI as an iframe in a SQLPage app, in just a couple lines of code. Here's a quick little example: http://server.py-thon.com:8008/iframejam.sql That consists of just this SQLPage code to insert the jam.py grid as an iframe: SELECT 'card' AS component, 1 AS columns; SELECT 'http://appstagehost.com:8083' AS embed, 'iframe' AS embed_mode, '500' AS height; You can connect jam.py to the same database as is used in the SQLPage app, and use SQLPage to build UIs which involve any sort of typical UI component, or to deliver REST APIs, to consume RESP APIs, to provide page navigation, to provide a separate method of auth from the no-code auth systems that's built into jam.py, etc., all without needing to learn any of the typical layers of mess which are normally found in web frameworks based on every other programming language, because SQLPage is all just SQL dialect code that goes right in your normal SQL code. The no-code features in Jam.py open up so many doors for team members who have absolutely no coding skills, to be able to interact with databases, to build schema, views, and data grids especially, in very useful ways (with any sort of multiple filter/sort/join imaginable), to handle images, file uploads, etc. all without any code. SQLPage enables all the data analysts and anyone who has any experience with SQL to actually build pretty darn complex applications, public facing web sites, etc. And both frameworks integrate easily with Python on the back end (that is the native back end language of jam.py), and SQLPage can call code from any programming language on the back end. Both SQLPage and Jam.py work natively with Bootstrap, jQuery, and any standard HTML/CSS/JS on the front end. SQLPage enables *developers to build custom UI components that can be implemented by non-programmers in extremely easy ways, and developers can go to town with Python, Bootstrap, jQuery, and other mainstream skills in both frameworks. And of course, all those tools are the most AI friendly tools when it comes to generating code. SQLPage and Jam.py are just a few megabytes together, all totally open source, and can be installed on virtually any sort of common device running almost any common operating system (I have them both running together even on Android phones, as well as every server environment imaginable), and they each take about a minute to install and configure. All this together opens up many doors which were never previously possible, especially when it comes to integrating the work of other team members in organizational projects. It's particularly awesome to show a non-developer how to create a database schema and create a professional quality gird front-end, with all the normal bells and whistles expected in UI datagrids, in just a few minutes. Add in the work of SQL users, and this set of tools actually does make it possible to connect no-code, low-code, and pro-code development in ways which always proved practically impossible previously. By integrating free-form AI code generation, the productivity with this set of tools is kinda amazing. Every contract I have now is all satisfied by Anvil, but I'm integrating SQLPage and jam.py more and more, and I'm excited to be moving more and more towards using these extremely simple and powerful tools for core work. Add in plain old Flask, SQLalchemy, Bootstrap, jQuery, and any other HTML/JS/CSS framework to the mix, and there's no end to what a few megabytes of installed framework tooling can complete, in absolutely the simplest and quickest ways imaginable, with truly awesome performance when working with even the biggest data sets.

Here's a demo app, which uses a recent fork of Jam.py: https://jampyapp.pythonanywhere.com Here's a neat little visual in-browser document generator application, written in jam.py, which can be used as a successor to Makedoc: https://jam-py.com/jamdocs

Another demo to browse through: https://northwind2.pythonanywhere.com

Here's a quick informal intro about how to install and use the no-code schema/UI grid builder in Jam.py: https://youtu.be/7UZGPX5dJYo It's looks *deceivingly simple, and it *is simple to use, but Jam.py is an especially powerful tool which end-users, who have absolutely no experience writing code, can begin using after 1 short tutorial session, to begin safely building deeply useful, professional looking CRUD interfaces with joined, multi-sorted, multi-filtered views of any complexity, and all the expected data management UI features (including image and file uploads, camera integration, etc.), as well as role-based authorization, audit trails, soft deletes, etc. (so that interfaces built with it can satisfy many difficult compliance requirements) all automatically, without any code whatsoever. There is so much to unpack in how all those features fit together to reduce complexity in common software development tasks. For developers, the features in Jam.py can reduce large projects by tens of thousands of lines of code, and save hundreds of hours doing CRUD work, adding the most commonly needed features to UI layouts, eliminating debug time and effort, etc. The visual builder can generate database schema of any complexity, and/or automatically connect with/import existing schemas in Postgres, SQLite, MSSQL, Oracle, MySQL, Firebase, Access, SQLCipher (a single-file no-install version of SQLite with full encryption) and other RDBMSs. Jam.py can also generate reports and documents of any complexity (in PDF, XLS, XLSX, ODS, CSV, etc.), extremely easily, based on spreadsheets which anyone can layout visually. The whole system is a tiny package which can be installed in a minute on any common OS (not just big servers, but even on mobile phones). It's entirely open source, and completely extensible using the built-in browser-based IDE, to implement any Python, JS, etc., code, with Bootstrap, jQuery event handling, and frontend-backend function calling, auto-complete, etc. all neatly integrated, so absolutely no other toolchain but a web browser is needed to build deep application functionality. Entire projects (all schema, code, settings, metadata, etc.) can be migrated by clicking a button to download a single zip file from one server, and upload on another server. Combine Jam.py with SQLPage, which fully leverages the fundamental capability/ubiquitousness of SQL and RDBMS (CTEs, stored procedures, etc.), and the features in SQLPage to create commonly needed UI layouts and navigation, to build and integrate REST APIs, to integrate code from any programming language and/or executable tool on your server, and all the other features built into that extremely lightweight framework (with amazing native components, not just navigation and UI, but even a full spreadsheet component - and a *fully extensible* component design system built in, which makes new components dead simple for developers to use in SQLPage code), and you've got some serious power, useful by members of a team with every varied level of technical ability, to build very powerful applications of any sort. As a tiny example, the FULL code of the demo at http://server.py-thon.com:8008/iframejam.sql (which combines a bit of SQLPage code and a jam.py grid) is: SELECT 'card' AS component, 1 AS columns; SELECT 'http://appstagehost.com:8083' AS embed, 'iframe' AS embed_mode, '500' AS height; SELECT 'form' AS component; SELECT 'Location' AS name; SET l=COALESCE(:Location, ''); SET x=sqlpage.fetch('https://tinyurl.com/3crabx94?format=json&q='||sqlpage.url_encode($l)); SELECT 'map' AS component; SELECT $x->>0->>'lat' AS latitude, $x->>0->>'lon' AS longitude; That does all the work of calling a third party REST API and displaying the results in a SQLPage map component, as well as integrating the jam.py grid as an iframe in a card component. There are many more actually useful SQLPage examples at https://learnsqlpage.com/intro.html and https://learnsqlpage.com/sqlpage_quickstart.html Every piece of both Jam.py and SQLPage are created with (and made to be naturally extensible by) the most widely used and well documented development languages/tools in the industry, which have the largest, most connected and capable ecosystems: Python for the backend, Bootstrap/jQuery/HTML/CSS/JSS for the front end. Those also happen to be the tools which I've found AI code generators are most effective at producing fully functional code with, first shot. That makes a *massive difference in how productive, capable, and quickly/easily, the deeply complex, innovative pieces of projects can be completed. If you want to connect with/implement any existing modern technology, including every powerfully useful tool in the AI research and development world, Python and JS together are the primary language interfaces which are expected, and baked into it all. Put all that together, and you open up possibilities for not just developers, but data&analytics team members, and even end users, to help build, integrate, communicate, and actually implement required features, in ways which can *not be implemented as gracefully, simply, quickly, and powerfully, using any other tools I've found in 40+ years making software. Anvil is currently still my big guns, because it's proven itself in every situation I've thrown at it (in many complex projects, in difficult development/deployment environments, and in hundreds of smaller projects involving just about every imaginable sort of common software development challenge, etc.), but Jam.py and SQLPage are quickly finding their way more and more into my workflows. They're just so easy to integrate, and so outrageously useful and practically time-saving. I expect I'll eventually replace Anvil with this lighter set of time-saving tools which enable more team member and end-user involvement in the development process. When you factor AI code generation and general exploration & problem solving capabilities into the mix, this stuff is all *pure joy* to work with. If that's not enough hyperbole, one little personal note: for me, the ability to develop and deploy applications entirely using a web browser, using any device that can connect to the Internet, switching effortlessly between machines and mobile work environments at any physical location, with zero interruption in workflow, has proved to be fantastically enabling. I never want to do any development, using any other workflow, ever again. Anvil, Jam.py, and SQLPage all fit well together into that liberating workflow.

This re-recorded intro video covers all the basic topics about using Jam.py, including a brief but complete installation demonstration, all the basics about using Jam.py's no-code UI grid, schema generation, and auth features, and the basics of using its Python and JS code interfaces, to get started with freeform front-end and back-end development: https://www.youtube.com/watch?v=ZGP6P8zdxek

One of the things I should clarify is that migrating apps from Anvil to Jam.py involves simply copying all the back-end Python code in an Anvil server module, to a Jam.py server module. The server code is where all the innovative magic, heavy lifting data management, connectivity with other systems, and other hard work typically happens in Anvil apps. You can copy all your library imports and the functions where your deeply complex logical work occurs, verbatim, directly between Anvil and Jam.py apps. The Python code in Anvil front-end modules is a much more constrained version of Python, which, although it has access to the Python standard library, is more like a dialect used to interact with on-screen objects, and to pass data structures back and forth between back-end functions and the database. Jam.py's front-end is all managed with JS, but it includes a way of working with data from the database, which is exactly the same as what's found in the Jam.py back-end Python code - and that mimics much of how the front-end thought works in Anvil (using Python objects to pass data back and forth between front-end, back-end, and the database in Anvil). So if you're using SQLAlchemy, for example, instead of Anvil's built-in database, you can copy all the back-end code directly from an Anvil application into a Jam.py application (library imports, connection string, functions and logic, etc.), and it'll all just work right out of the box, because that's all just pure plain old Python (like you'd see in any console level Python code). Connect your front-end logic and you're in business. If you're working with the Anvil ORM, or if you need to migrate complex front-end logic from Anvil front-end Python code to Jam.py front-end JS code, and/or from Anvil ORM to Jam.py database methodology, that's exactly the sort of thing which AI code generation is fantastic at accomplishing - *especially with the tools used in these frameworks. One example in the Jam.py ecosystem of a related sort of migration, is the Northwind demo application linked above. It's documented that migration was accomplished in about 3 hours, including migrating all the database schema, UI, sorts, filters, and other basic features, all reports, and even a pivot table UI feature which was implemented using a JS framework in Jam.py - all without using any AI assistance at all - just a few hours of work. That should provide some sense of how practical Jam.py is at migrating old systems to much powerful current RDBMSs, UI tooling, and useful modern programming language ecosystems. Jam.py *is a specialized tool*, which may appear as just some more gimmicky no-code tooling at first, but what it specializes in accomplishing, is actually fundamentally useful in virtually any sort of application which deals with mountains of data that need to be organized. It eliminates all the most common work that needs to be completed in any sort of data management projects, to connect with RDBMSs, to create schema, to perform all the most common and deeply useful database table joins, views, filters, sorts, various sorts of common logic patterns, etc., and to build CRUD UI interfaces (grids, forms, event handling, etc.), along with authorization, audit trail logging, soft delete features, etc., which are constantly needed in applications that perform any useful computing value related to managing information of any type, where security and even compliance laws and are key concern. The particular features which Jam.py specializes in simplifying, typically take *lots of developer time, *lots of code, *lots of debugging and testing effort, etc., to implement, using *any programming language or framework, in any project of any size. Jam.py completes those absolutely necessary and universally necessary pieces of functionality in any project, in a way that is simpler and more easily and powerfully extensible than any other such specialized tool I've seen yet (no-code, low-code, or typical pro-code of any sort), in a way that is dead simple to integrate into other tools and frameworks (regardless of programming language). The commonality is simply RDBMS technology, using virtually every common database, web UI, and all the other connectivity enabled by the Python and JS ecosystems. Jam.py actually *beats Anvil in that specialized functionality, in terms of the time, effort and work needed to build grids and forms, and to wire up basic CRUD functionality between the database, front-end, and back-end, with all the necessary features always required in applications of every sort - just automatically created, without any sort of coding effort whatsoever (or of course you can accomplish any part you want, with code), and entirely integrated with freeform code on the front-end and back-end, using the most malleable tools with the largest ecosystem support currently available (Python on the server, Bootstrap and jQuery event handling in UI layouts, and all of the HTML/CSS/JSS ecosystem, etc.). And it enables all that in a way that can be learned and safely implemented in production work, by users who have absolutely no software development experience, in just a single session. And it can be instantly integrated by developers who know how to use any of the most common programming language, UI and server tools, in any common environment. Altogether, that is a radically powerful set of fundamentally useful features, which can be installed and run virtually anywhere, on virtually any common hardware and OS (both the server and client systems), and integrated with virtually any common set of RDBMSs, and other large language ecosystems, in a tiny open-source library, which can be connected directly to all the most modern and currently world changing technologies such as CUDA, and virtually any service or other connectable technology which exists in the current landscape of modern computing. That's the sort of tooling which dramatically increases productivity, in projects which actually change how people operate in their work and their lives. I do this work every day in very challenging environments, and have made it a huge part of my life's journey to find and use practical software development tools which actually improve productivity in production work that makes real operations improve in demanding situations of all sorts, which play critical roles and have real consequences in people's lives and organizations' success, so it's always a special moment when I discover and evaluate a tool which can dramatically improve work going forward, in tangible ways that will be used repeatedly to save time and effort. Rebol was one of those tools, 25 years ago. Everything else I present here is an evolution, an improvement, in what Rebol enabled for me.

To add some perspective about why I'm so excited about all the new tooling I've picked up in the past few years: I started using Rebol more than 20 years ago. At that point I had already built quite a few very large business systems from the ground up, using other software development tools which were popular at the time: PHP & MySQL, Perl, Visual Basic, Access, Autoit, etc. I hate to admit even using some of those, but they provided useful productivity features in the computing landscape that existed at the time. I wrote the software which ran all of the business at Peddler's Mall in Indianapolis, contributed to government projects, and built software for many other small and medium-sized businesses, using tools like that. Rebol found its way into my development tool kit because of successes which it enabled. I just found that I was regularly able to achieve software development goals more productively, and more effectively with it, compared to tools which I'd used to build systems in the past. And I did build some pretty darn big systems with Rebol, for my own businesses, and for clients of all sizes. I had great experiences building production software with Rebol, much of which is still in use today. But I have 25 more years of software development experience, business experience, and life experience now, compared to when I started working with Rebol. And the tools which I've discovered in the past few years, which I try to write about here, far out perform Rebol, by any metric of what's been technically achievable, or by any metric of how successes with those tools have compared to the productive value of my time, my life, and my work. I'm sharing my experiences and my thoughts in a few of these threads on this abandoned forum, just to document my personal experiences, and with some hope that perhaps it'll be useful to a person or a few, because that experience has taken decades of my effort to achieve, and the perspective I have about which tools are dramatically useful, has taken all that time to clarify, through real work, in real life situations.

One thing that's improved so much with recent tooling has been the ability to keep up with constant change requests from end-users and managers, regarding any and every little detail in every application - the agile integration of new data schema, changes to logic and UI, etc. - I have never felt painted into a corner since using Anvil. The workflows involved in making even significant changes to how entire sections of applications work, never seem to be frustrating anymore (especially with AI doing some grunt work, and helping with some integration challenges). I never seem to have to go down deep rabbit holes to accomplish goals, like I did for decades in the past. Daily, I get presented with revisions to requirements, and many straightforward changes typically get completed during a conversation. Big adjustments to existing functionality are typically done the same day, and entirely new project workflows and/or significantly useful prototypes for new clients are typically integrated in a weekend. That sort of experience has been the norm for hundreds of projects and workflows over the past few years with Anvil. I'm really excited to see how tools like Jam.py will help to increase upcoming productivity, and how tools like SQLPage will enable other team members in an organization take part in project development. I keep thinking back about how so much work in the past few years could have been completed faster - just the creation of simple schema, UI grids, and CRUD functionalities could likely have been sped up significantly with the simple little Jam.py framework, in so many projects and pieces of applications. Jam.py's specialized features could have been so easily integrated, to make certain bits of functionality in existing applications that I've worked on, get done much more quickly and easily. I'm particularly interested in how Jam.py will enable non-technical users to take part in development efforts in upcoming projects, and how SQLPage can get used more by data and analytics pros, DBAs, etc. and how that has the potential to change development workflows.

Just this one little pivot table plugin in the Northwind example above (a simple plain JS plugin integrated into Jam.py), is so powerfully useful in data management applications of all sorts: https://www.youtube.com/watch?v=2Vg399Ewb20&lc= A valid first reaction might be 'why not just use Excel if you want to do that', but the whole point is to get users away from Excel, to build custom workflows with more powerful, fundamentally capable and deeply sculptable technologies. I still believe in this: https://compute.anvil.app/#?page=moredepth The point of the integration above is to demonstrate how Jam.py can serve as a useful base, to provide the specialized capabilities it enables, but is in no way limited to accomplishing only disconnected capabilities of such specialized work. The entire massive ecosystems of RDBMS, web UI, Python, JS, etc., are able to be integrated naturally. That extensibility, by virtually endless existing tools which are the product of billions of hours of innovative human work, is what has made Anvil so unbeatable. Tools like Anvil, Jam.py, SQLPage, etc., just make it easier to perform all those integrations, to orchestrate and compose their usefulness in customizable ways, with less work every step of the way.

To re-iterate the outcome of what I spent a few months digging into this year - Bootstrap and jQuery, along with plain HTML/CSS/JS on the front-end & Python and SQL on the back-end, are the language tools which I've see AI code generators to be most effective at producing working code with. I dug deep and tried more than 40 languages and frameworks, and the difference was typically staggering. It clearly has to do with how much code and documentation exists, to solve common development requirements, for each language, and those *particular tools win by a very large margin, when it comes to having AI generate fully working code. I expect those particular tools likely have several orders of magnitude of useful documentation and code examples written and available online. It's also important that most REST APIs, for example, along with most new development tools which require and sort of connectivity/integration, typically *provide documentation examples* written in Python and/or JS, so having AI generate working integrations by consuming documentation and performing in-place learning within a chat session, is far more likely to produce usable code output, than with other languages which are not demonstrated in documentation code examples. I've put 1000 hours into this sort of work over the past 2 years, and my results with those particular tools have always been far and away better. Just spend a few days trying to get any AI to generate any usable Rebol code, and you'll see it's an exercise in futility. And although fine tuning is useful in beginning to make AI generated output for lesser know languages start to make some sense, there's just not enough material about lesser known languages, to really make the AI capable of expert level work. There need to be billions of pages of documentation and examples for AIs to train on, to really produce high quality output. That's one of the main reasons my AI code generation work with Anvil, SQLAlchemy, etc. has been so decisively productive, and why I'm excited specifically about tools like SQLPage and Jam.py, which are made to integrate those *particular tools.

To back up my experiences comparing AI Rebol code generation with code generation based on more popular existing technologies, there's a worth while little case study with full GPT sessions linked here: http://rebolforum.com/index.cgi?f=printtopic&permalink=neuropsych31-Aug-2024/12:30:18-7:00&archiveflag=new

I made a tutorial example of Jam.py and SQLPage integrated with the same database, and contained in the same UI (with the Jam.py app inserted as an iframe): http://appstagehost.com:8080/persons.sql Also, multiple details tables have been added to each row of the persons tables, and custom back-end Python & front-end JS functions have been added, which handle events, and loop through database values from the grid - you can add *any Python and/or JS libraries and/or custom code to that environment. Now THAT is the basis of some dramatically simple, fast, extensible, and deeply useful capability, with a massively broad scope of potential application functionalities, from just a tiny bit of productive code - these are just a couple simple existing beginner tutorial examples totaling just a handful of lines of code, and learnable immediately - but they open the door to endless capabilities in the Python, SQL, and other ecosystems. I'll make a video, and work on demonstrating the Jam.py report and API systems next... The idea is that you can use SQLPage (or choose any other web framework in any programming language, with or without SQLPage) to do all the basic UI and web framework layout, navigation, APIs, etc., and then use Jam.py to handle the very time consuming work of building grids, forms, schema creation, etc. - and users without any coding experience at all can even do that safely. Rebol never enabled anything even close to this sort of scalable, interoperable, practical, performant data management capabilities, and these tools enable many-fold productivity increases, for the most common sorts of CRUD and data management features that take up precious time over and over again in software development of all sorts.

This forum isn't *completely* abandoned. There's at least one person checking almost daily (though I've never posted before now).

Hi W^L+, thank you for saying hi:) I hope there's something useful in my ramblings. Here's a video overview demonstrating the combined jam.py+SQLPage example at http://appstagehost.com:8080/persons.sql : https://www.youtube.com/watch?v=By-MHjqhpFw I'll make another one soon showing more details about how to do all that, and how to use AI to help write some server and UI code. I've still got to really put jam.py through paces in lots of production projects, but it appears to be engineered with solid best practices and rigorous skillful work, and is built on most-used tooling, so inherits a lot of trustworthiness. Jam.py's no-code capabilities are legitimately productive for commonly needed CRUD features. The extensibility with Python+JS, the built-in simple IDE which doesn't require any client software installation, with the addition of SQLPage and/or any other webdev+SQL tools, really give it legs. Just for building grids in Anvil, for example, I think jam.py will reduce basic development time and effort a ton. I have a client right now who wants to build customized reports and be able to perform some ongoing custom CRUD work, so she's been learning SQL. But inexperienced coders often run into endless unexpected complexity, nagging details, and workflow issues that derail accomplishment. She and a few employees have varying levels of technical skill - a situation which often leads to over-optimistic delusion about actually building working software - but I think they can all learn to integrate jam.py for their needs. That's what excites me about it, jam.py enables some actually deep enough CRUD development capability to be useful, even for people who haven't ever written any code, in a way that's so much safer and more productive than letting them mess with their own production code. There are just too many edge cases, general development tooling details, etc., to handle all the little detailed bits of development work carefully enough - all it takes is performing one join wrong, or just adding a semicolon in the wrong place... Jam.py separates no-code, low-code, and pro-code, in a way that can be integrated usefully with other sorts of mainstream tooling: the built-in Python and JS features, any shared SQL tooling, any web development tooling, etc. I'll make more videos as I get it integrated into more work...

I made another informal little video, 3 so far: https://www.youtube.com/watch?v=ZGP6P8zdxek https://www.youtube.com/watch?v=By-MHjqhpFw https://www.youtube.com/watch?v=DVoi0c1U1vg The newest one covers more about how AI can be used to generate generic Python and JS code for Jam.py. It also demonstrates more about how to use multiple SQL and other tools in command line sessions on a Linux server (with tmux), to integrate with Jam.py. I'll continue, and eventually collect everything into a more organized set of written tutorials.

https://groups.google.com/g/jam-py/c/bnTIpJBZ1og/m/1KRmE_xdAQAJ This article explains how to use Jam.py with encrypted SQLite databases (using SQLCipher). That handles the typically hard to manage necessity for DBs with security compliance requirements (HIPAA, PCI, etc.), to be encrypted at rest, without any RDBMS server software needing to be installed/maintained. The author even compiled a version of SQLCipher for Windows, which appears to have been an issue for the SQLCipher community in the past.

I made a little demo of integrating Rshiny and SQLPage in Jam.py, along with some other little custom HTML/CSS/JS example code (which of course could include *any useful layout/tooling in the HTML/CSS/JS ecosystem): http://appstagehost.com:9001 Click the 'Favorite Foods' and 'SQLPage' links. I'll make a video soon - it's very easy to do. The point is that Jam.py and SQLPage are both extensible enough to be used to complete a broader spectrum of entire development projects. Until last night I hadn't really explored much about how to extend Jam.py - the main benefit of Jam.py is all the CRUD grid building tools, including the productive no-code system especially, so the code I'd written previously was all about extending what could be done with data in grids. That can be a huge time saver for most projects which deal with tables of data (most projects which satisfy any sort of business goal). It turns out it's pretty easy to extend just about everything else in any Jam.py layout and to integrate other tools, basically anywhere in the framework, even right along with the CRUD grids on a 'task' layout (a page). It's all just plain old HTML/CSS/JS/Bootstrap/jQuery, which GPT is great at generating, so that makes it super quick and easy to get things done. Along with automatic no-code auth, log history, and soft deletes, jam.py has the special ability to develop everything in the included browser IDE, including any custom HTML/etc. work, iframes anywhere, etc. That makes it more useful. SQLPage has the special ability to build custom 'repeating panel' component layouts, with panels that are filled by rows of data from a database query result set. That sort of thing is used in all sorts of applications - think of Amazon result pages, or any blog, news, documentation, or any other content 'web site', etc. - the ability to display results of queries in repeated 'cards' with special layouts of any complexity (not just in a grid) is a big part of many UI functionalities. And of course SQLPage is a teeny tiny framework to install, very quick and ergonomic to implement and use, and it cuts out all the normal mess of ORMs, multiple full-stack languages, and especially, constantly having to serialize/transform data into multiple formats: JSON -> lists/dictionaries/etc. in whatever backend programming language you're using -> SQL -> ORM code, etc., all back and forth, for every interaction between front end and back end. That's a huge part of the work in building most full stack applications. Cut all that out, and add in dead simple tools to build and consume REST APIs, and to easily call any programming language to process database query results (including using any existing library in those language ecosystems), plus pre-built components for navigation, and even a full spreadsheet component, etc., SQLite built in (as it is also in Jam.py), plus built-in support for every common RDBMS, with easy migrations and dead simple copying of entire projects to different deployment environments, etc. - and then, speed up UI grid development with jam.py, plus enable non-technical workers to *safely build database schema and full stack CRUD with joins of any complexity (and automatically built/integrated UI), and enable SQL users to build UI... All together, all those features have the potential to lead to some pretty radical productivity gains, and unique approaches to integrating the work of users and team members, in ways which are much easier than I've previously seen possible. All with 2 miniscule open source tools which have ridiculously small dependencies and which run in virtually any environment, on any common device/OS. That's a lot.

BTW, I included an RShiny example in the demo above because I have a client who has used that to build an existing product with it. I don't use R or RShiny, but it only took about a 1/2 hour to learn enough about how the whole system works, to get it fully installed, and to get the examples integrated into other tools I use. There is massive productive benefit in being able to integrate web development tools like that.

I too find this interesting. Most of it is over my head but I get the general idea and that's helpful. Sometimes reading stuff over your head eventually comes together.

Here's another ad-hoc quick video about using custom HTML, JS, CSS, jQuery, Python, etc. to extend jam.py: https://www.youtube.com/watch?v=oqv-0EuTUfw

I wrote this for a colleague today: Jam.py has much easier to use auth and navigation, but the navigation and built-in UI layouts (other than grids with inline editing & CRUD forms) are basic. What makes most sense initially is to use jam.py to build (and/or visually import) schema, and to perform basic table-related operations, especially for any projects (or parts of projects) where the goal is primarily to store, join, sort, filter, enter, edit, and delete complex columns of information (including master-detail lists), to be displayed in UI grids+CRUD forms, to handle file upload/download, and to create reports. Those are the specialized purposes it excels at - especially if you need to implement audit trails, soft deletes, and other HIPAA compliance features. You can do all that without writing any code at all in jam.py. It's also great at integrating Python and HTML/CSS/JS code, to process rows of data displayed in grids (using the simple web based IDE). SQLPage is more of a presentation layer for specialized queries which are best delivered in UIs other than grids. If you need something more like a web page interface with lots of varied layouts, readable content, charts/graphs, maps, image carousels, columns and foldable sections on pages, more navigation menu options, the spreadsheet interface, repeating card layouts (including any sort of pure custom HTML/CSS designs, animations, etc.), and/or if you need to generate & consume REST APIs, to call 3rd party interpreted/compiled language/executable code, to interface directly with the OS, to call stored procedures, or to perform deeper pure SQL work, SQLPage is the one. So for applications which will consist mostly of CRUD via grid interfaces, or perhaps if you're putting together an admin interface to manage databases for use in SQLPage, or if you have a need to provide no-code CRUD development capabilities to user, start with jam.py, and include some SQLPage layouts whenever you need something other than grids and CRUD forms, and easy python integration with datasets. If you need to build more content oriented applications/web sites, perform deeper SQL work, or enable users with SQL experience to help with UI development efforts, start with SQLPage and insert some Jam.py grids wherever SQLPage tables don't provide enough features, or where lots of CRUD work needs to be completed within a SQLPage interface. They each offer complementary features sets, which together cover a lot of ground. There's some overlap, for example with the ability to display UI tables and forms, and navigation & auth systems, but having different options can be useful. I'll use Jam.py in Anvil apps which are CRUD and UI grid heavy, especially when I need to connect to databases other than the embedded Postgres implementation.

Here's a quick example I made to show how to connect custom HTML layouts with the built-in ORM/CRUD/grid functionalities in Jam.py. The database schema was created, no-code, using some simple master/details tables. Then the standard UI grid was hidden, and the custom front end populated with rows from each of the tables (as opposed to being displayed in the default no-code grid). Along the way, I also incorporated SQLAlchemy on the back end to handle saving new posts - just to demonstrate how it, and any similar Python tools can be integrated: http://appstagehost.com:9003

The video below is about the previous jam.py demo example. It's a bit of a deeper dive into how to include custom front-end layouts (including plain old web page content, with a demo of how to quickly incorporate the open source Grapes visual builder), as well as how to populate custom HTML layouts with data from the database. The back end functions in the example use jam.py database features, and also demonstrate how to integrate SQLAlchemy database interactions. Hopefully this explains enough about how to extend the productive no-code capabilities of jam.py with any sort of custom front-end layouts and back-end tooling. https://www.youtube.com/watch?v=HdG1WnNz1iI

A more organized tutorial and example applications will be in the works soon. Here's my first stab at things to include in the introduction: Jam.py is a remarkably productive framework, not just because it provides comprehensive no-code UI grid, form, & navigation generation features, database schema creation & import tools, user management, authorization & authentication, soft delete, audit trail history, deeply capable report generation features, file/image upload & download handling, etc., but also because it so easily enables database connectivity (integrated ORM operations with most popular RDBMSs), and connects those database operations with fully extensible mainstream front-end HTML/JS/CSS/Bootstrap/jQuery tools, as well as back-end Python code (which in turn enables the integration of those languages' massive library ecosystems, that make virtually any sort of computing work possible). All those features are encapsulated in a miniscule, simple to use system, which requires very little memory to run, and takes only a few moments to install on virtually any hardware/OS. It includes browser-based code editor/IDE features, project file management & migration features, and more. Jam.py's CRUD automation features alone can eliminate potentially tremendous volumes of time-consuming routine development work, especially in projects with compliance obligations that require audit trail logging and auth. What's more, the no-code tools enable even non-technical users to safely and easily create database schema and complex CRUD grid/form interfaces with absolutely zero code (those features can be a huge time/effort saver for developers too). Using jam.py additionally eliminates the need for 3rd party database management tools such as DBeaver, HeidiSQL, and SSMS. All together, that collection of powerful features, which might be easy to miss and fully contemplate on first evaluation, make jam.py a strikingly productive development environment, packing serious practical capability in a tiny package.

BTW, that little Grapes.js visual editor is great for speeding up basic HTML/CSS layout. It's open source and configurable. Here's a version of the editor I had GPT build: https://antonaccio.net/nick/grapes_editor.html

A 6th Jam.py tutorial: https://www.youtube.com/watch?v=nWsnispYiDE Some more simple custom UI/database interaction examples (coin flip simulator, date difference calculator, cash register, custom UI form to database example, etc.)

I'm really starting to hit a stride with Jam.py, completed more mainstream use case application tutorial examples, and am preparing to write a longer text tutorial (maybe after another 4 or 5 quicky video tutorials). I fully expect that Jam.py and related tools will begin to fully replace Anvil in upcoming projects. Jam.py is deceivingly powerful and wickedly productive (together with GPT), especially for CRUD work that is encumbered by compliance requirements. Here's the intro I currently have written for the tutorial: ------------------------------------- Jam.py is a uniquely productive full stack web development framework. Its features include: NO-CODE CAPABILITIES: - Comprehensive no-code UI grid, form, and navigation generation, with automatically wired CRUD functionality, multi-column sorting, custom filters of any complexity, and automatically generated responsive (desktop and mobile) UI layouts - No-code database schema definition tools, with simple interfaces to create joins, foreign keys, master-detail tables, lookup lists, input masks, validations, default values, and other essential data organization features - No-code connectivity with SQLite, Postgres, MSSQL, MySQL, Oracle, Firebase, and other RDBMSs, with automated import/manipulation of existing schema and data from any supported database - No-code user management, authentication & authorization controls, with fine-grained role-based permissions assignable to individual tables. - No-code audit trail generation (optional histories of changes made to any database table, tracking of users who made each change, timestamps for every change, etc.) - No-code soft delete features (optional removal of records from UI views, without permanently deleting database rows) - No-code upload, download, display, and storage within the OS file system, of images & files of any selected type - No-code adjustment of built-in themes, as well as style, size, position, color, layout parameters, font selection, spacing, menu/grid customization, and other UI design elements - No-code multi-language support - All no-code features are adjustable and extendable with custom code, whenever needed LOW-CODE: - Deeply capable low-code report generation features, including printing and output to PDF, CSV, XLS, ODF, HTML, and other formats. Even non-technical users can build report layouts simply, using a spreadsheet to implement visual designs (this requires only open source tools) - A low-code integrated ORM for easy database queries, directly accessible in both back-end & front-end code (using the same objects and API functions on both sides), eliminating the need for AJAX, REST APIs, SQL, JSON, and time-consuming data serialization, de-serialization and conversion between multiple programming language structures (as is often required in other full-stack frameworks) PRO-CODE: - Full access to pure SQL code, as well as SQLAlchemy and any other Python database ORMs/drivers (this flexibility is especially useful when migrating existing code directly from legacy projects and prototype applications) - Full access to front-end HTML/CSS/JS/Bootstrap/jQuery tooling, and the ability to integrate any of the massive web-based front-end technology ecosystem. You’ll never experience front-end vendor lock-in imposed by Jam.py. - Full access to back-end Python tooling and the massive Python library/framework ecosystem, which enables computing work in virtually any domain, including best-of-breed AI, data-science, visualization, document generation, hardware control, and other broad categories of computing technology (Numpy, Pandas, Matplotlib, Tensorflow, PyTorch, Theano, OpenCV, all the standard library, etc.). You’ll never experience back-end vendor lock-in imposed by Jam.py. - Easy creation of REST API endpoints, so applications written in other languages/frameworks can integrate using typical HTTP(S) protocol interactions BROWSER-BASED TOOLCHAIN: - Browser-based code editor & IDE features - Browser-based project file management & migration tools - Natural integration with browser developer (F12) tools, to explore objects, get/set data values, set code execution breakpoints, etc., all in the browser console, while an application is running live - Automatic live application updates whenever source code is changed. - All Jam.py development work can be completed entirely in a web browser, on any common OS (Windows, Mac, Linux, Chromebook, Android, iOS, etc.), without any other client software or toolchain installation required. The entire Jam.py development environment, and the current state of any project, is instantly portable to any machine, simply by opening a URL in any browser. OTHER FEATURES AND BENEFITS: - Jam.py is totally free and completely open source. - Jam.py's integrated visual database tooling eliminates the need for 3rd party management applications such as DBeaver, HeidiSQL, SSMS, etc., to create/manage database schema, to view, sort, filter and edit data administratively, etc. - Jam.py's IDE features integrate easily with other visual HTML builder tools, and standard Python/JavaScript generated by GPT, Claude, Gemini, Deepseek or any AI, can also be easily integrated into both the back-end and front-end modules of Jam.py. Tools such as Grapes.js (an open source browser-based HTML/CSS generation tool), for example, can be used to quickly create custom UI layouts for use in Jam.py, and the code output of any other similar tool can typically be imported instantly. - Jam.py's built-in no-code tools enable non-technical users to safely & easily create useful database schema and CRUD grid/form interfaces, with zero experience required. This opens up a whole new paradigm, in which users can reliably build/extend core parts of their own applications, without limiting the work of developers in any way. - Jam.py can connect directly with SQLCipher, which encrypts single-file SQLite databases. This provides a genuinely simple solution for security compliance requirements in which data must be encrypted at rest, without any RDBMS server software needing to be installed/maintained. This feature alone can eliminate significant IT workloads. - Jam.py's automated CRUD features enable developers to potentially eliminate tremendous portions of routine database/UI work, especially in projects with compliance obligations (HIPAA, PCI, etc.) that require implementing complex audit trail logging and auth solutions. These sorts of requirements can be satisfied with truly zero additional work in Jam.py. - As with any freeform web UI, Jam.py user interfaces can include iframes, which makes it a snap to integrate web applications written in *any other programming language/framework, simply by connecting to the same database and/or connecting REST APIs. - All of Jam.py's features are encapsulated in a *miniscule, simple to use system, which requires very little memory and CPU power to run, and takes only a few moments to set up on virtually any hardware/OS with either Python 2 or 3 installed (virtually any Linux, Windows, or Mac machine). The server can even run comfortably on Chromebook, Android, iOS and other low-powered mobile platforms, old and new. Client devices simply require any mainstream browser to run Jam.py applications - no software ever needs to be installed for multiple users to execute and update Jam.py apps. Jam.py can be easily scaled by load balancing servers and by employing other well established vertical and horizontal scaling techniques. Its small footprint and support for most common RDBMS systems and WSGI, provide many options and technical choices to fit virtually any deployment environment. Jam.py reduces software development complexity in several unique and powerful ways. The Jam.py interface is so simple in appearance, that its deep capability is easy to miss at first glance. Take a look through a few examples in this tutorial, and you’ll quickly see how Jam.py not only eliminates common installation, configuration, maintenance, and toolchain drudgery, but also radically speeds up time-consuming CRUD database development activities, which often form a majority of the work involved in completing projects of all sizes. For CRUD work, Jam.py’s productivity gains compare fantastically well to other mature frameworks. Jam.py enables a uniquely productive no-code approach, practically integrated with the most popular, well-entrenched, fully extensible mainstream web development tools, to form a system which is simultaneously hyper-productive and even usable by non-coders, yet also capable of completing complicated production work, comprised of complex and specifically detailed front-end and back-end requirements. Jam.py enables you to spend time building the innovative features of applications, instead of basic CRUD - all in a way that’s surprisingly powerful and fun to use.

Here's another little quick video tutorial: https://www.youtube.com/watch?v=kUjDKqPOBYE This one demonstrates how to generate custom Repeating Panel/Card layouts and how to integrate REST APIs calls on the back-end, with both the no-code Jam.py grids and Custom HTML UIs.

(as usual, probably best watched at 1.5x speed)

Jam.py is beginning to make my age-old hope for users to take part in writing useful CRUD functionality, a reality. I had hoped in the past it would be possible to teach normal computer users enough simple Rebol to do those sorts of things - and I did experience some success with IT pros, and a few motivated business owners - but most people simply never gain enough experience to write production code of any sort. There are just too many endless details, too many unclear solution patterns, too many varied small challenges related just to configuration and deployment, too many potential gotchas, even before getting into the shallowest weeds, for normal users to ever accomplish useful software development goals, using any pure code solution, in most situations. Users without software development experience just run into too many numerous little problems, to actually write reliable code which handles business tasks of any serious complexity. And the no-code world has previously been nothing but disappointing. Most no-code tools are too limited and rigid to integrate easily, and there are typically licensing limitations associated with any of the no-code solutions which can actually accomplish useful work. And most are huge beasts, with massive hardware and supporting infrastructure requirements - they're typically run in the cloud. Jam.py fits a sweet spot. It enables users to actually achieve very useful schema, UI, and query goals. Not just baby stuff, but actually deeply useful business capability - the sorts of things that would take new developers a few years to totally master all-in-all. Jam.py is, on the other hand, stupid simple to use. It's ridiculously tiny, quick to install, requires only Python (version 3 or even 2) on the server, and any mainstream browser on client machines, and it's extensible in a way that is about as enabling as any imaginable framework componentry could possibly be. It's safe to say that there are few areas of end-user application development which can't be accomplished productively with the tooling it consists of (Python and the HTML/CSS/JS ecosystem). It's a really neat paradigm to build schema, a majority of required query logic, and some/all fundamentally useful UI, using only dead-simple, intuitive, visual tools, and then to just hand over specialized/complicated functionality requirements to pro-code tools, without the no-code pieces getting in the way or limiting development. This is the first time I've ever experienced a no-code tool actually provide a preferable method of implementing core database and UI functionality. Jam.py enables building some of the most critically useful capabilities required in any software development stack, and it doesn't make syntax, logic, schema, query, or other errors in the pieces of application engineering which it automates. I can point to many tens of thousands of lines of code I've written, which simply would never have needed to be written, if I'd picked up Jam.py earlier. Taking a few days to learn how it works is certainly worth the effort. Even if you never use any of its framework tools as the foundation of a project, it's useful just for creating UI datagrids and forms with automatic CRUD wiring.

Here's a little Jam.py Gemini API example: http://appstagehost.com:9007 Upload a PDF, and Gemini (Google's LLM) provides a summary. This is just a super quick project example with few dozen lines of code, but this sort of LLM API application has 1,000,001 practical uses in all sorts of domains.

Here's a tutorial for the application above. It shows how easy it is to connect the Gemini API (Google's LLM) with Python on the back end of a Jam.py application, and connect that to a simple Jam.py front-end UI. The example application enables a user to upload PDF files, sends the file to the Gemini API, and prompts the model to return a summary of the PDF contents. It's dead simple to do with Jam.py, and this is a use case which is currently on everyone's mind, and actually practical in a wide variety of domains: https://www.youtube.com/watch?v=4tXUqtnMMlk

Here are the exported project zip files for all the Youtube examples above, which you can download and import directly into a Jam.py installation on your server (all the code, schema, everything required to run each of the complete application examples demonstrated in the Youtube videos, on your own server): https://com-pute.com/nick/gemini_1.0.0_5.4.136_2025-02-12_14-15-48.zip https://com-pute.com/nick/jam_form_with_api_and_repeating_panel_examples--1.0.0_5.4.136_2025-02-10_05-58-12.zip https://com-pute.com/nick/jam_forum_1.0.0_5.4.136_2025-02-05_16-17-27.zip https://com-pute.com/nick/jampy_html_landing_1.0.0_5.4.136_2025-01-30_17-56-52__with_textarea_which_displays_column_values_from_task_grid.zip https://com-pute.com/nick/jampy_my_demo_1.0.0_5.4.136_2025-01-27_05-27-53.zip https://com-pute.com/nick/xlsx_importer--jam_project_1.0.0_5.4.136_2025-01-19_20-57-10.zip https://com-pute.com/nick/files_1.0.0_5.4.136_2025-02-02_17-30-00.zip

I'm thoroughly enjoying Jam.py, at this point far more than SQLPage. It's much more powerful out of the box, but in many ways even simpler and more straightforward to complete work with. It makes CRUD work with a database utter child's play. The combination of Python and HTML/CSS/JS/jQuery/Bootstrap (plus the no-code tooling, database ORM (and/or SQL)) is just so consistently practical, fast, and effective. Jam.py is tiny, it takes less than a minute to set up an entire development environment, and can be extended so naturally with front-end and back-end code by GPT. GPT and all the other AI models know nothing about Jam.py framework, but the language frameworks built into Jam.py are all the best-known tools in any AI quiver, so they are instantly understandable and extensible by generative AI, in the deepest way possible. I'm having a moment with Jam.py that feels pleasantly similar to using Rebol for the first time, a quarter century ago. I just keep noticing how surprisingly quickly and easily I'm getting a broad variety of little tasks and apps actually completed with it. The super lightweight self-contained in-browser toolchain/workflow is as ergonomic and efficient as anything I've experienced. It reminds me a bit of using Rebol's text editor to build and run quick Rebol scripts (except that Jam.py's editors have more actual IDE features such as syntax checking, auto-complete, code handling features like commenting, etc.). I'm looking forward to getting Jam.py worked into production projects over the next few weeks - and there is one particular client who will immediately start building their own CRUD and reporting functionalities with the no-code tools. That's such an exciting prospect. I've had so many Anvil projects over the past few years make use of non-Anvil tooling, integrated with Anvil, that virtually every part of the framework has been swapped out with other tools, in various cases. In particular, I've written 10's of thousands of lines of production SQLAlchemy and integrated a pile of third party SQL, used HeidiSQL, DBeaver, SSMS, etc. to replace the built-in Postgres, ORM, and database management tools in Anvil (which has only made me appreciate Anvil's framework tools even more!). But Jam.py's database tools nicely replace all those things, and add some seriously tremendous no-code productivity benefits. I'm just so aware of the many thousands of lines of schema definitions, queries with multi-sort features, multiple deep joins with complex filters, audit trail logging functions, soft-delete schema/query functionalities, etc. - none of which would ever have had to be written with Jam.py (and no other language/framework that I've ever seen would have solved those issues any more easily). I've got visual builders to integrate with Jam.py, which are helpful to quickly build UI layout (HTML and CSS), libraries to handle markdown, charts, diagrams, sound, graphics, and any other imaginable functionality, immediately, with just a few lines of code - but more important, the most time consuming parts: any basic CRUD forms and grids are all completely built, automatically by Jam.py. And then, even more effective at customization of any kind, is generative AI - it can write from scratch and painlessly integrate a majority of the code needed to perform heavy lifting on both the front end and back end, help reason working solutions, etc. SQLPage is a really cool little tool, with so much functionality built in, and Anvil - Anvil has provided all the big guns I've needed for every big production project I've taken on since I started using it. But I expect it will likely get completely replaced by the end of this year with Jam.py. If you haven't seen it, take a look at the 'Northwind Traders' demo below by Dean Babic, which was migrated from MS Access in a total of only 10 hours, including all server installation/configuration, database schema creation, UI layout with fully interactive CRUD grids, forms, navigation, charts, printable report designs, and even a pivot table interface: https://northwind2.pythonanywhere.com Think of how long that would have taken to build with Rebol - the truth is, I never witnessed so many comprehensive features even approached in any Rebol application. And the exact specs of that demo would have taken far longer to build with Anvil (and the install would be massive in comparison). I'm actually excited again, for such a tiny tool to be so profoundly productive and capable.

Hello! I need an idea regarding SQLPage. I also wrote discussions on github/sqlpage, I still don't have a satisfactory answer. If I work with several hundred databases (mysql for example), how can I change the working database? It is about accounting software, an accountant keeps records for more than 100 companies, each with its own database. In sqlpage I cannot send the 'use X' instruction to change the database. The proposed solution - to launch one SQLPage process for each database and redirect the requests from nginx .. it works for 5-10, but not for 100 databases. Do you have other solutions?

I haven't needed to do that, but have you tried using sqlpage.exec() to call a script (Python or otherwise), to edit the sqlpage.json file, and then restart the sqlpage server?

Here's another Jam.py tutorial which demonstrates how to display Markdown returned by a server function, and also how to implement a JS audio recorder which saves recorded audio to the Jam.py database, and retrieves/plays any selected saved audio files: https://www.youtube.com/watch?v=EnuJHqdVDTI

Nick, I thought about it, but it doesn't work... If I had only one user it would be fine. I cannot restart the server when user X accesses a database and Y wants to switch to another database.

Have you spoken with Ophir about it? He's responsive, and trying to make SQLPage more successful, so you may get him to implement a new feature. Otherwise, for the immediate future, why not run several hundred instances of the SQLPage binary, each on different ports, with links from a main page? SQLPage is small enough that even a few hundred running servers should only require a few gigs of RAM. Not ideal but doable until Ophir can address the need...

For reference, I just checked a couple long running instances of SQLPage: ps -p 39286 -o pid,cmd,%mem,vsz,rss PID CMD %MEM VSZ RSS 39286 ./sqlpage.bin 0.9 1792528 41672 ps -p 217183 -o pid,cmd,%mem,vsz,rss PID CMD %MEM VSZ RSS 217183 ./sqlpage.bin 1.1 1319396 50268 So about 45Mb per instance on average, or 9GB of ram to run 200 servers simultaneously. Certainly not the best long term solution, but potentially doable even on a small VM, until you can get a ticket worked out with Ophir.

I sent the problem to Ophir some time ago, I know he is responsive, others had asked before me. It seems to be a technical limitation, related to the SQL parser (all instructions are sent as prepared statements, and in prepared statements you cannot use 'use X' to change the database). We'll see, maybe he'll find solutions in the future. I still don't dare to go for the option with the 200 or more processes launched simultaneously, I'm still waiting :)

I'd have suggested adjusting schema so all records are contained in one database, but it sounds like schema definitions are beyond your control. I sent a message to Ophir about this to add some urgency. I'll let you know if he has a solution!

Ophir wrote back immediately: Hi Nick! Multi-database instances would indeed be a really nice feature to support in SQLPage ! It's an engineering challenge, but one we would be happy to work on. Could you put us in touch with that user? As a side note, I am not an expert on this, but I don't think you can add RSS between multiple instances of the same executable like that. Some of that memory is shared between the instances, isn't it? Cheers, Ophir How should he contact you? Or you can write him - he sounds eager to get this happening

BTW, what Ophir is pointing out about RSS, is that when running multiple instances of the same executable, a significant part of that memory (code, libraries and other shared resources) can be shared between the processes. So just summing up the RSS of each process might be overestimating the total additional RAM required, because some pages of memory are common to all instances and are only loaded once in RAM.

Nick, thanks for getting involved! I have the impression that I can't express what I want correctly (I don't speak English well). I don't want multiple database instances, all I want is for a user to be able to dynamically change the database they are working on. For example, I have a mysql server with databases 'db1', 'db2', ... 'db99' - all with the same structure (they contain the same tables, the same structure). From the application created with SQLPage, the user must be able to change the active database 'with one click'. In other development environments, I use a 'use db2', after which I send the SQL instructions, without having to prefix the names of the database tables ('select id, document, value from documents', not '...from db2.documents') Look at what I wrote last year about this problem, and Ophir answered that it is currently not possible https://github.com/sqlpage/SQLPage/discussions/570#discussioncomment-10559108 Others have asked for the same thing before, I found older discussions, unfortunately so far we don't have a solution.

Your explanation is clear, and Ophir has expressed that they're interested in developing a solution. He asked to contact you, or for you to contact him. Is there an email at which he can reach you? You can send it to (my first name at) com-pute (dot com) if you don't want to post it online.

A written tutorial covering everything I've done with the video tutorials is now available: https://com-pute.com/nick/jampy_tutorial.txt https://com-pute.com/nick/jampy_tutorial.html The tutorial includes a document which can be pasted as plain text into any generative AI chatbot (ChatGPT, Claude, Gemini, Deepseek, etc.) conversation, to train the LLM in-context how to use the Jam.py framework. That training document is available separately at the link below, so that the text can be copy/pasted as-is, directly into any chat session. This should enable your AI to answer questions and generate working code for use in Jam.py applications: https://com-pute.com/nick/jampy_llm_introduction.txt

https://www.youtube.com/watch?v=UjEsyKyeWl4 The complete conversation with Grok: https://grok.com/share/bGVnYWN5_11f8ccd3-0c9a-4a0e-aa0d-c864c95efeaa Alternate download URL: https://com-pute.com/nick/Jam.py%20in-context%20learning,%20poll%20example%20_%20Shared%20Grok%20Conversation.mhtml In-context training doc for LLM AIs: https://com-pute.com/nick/jampy_llm_introduction.txt Alternate download: https://drive.google.com/file/d/1dorsKVVUBka1ZgpC8lvoIuqVur160b0g/view

I'm starting to use Jam.py on some production work. Together with Grok to generating code, using the in-context training document I demonstrated above, I'm getting some mind-bendingly good, yet unheard of productive results.

I posted the previous message because I was able to build a prototype application for a client, in less than an hour last night, which would have taken quite a few hours with Anvil, even using Anvil's highly productive visual tools and the rest of its tightly integrated framework features. Jam.py is having a powerful impact on my sense of where software development tooling can be improved. In working through my normal suite of initial tutorial applications (which I trust to help me achieve useful productivity with new tools), Jam.py continues to prove that its particular features are a remarkably effective mix. The key characteristic that I've never seen accomplished so productively previously, is the simplification of CRUD, to the point that all CRUD requirements are a genuine triviality: the schema building process, UI form and grid creation and CRUD wiring, joins, filters, sorts, master/detail table wiring, etc. - to the point that a substantially large/complicated implementation of all that can be built in minutes, reliably, by someone with no development experience - and that that foundation is naturally, fluently extensible with mainstream front-end and back-end language tools - especially with a shared ORM between the front and back end, which eliminates re-serialization of data (that part is similar to Anvil), with connectivity to all the most common RDBMSs, and integrated with a dead-simple suite of portable in-browser tool chain features... That's a really comprehensive mix of productivity features. For me, the proof is always in the pudding - how effective it is at building production applications. So far, the results of building my wide range of tutorial apps has been astoundingly encouraging. I can't wait to get Jam.py dirty with bigger projects - and luckily I have some clients who have great use cases which will wade it quickly into deeper production solutions in the coming months. The cool thing about Jam.py is that every part of it can be replaced by a variety of other tools (as is typically the case with any system based on RDBMS, web UI, Python, etc.), so there will be very few roadblocks that can't be solved by migrating some part of the solution to other tools, if ever required. That's a great benefit of using tools with enormous ecosystems - there are just so many interchangeable options. I'm excited that the small Jam.py community has a shiny new version 7 in the works :)

It's interesting to me that all these things sound so similar - some framework, with a database ORM, some UI implementation, to enable easy integration with a large ecosystem of libraries... But the devil is really in the details - using Flask, Anvil, Jam.py, Streamlit or NiceGUI plus SQLAlchemy, etc., all feel radically different, and the workflow is radically different, even though they each make use of Python functions running on a server. Anvil and Jam.py feel the most similar, their toolchains are primarily browser based, and porting back-end code between the two would be effortless if I were using SQLAlchemy, for example, instead of their built-in ORM's - but they still have very different implementations. Anvil has all the visual tooling for UI and database schema, but its implementation is molasses compared to the autogenerated fully-wired CRUD forms and grids in Jam.py, and custom UI code generated by GPT, Claude, Gemini, Deepseek, etc. And Jam.py can work with all the most common RDBMSs (and migrate between them in a framework-native way, without any code changes (as you can with SQLAlchemy, but with significantly more concise language structure and pleasant syntax)). That's a significant set of realizations, considering I've never previously experienced any tools more productive, all-in-all, than Anvil. So now we all get to tell our AIs 'generate some CSS to make that pop', and to instantly have a foundation of hundreds of malleable lines of code to make a layout go from functional to eye-catching, with zero work. But our experience with generative AI is all so different, depending on the languages, libraries, and tools we use. I can't emphasize enough how much of a difference it makes to ask an LLM to write HTML, CCS, JS, jQuery, Bootstrap, and Python code, compared to anything else I've tried (many dozens of alternate language tools). Every LLM is just so deeply steeped in billions of examples and pages of documentation with those tools, that they're intuitively great at producing effective code for those tools. Combine that benefit with a super slick low-code/no-code foundation which eliminates work and errors for functionalities which are universally needed in an overwhelming majority of data management apps, and which enables non-technical users to get core development work accomplished, and which can be extended naturally with code that involves the tools that LLMs know best, and it's hard to beat. I've been searching for a base solution for non-technical users for several decades, and Jam.py is far and away the best I've ever found. I left Jam.py unexplored for years, because it looked like just another tool. Having used so many other tools over decades really clarified how effective Anvil was in comparison. Jam.py is another level of productive. Just look, for example, at https://northwind2.pythonanywhere.com . What other software development system enables someone to build all that end-user functionality from the ground up in single a day (without any AI code generation)? Adding AI code generation to that mix is starting to give me some experiences that are mind-bending.

BTW, Jam.py is a truly great way for developers who have no experience with HTML, CSS, JS, jQuery, Bootstrap, SQL, and Python, to dive right in and begin using all those tools. You can read just a few very basic tutorials about each of those language tools, spend a single day getting to know only the basics about how they work, learn only the absolute fundamentals about how Jam.py puts them all together, and begin building actually useful software, right away. It's a super simple way to wade in to all those technologies, which would likely otherwise take at very least a few months to begin putting together effectively. The benefit is that you learn the most used ubiquitous language technologies that are used everywhere, so those skills are portable to a massive majority of other development environments.

In Jam.py, even young children and inexperienced computer users can be shown immediately how to organize information into data structures stored in an RDBMS. Create a complete ToDo list application with all the create, read, update, and delete features, and have a new student be able to reliably reproduce the application, within 5 minutes. There are none of the normal detailed syntax error problems in code to worry about, no need to learn how to use the command line, no software toolchain for the user to install, none of the mess. Just a direct path to learning how to structure data, in a point and click visual environment that takes care of the sort of details which would take most beginners at least a few very frustrating months to get past. Then, right away, actually practical and universally useful basics about UI event handling, variables, functions, conditional evaluations, database queries, front-end and back-end interactions, etc. can all be introduced in the simplest possible ways, with a line or two of code. No complex installations or configurations required. Just a few lines of code, without helpful autocompletes, syntax checking, etc., and immediate changes to code shown by clicking the browser refresh button. And then when it's time to dig deeper, a student can be introduced to all the parts in play: create schema with SQL, and write some queries in a command line tool, show how Python functions can be delivered over HTTPS using Flask, FastAPI, etc., show how JavaScript can be used to call those functions with AJAX, etc. - all without introducing any fundamentally new concepts or language - all perfectly relatable, and in fact *interchangeable* with what students have seen in the Jam.py interface. The is literally zero wasted time/effort spent teaching students any concept in Jam.py - only 100% practical common code patterns, syntax, libraries, tooling, etc., demonstrated in the simplest possible environment, with every complexity initially handled in a way that eliminates confusion and error, and extensible in a way that's useful in actual production development work, with or without Jam.py. Get students actually using all the common RDBMSs, and all the common web development tools, immediately, in a way that is initially error-proof. Introduce database schema, joins, foreign keys, sorting, filters, UI forms, grids, and all the CRUD concepts immediately, without having to write a single character of code, and then immediately transition into implementing and extending all those things, in the most incrementally simple ways. So students gain immediately useful skills, in the very first setting, and can immediately build and deploy actually very useful applications, and then just continue onward and upward from there. I've never seen an environment more capable of easing the learning process better than Jam.py.

I added another one of my standard tutorial applications to the jam.py example at http://appstagehost.com:9005 - the guitar chord diagram maker, which dates back to some early Rebol tutorials 20+ years ago. I gave Grok my Jam.py introduction doc for LLMs, pasted the code from my Anvil version of the chord application (which I previously ported manually from a Rebol example), and it took a few seconds to build a 100% functional port in JS, with all the parts needed to make a fully functional Jam.py app. Here's the conversation with Grok: https://grok.com/chat/6d0fe70c-1c2c-4e9d-9ea9-9cacff65b53c

Nick, the link is incorrect. You need to click on the icon with the arrow up, in the upper right corner, only then you will get a link to the conversation available to other people and it will look something like this https://grok.com/share/bGVnYWN5_ee5cc8c5-f06c-4614-a3bf-52e6eb1ab2

About using AI - the profession of a programmer is gradually becoming a thing of the past, like, for example, the profession of a carriage driver. For example, this code editor in the form of a single html file (https://pochinoksergey.ru/ai/editor/editor_en.html) was completely created by AI, and I only gave verbal hints. Here is the result - syntax highlighting, chat with AI that has access to the code inside the editor, the ability to highlight part of the code and ask it to explain or change it. (The provider - https://pollinations.ai - does not ask for payments, registration and has a very simple API for accessing many models - I recommend it for your projects)

Thank you Sergey, here's the link: https://grok.com/share/bGVnYWN5_1d9a59c4-bacf-40f2-8cc2-6d99f558837c I'll take a look at https://pollinations.ai

'About using AI - the profession of a programmer is gradually becoming a thing of the past, like, for example, the profession of a carriage driver' - I've been harping about that endlessly here for the past few years ;)

https://pochinoksergey.ru/ai/editor/editor_en.html is another very good example, for those who did not understand what was in the process developing - and I'll say it again - we're only currently experiencing the first inch of a million mile journey. We have about 3 years before capable humanoid robots begin to proliferate and become ubiquitous, with the ability to replace most other human work.

I've been using jam.py more and more for small projects, and fully expect it to replace Anvil for a much larger percentage of my future work. Last week I built a prototype for an application to store images, scanned serial numbers, logged-in personnel information, and other batch data for a high-end window manufacturer, to document lack of defects at the end of their line. The guys who contracted me expected a week or 2 of work to build a prototype, and I was able to provide the first version in 5 minutes with jam.py. That included fully operational master-details tables, with the complete schema, UI, and CRUD implemented exactly to their specs, and additional sort and filter features which would have taken many hours in any other environment. I also built a small prototype to be used for one of my client's informational web sites, which also took just a few minutes, and would have been far more complicated to build with any other framework I've seen. Since I've begun exploring jam.py, I've revisited several significant projects completed with Anvil over the past few years, which would have been child's play to create with jam.py, along some AI code generation. Not only the development time and trouble, but also the hardware resources, could have been dramatically reduced for those projects. Jam.py is definitely worth checking out: https://com-pute.com/nick/jampy_tutorial.html https://com-pute.com/nick/jampy_llm_introduction.txt https://jam-py.com/docs/contents.html

I'm much more likely to use jam.py than SQLPage for most small projects going forward, but SQLPage does have one distinct advantage: support for ancient browsers, with absolutely no JS required for any of it's core features. In that way, SQLPage will replace all my old tools such as jslinb whenever I need to support any sort of ancient client device, or for alternate IU interfaces to databases created by tools such as jam.py, which need to support all possible client devices. SQLPage is fantastic for that purpose, and it's very fast.

Just so you will know someone is reading this and appreciating it. This is all interesting. A question. Is it easy to use SQL Page to set up a site where you can sell stuff with credit card payments? Is it secure for that? And the same with jam.py but my interest are no JavaScript if possible.

SQLPage implements the typical security features expected in a modern full stack framework: https://sql-page.com/safety.sql But much of what's required to maintain a secure server is IT related: configuring firewall, constantly monitoring suspicious activity, installing OS and malware updates, requiring complex passwords, rotating encryption keys, performing penetration testing, implementing internal workflows that keep over-the-shoulder breaches from occurring, etc. That's true of any framework/stack. Jam.py uses JS to send parameters to Python server functions, but it hides most of the typical AJAX mess. It also includes default jQuery handlers for most common events, and Bootstrap for most common styling needs - and/or you can use your own pure JS and CSS as you prefer - and that's the sort of thing generative AI is fantastic at. You can learn to use the JS parts of jam.py in a day - try Gemini 2.5, it knows jam.py well. You can also feed this document into most other LLMs to get them up to speed in basic way: https://com-pute.com/nick/jampy_llm_introduction.txt So don't hesitate to do at least some minimal JS in jam.py. It's dead simple. SQLPage not only eliminates JS and front end code, but also the need for typical server language tooling, ORMs, etc., for most fundamentally useful tasks. You can use it to build significantly capable apps that run even in Dillo browser (D+), which can be compiled to run on just about any device, and require zero JS. SQLPage can interact with REST APIs, so you should be able to interact natively with a credit card payment system that provides a web API, which uses webhooks, etc. You can also call Python code using sqlpage.exec(), which can be helpful for services which offer a Python SDK. I've moved away from using SQLPage for most of my own work, because I absolutely love jam.py, but SQLPage will be my go-to for building front ends which need to run in ancient browsers (connecting to existing apps created with other RDBS based frameworks, or stand-alone), and also when working with users who have significant SQL experience and who lack other software development skills. I'm still relying on Anvil for most of my big projects, and every project I've gotten implemented in production with it during the past few years. But I'm using jam.py more and more for production work, and it's just a ridiculously productive/easy/fast/pleasant framework to use. Since jam.py is all built on standard RDBS, plain vanilla Python on the back end, plain jQuery and Bootstrap on the front end, a brilliant ORM that works on both server and client (and/or write your own SQL code), and provides truly spectacular no-code tools to satisfy the most common CRUD requirements, it's something really special, productive, and fun to work with, for any typical CRUD database work. I'd suggest everyone at least try jam.py - I've never seen a more productive software development tooling system in 40 years. Together with LLM help, it is the best in terms of *productivity for database applications (business data management applications), bar none. I also still use Flask for some little tools and utilities, middleware, etc. which don't require a lot of pretty UI work. It's lightweight, and LLMs can instantly generate working Flask code, first shot, for most little utility scripts. And of course, you can build huge applications/sites with it, if you want to really dig in. If you don't want to run Python with sqlpage.exec(), Flask middleware connected to SQLPage API calls, is another viable solution for many tasks where Python is useful - and of course you could use a middleware API built with any other language/framework/stack...

With everything I do in software development, regardless of the tooling, languages, etc. I use AI to help. I think of this similar to how I approach musical improvisation. As a guitarist, I've performed more than 3000 concerts and taught many thousands of students. Over 39 years, one thing that I've always clarified is that there are dozens of approaches to melodic note choice and harmonic/structural thinking. Guitarists typically learn how to choose notes by thinking about pentatonic scale fingerings, arpeggios, CAGED shapes, rotating modal fingerings, note names, single string patterns, interval patterns across adjacent strings, interlocking octaves fingerings, etc. All those approaches force your fingers to move differently, and force your mind to consider different natural melodic, textural, and harmonic combinations. Software development frameworks work similarly. Just as my first thoughts about how to approach playing pentatonic scales in a single key (and using a light overdrive sound, with a Strat and Fender Twin amp, etc.), when playing over a basic 12 bar blues, is entirely different than choosing modal scales and arpeggios over individual chords and ii-V progressions (and a clean sounding Gibson ES-175 into a JC 120 amp) when playing over jazz standards, frameworks, current language choices, etc., provide similarly diverse tools to use when approaching development problems. These days, I'll likely choose to get through an entire small gig at a local venue, with a single guitar, and a basic modeling pedal board going direct into a PA system. I can mix the sound at the event better, hear better how everything blends for the entire audience, and I can dedicate my energy fully to playing creatively, instead of moving and setting up gear for hours. For a pickup gig with a small group I haven't worked with before, that makes sense. To the audience, it still sounds mind blowing. But if I'm performing an event for 30,000 listeners, the stage has a dedicated hardware backline choice between given amps, and there's a sound crew listening and mixing in a tent, more professional advancement on the line for the musicians I'm working with at a big gig, etc., then my choices become much more traditional, based on decades of using tube amps with matched instrument choices, changing guitars between tunes, etc. Jam.py is like having an Axe-fx floorboard and a Strat at a little event. Using AI is like having a lifetime of licks and dozens of approaches to melodic and harmonic creativity, just plugged into your brain and working on autopilot. You've got to put the energy into make the performance, but you're free to create as you imagine, effortlessly - and that's most important in that environment. Anvil is like having a huge stable of guitars and amps that all just work together to create exactly the required tones for a bigger event. I've spent my musical life learning to use all those different equipment combinations, all those different harmonic and melodic compositional approaches, as well as building physical technical ability, etc., but I'm perfectly happy using a great modeling processor for live shows and recordings, and using tools like Suno to help write music for students. The corollaries are exactly the same, and in most cases, Suno can do a better job producing a song which inspires a person, can be used at an event, etc., than I (or anyone) could produce in a single meeting with a client. It's a dramatic improvement in lifestyle and freedom to be able to use those tools. And the effect of having all these tools, is that I get more time in my musical life to just focus on playing guitar the way I want, and to do other healthy things in life. I don't worry that music will become meaningless to me just because tools like Suno exist. I certainly don't write the way I used to, however, and I certainly don't carry as much gear to most shows, the way I used to. Maybe some day, people will just be more interested in music made by AI, I don't know, but the music I make is still satisfying to me. In the future, I expect that some technology solutions may still be interesting and fun to build using traditional tools, just like it's interesting and satisfying to grow your own garden and to build/run an off-grid living environment. I don't expect to fully stop using tools like jam.py ever, even if the future is full of autonomously created software. There's enjoyment in creativity, purely for the purpose of human satisfaction.

I've used Baserow for a few recent task/projects. It's the best fully no-code tool that I've tried so far, which provides everything from database to front-end application development solutions, and is genuinely open source. Baserow does offer SAAS deployment and additional commercial features which aren't free/open source but the open source package is capable for a wide variety of needs. Jam.py is still my favorite framework which includes no-code functionality (it's so small, fast to install, and easily extensible), but it does require code for anything other than CRUD grids, forms, schema, auth, etc. Baserow is a massive install in terms of hard drive space and memory requirements (it includes Postgres, Redis, etc.), but only takes a few minute with Docker, and then you have a multi-tenant, multi-database, multi-application build system which requires no code whatsoever implement any number and sort of complex integrated database back ends, and any number of multiple full-stack applications, within a single development workspace that never needs to be installed/configured again (of course the entire environment is browser based and protected by an auth system). This is great for no-code users. The back end provides full fine-grained API access to every feature of the database system, which is typically dramatically fast to implement, compared to building an API to a database using any sort of coding framework - and the front end can include iframes in any part of a layout, so there's not much that can't be built and added on to applications created by the no-code builder. From what I've done so far, this enables a very nice foundation for non-developers, which is fully extensible in very productive ways. Baserow advertises HIPAA, Soc 2, and GDPR compliance out of the box, and it takes care of HTTPS termination, and most other infrastructure requirements. Spin up an Ubuntu instance for ~$50 per year on a Contabo VPS, install a firewall, Fail2ban, Docker, and Baserow, and you've got some serious development firepower which enables typical office workers to build real, complex data management software. Virtually all other no-code solutions are crippled by license fees, SAAS-only deployment options, etc., but Baserow and jam.py provide real *scalable solutions which dramatically reduce development time and effort, potential errors in code, debugging work, etc. for developers, and enable non-coders to complete actually powerful and scalable enterprise level data management tasks, which aren't constrained to any walled garden. GPT and others are fluent at writing code which connects with the REST APIs baserow automatically generates for every database table, so integrating with other development systems is extraordinarily productive. I've also built some really complex formulas in Baserow instantly with GPT. I still rely on Anvil for my big guns, and a full gamut of other traditional tools (so many little things get done in Flask), but I love having these no-code options available for clients who can integrate them.

I think back on so much of what made me love Rebol, and for my needs, basically all of its hoped-for benefits have been fully materialized in the tools I've used during the past few years. For me, the points at https://redprogramming.com/Why%20Rebol%20and%20Red.html have all either been surpassed or rendered irrelevant. Obviously, Rebol is smaller in size, but the actual productivity benefits that I enjoyed from its tiny size and portability (quick installation on remote machines of any common OS, the ability to send a full interpreter for any OS along with a code base as a tiny email attachment or a trivial download, etc.), have all been surpassed by competing delivery mechanisms - primarily browser based UI and development workflows. Browsers are absolutely ubiquitous in any environment I work in, zero training is required to get any user to begin working with browser based applications, browsers work on any OS new and old, there is never a need to make users update a web app - that's all totally transparent to users, and requires no time or effort whatsoever (this benefit can't be overstated - I don't even think about updating, ever - it's just a non-issue). Python is everywhere by default, and if it's not somewhere you need it (typically it's only ever needed on a single server machine - never on a client), or if you need a particular version, it's a few minute install process. Library management is also a non-issue in Python. Environments and pip (or choose your other favorite system) all just work, and there are never issues with version conflicts. Freeze an environment, pip install the requirements.txt - it takes a minute. All the options for web based UI, schema generation, all the work that used to be required to develop APIs which wired up multi-user network connectivity, all the work that was needed to build logic for CRUD, filtering, and sorting query results, all the work that was required to perform infrastructure configuration, for workspace tooling installation, for project management and codebase version management, for backing up and restoring codebase and user data, logging changes to data by users and undoing unintending changes, for handling security requirements, for dealing with common file formats, for importing and exporting data, for creating documents in common file formats, etc... Those are all non-issues these days - no effort or time is wasted on handling those things. And so much of what needed to be handled by *language - the main benefit of Rebol's ability to create productive dialects - is superseded by far more productive and intuitively useful tooling. I could never teach a non-technical user to create a fully working multi-user database with multiple linked tables, and a network accessible API, in a few minutes, like I can with jam.py or Baserow, let alone do it in a way that's reliable, bug free, secure, and includes features like soft delete (restore any unintentionally lost/changed data), logging, instant updatability for all users, availability on any OS (with responsive mobile layout), etc., etc., etc. It's not even a close race, even *before AI productivity gets added in. But then add in AI, to generate code which connects those reliable, secure, complex database tables which a new user can create intuitively, minutes after being shown how, using an automatically generated REST API which can be connected with virtually any other development system, in any programming language, and the productivity capability increases by *many orders of magnitude. So much has changed in the past few years. I love building software more than I ever imagined I could, and I'm able to be so much more productive and capable of connecting with any common system, than I ever imagined. Users of technology are still limited in their abilities. Clients still misunderstand the scope of their problems, organizations still build massive messes of complex technology, organizational cruft, and integration hurdles which require complex navigation, our world is filled with bad actors who force everyone to abide by so many complex security requirements, and end users still don't know how to perform basic mouse and keyboard operations (and many still just want to use iPhones), etc., etc., etc., but I find that those problems simply melt away more and more with the tools that have been developed recently. Somewhere around 2015, I had lost hope after Rebol essentially evaporated, but I'm really grateful and honestly surprised at how good the situation has gotten for developers since then. I'm so excited to watch AI and robotics continue to improve prospects in every other facet of life.

Last night, I built an application with Baserow, for an client whose business is to send therapists to patient's homes to perform rehabilitation. The app helps her admin employees determine which therapists are available in various geographical regions, so they can make better use of their human resources. The business was previously using a collection of spreadsheets to store the availability of all therapists. I spent a few minutes combining and flattening the spreadsheet data into a single CSV file, then imported that data into Baserow, which provided instant full CRUD, multi-filter, multi-sort, grouping, auth, REST API access to the data, etc. Then I took about 1/2 hour to build a nice web application with Baserow's built-in application builder, which included multi-user access and authorization (using a custom editable user table), typical navigation between pages, each with various default data views, full CRUD, custom page layout, styling, images, responsive design for desktop/mobile, etc. The builder covers all the most common page layout and styling requirements, as well as any sort of common CRUD interaction requirements (any imaginable filters, sorts, groupings, grid and form views, etc.) - it's perfectly capable of building public facing application layouts, out of the box, but the huge advantage is that Baserow builds automatically generated and fully documented REST APIs to all the data in any database, so you can interact with any data in any way imaginable - and all that comes totally for free, no coding effort required. You can connect with any data in the database via API, using any language or interface that can make HTTP requests, even Rebol :), and build any sort of web application, using any other tools you prefer, and then insert that application into an iframe in the Baserow app builder. This provides unlimited extensibility to the Baserow application builder, for any developer, with any background, using any development tooling of choice. The Baserow database system is easy enough for most office workers to learn how to use in just a few minutes. Baserow is intended to be simple to use for anyone who has any familiarity with spreadsheets - you can slice and dice columns and rows, aggregate values, add formulas, import and export data, etc. (there are a massive variety of very powerful formulas included). In many cases, just using the database builder to store/import data is enough to satisfy the most typical data management requirements for common organization uses that you see 'internal apps' being built for. Many of the hundreds of little utility apps I've built in Anvil, for things like supply lists, or even much more complicated linked tables, can be built in a few minutes with Baserow, by a complete newbie who has zero software development experience. The app builder would likely take most office workers who have a technical bent but no coding experience, perhaps a few hours to learn well, and a few days to master. And those users then have the ability to build real, professional looking applications, not only without bugs, but even satisfying HIPAA, Soc 2, and other compliance requirements. It would take years to be able to achieve that using any sort of traditional development methodology. But the real power comes from the automatically generated REST API. Any user who creates a Baserow database, just by importing a CSV file, or by adding a few columns to a visual table layout, has automatically generated a REST API to that data, which any other developer can connect with (and which GPT and other code generation LLMs know very well how to use and integrate deeply). The fact that all this is done in a multi-tenant, multi-workspace system, which can be installed in a few minutes on VPS servers which cost just a few dozen dollars per year to run, and which is scalable to any sort of workload that can be handled by Postgres, is fantastically productive and powerful. I'm going to use Baserow much more.

I keep thinking about how Rebol datatypes made working with data of all sorts, more natural. Baserow has these data types built in by default: Single line text field Long text field Number field Rating field Boolean field Date and time fields URL field Email field File field Single select field Multiple select field Phone number field Link to table field Lookup field Collaborator field Count field Rollup field Created by field Last modified by field Last modified field Duration field Autonumber field UUID field Password field AI field Of course that's just a tiny part of the feature set in Baserow, and nothing compared to automatically generated API access to tables, but something to think about.

And unlike Rebol, field types in Baserow such as dates and times naturally understand and automatically convert all the most common date and time formats when data is imported (in ways which are much smarter and more universally capable than Rebol was). I'm gonna to really dive into other open source no-code integrations with Baserow, such as n8n. Baserow's automatically generated API access to the database makes incredibly fast and easy work of extending Baserow applications using any programming language, and AI generates Baserow API code beautifully (and also generates formulas well, for simple native data transformations and logic implementation), but there's still a typical development and debug cycle required when using any API. The real benefit of no-code is that you don't need to rebuild any wheels, for integrations that exist to perform any sort of common workflow . That not only saves time tremendously, but also eliminates many potential bugs, and all the issues that come from dealing with the minutia of traditional development practices which can cause headaches. I'm not yet a user of n8n, but I've watched several not-so-technical clients quickly and painlessly build significant solutions with Zapier and other similar sorts of tools, which would have taken quite a bit of time, effort, and careful work, even with Python and it's incredible ecosystem. So, I'm motivated to continue exploring any no-code systems which integrate nicely together, and eliminate development time and pains. I'm really motivated by my experiences with jam.py and Baserow.

I have a client who's a perfect candidate for no-code. She's driven to build in-house tools to reduce payroll waste, and she can tremendously improve her bottom line by automating paperwork tasks. She and her staff are great with spreadsheets, so Baserow is an easy drop-in replacement. The database part of Baserow takes a day for new users to learn the interface, and how to normalize linked tables. Beyond that, they export CSVs and learn the basics of filtering, sorting, formulas, etc. I'm finding that most new users can get a handle on the database system in a few minutes, see where all the features are in less than an hour, get how the workspace and UI are organized, and actually begin modeling significantly complex schema in a few hours. With Rebol, this level of capability would have taken several months of daily work to achieve, and still would have required the oversight of an experienced developer to painstakingly ensure code was debugged and tested properly. For most data management tasks, the Baserow database system is all that's required to organize all sorts of in-house paperwork work. Users log in and create as many databases as needed in their workspaces. The automated UIs generated for linked schemas of values with structured data types, multiple filters, sorts, searches, groups, etc. is all that's needed to handle a majority of in-house tasks. To build UIs from the Baserow tables that all her employees create, for my client's contractors to see and interact only with specific curated data, with authenticated access to only values and workflows that any particular user group is given permission to work with - some of my client's more tech savvy employees will learn to use the Baserow application builder. So far, it's taking me a few hours to demonstrate all the features of the Baserow application builder, and users gain solid capability with it in a few days. All the basics of page layout, styling, navigation, adding auth and providing access to tables of users (created with the Baserow database builder), are instantly useable. Learning to display tables of data and to implement full CRUD interactions (with every sort of deep filtering, sorting, etc.), routing ID values between UIs, etc., can be accomplished reliably in a few days by people with some basic tech skill. I imagine most non-technical users will become fully capable with the application builder within a few weeks. There's 0 code, and the builder UI shows live views of all data, so it's not difficult to ensure values are being correctly queried and displayed. It's more about learning a series of steps and where features are in the UI - absolutely anyone can learn to use the builder - with 0 code required, it's all about learning how to select and pass ID values, and all of that is intuitively UI based. Commercial Baserow licenses open up fine-grained user access controls to the database interface, as well as all sorts of in-app communication features, extra UI components like Kanban and calendar views, branding, etc. (and that's all cheap - $10-$20 per month if you want those features), but I think the open source (MIT) version will suit every need I see for situations where Baserow will be useful. Employees can each be given their own workspace to build databases and applications, members can be added/removed to/from any workspace, and admins can control all those memberships. Role-based access to any data can be controlled in as fine-grained a way as desired, using the application builder's auth system, which is simply based on user tables added via the database builder. It takes more time to build auth access into application screens, then to just have assignable user access in the database interface, but it's still much easier than in most frameworks. The open source self-hosted version does not limit data in any way (the number of workspaces, databases, tables, rows of data, etc.), and you have absolute control of everything on your server. It takes a few minutes to install, and then you've got a multi-tenant, multi-user, multi-application server, with a fully web-based interface, which never needs to be installed or configured again at the server level, for any number of apps. There's full logging and configuration control at the server console, but users/builders never need to see or interact with any of that to start new projects, databases, etc. The great thing about Baserow is that it's API-first, and absolutely everything you can do in the UI is available via a REST API interaction, using any programming language/tool which can interact with HTTP and JSON. Any database interaction can be achieved with an authenticated HTTP call, and any number of fine grained database access tokens can be configured in the Baserow builder (all just point and click to select database tables, columns, types of access control (create, read, write, update, etc.)). Baserow can also trigger webhooks to be sent to any REST API you create with any other development tools, to automatically react to/process any sort of fine-grained updates to data in the database. For me, just a simple Flask endpoint is all that's needed to process data in any way imaginable, and from what I've experienced so far, GPT and other LLMs are absolutely fantastic at generating Baserow API code, out of the box, first shot. The API is automatically generated for any database users create, and fully documented in the Baserow interface. Many of the really useful features of Anvil's project management, database building, UI building, and workflow are entirely covered by the Baserow system. Just write Python code (and/or code in any other language) using a lightweight routing/web interface framework, and you can do anything you need to transform and connect data to other systems, as well as display data in any possible UI. It's dead simple to integrate with Flask, FastAPI, Bottle, Django REST API, Tornado, web2py, Pyramid, Jam.py, etc., or any comparable Node system, or any similar web framework in any other language (including Rebol). Just pop your little web app into an iframe in Baserow's application builder, and it's instantly integrated. That makes the job of extending Baserow dead simple and so fast to accomplish, for virtually any imaginable purpose. So there aren't any limits to how Baserow can be extended easily with code, but what's even more interesting is that tools like n8n, Appsmith, etc., include Baserow integrations. n8n is particularly interesting as a tool to pair with Baserow, because it enables connections with so many other systems, to do so many of the things that people tend to accomplish with the enormous Python ecosystem, for example, but with no code. And node-code isn't just useful for people without development experience. Just as Baserow enables building databases quickly, for developers too, without having to worry that queries are bug-free and fully tested (you get that for free with no-code), n8n offers a similar faster, easier, safer, more productive, intuitive, bug-free workflow to accomplish common integrations, communications, data transformations, etc. I think n8n is a great pairing with Baserow which can enable non-developers to accomplish far more development goals with in-house, without ever needing any code whatsoever. There is real power in that. The ability to give normal users the power to instantly and reliably create serious databases (with the full power of Postgres under the hood), without any code whatsoever, to store and manipulate any sort of complex data, and for that data to be accessible, not only via the built-in super simple web site application builder system, but also via automatically pre-built REST APIs, is an absolutely rock solid design (access to which is in turn built into systems like n8n). It's hard to imagine any workflow that can't be accomplished with Baserow as a foundation.

These 2 videos introduce Baserow's database and application features (~11 minutes total): https://www.youtube.com/watch?v=5yFMfP96_4M&list=PLsS7C3JL-JT3QuWwewrvdcOYdERtA9o6Q&index=23 https://www.youtube.com/watch?v=ipm_RXysh70&list=PLsS7C3JL-JT1cZ7uTuR9qIdbExrb_SBA3&index=7 The first 11 of these tutorial videos explain how to use the Baserow system and perform all the most important database work (about 52 minutes total): https://www.youtube.com/watch?v=X_3CoteDuaw&list=PLsS7C3JL-JT3QuWwewrvdcOYdERtA9o6Q&index=1 These 6 tutorial videos cover how the Baserow application builder works, to build web sites, authenticated pages to provide custom access to data views, with custom layouts, navigation, etc. (about 30 minutes total): https://www.youtube.com/watch?v=9EXyEf1Yp1g&list=PLsS7C3JL-JT1cZ7uTuR9qIdbExrb_SBA3&index=1 If you prefer to read about any of it, the user documentation is here: https://baserow.io/user-docs Couple that together with n8n, and you can connect your Baserow databases and web sites/apps to virtually any other common system: Google Docs/Sheets and other Google services, Microsoft Teams and other MS services, any common email service, Twilio and other SMS and MMS text message services, WooCommerce, Stripe, and other e-commerce services, Slack, Discord, X (Twitter), LinkedIn, Jira, Trello, Asana, Monday.com, Notion, Evernote, any DB such as MySQL, PostgreSQL, and MongoDB, connect with IoT hardware, scrape web pages, etc., etc., etc. - all without any code at all. Here's a 2 hour video intro tutorial about n8n: https://www.youtube.com/watch?v=AURnISajubk These systems are EASY (!!!) to learn, for users who have zero software development experience. They're open source, free, and you can run them entirely on your own servers, with complete control of all the software and your data. If you use a VPS host like Contabo, A2, Hostinger, etc., serving them can cost less than $50 per year, total (or use can use the SAAS offering for each of these products, which requires no in-house servers or technical knowledge whatsoever). It takes a few minutes to start building databases in Baserow (and a few hours to master), a few hours to learn how to use the Baserow app builder (a few days/weeks to master), and a few extra hours/days/weeks to learn how to integrate any of 1000s of other data sources and workflows with n2n. Of course everything in all these systems is entirely extensible, in any conceivable way, using code in traditional programming languages (Python, Java, PHP, C++, etc.), and these systems make integrating code extremely simple, with auto-generated REST APIs and other dead-simple integration mechanisms.

A non-technical user can watch all the essential links above at 1.5x speed, and get through all the necessary Baserow videos in less than an hour. And they can spend any amount of effort and be as involved as they want, learning to go from just the basics, to deep data and workflow management capabilities, without ever needing to learn 'software development' - a typical background in basic computing and office skills (Excel, web brower basics, etc.), is enough to really dig in and get useful work completed. For business owners who are struggling with tech costs, constraints, and data management headaches, these tools are real, production-ready solutions which enable serious improvements to the bottom line, and enable owners and managers to have complete control over how all their tech works, and which can make every single daily task in a business more easily manageable, in exactly the ways that are imagined, in any way an owner or manager sees fit. This is the realization of much of what was imagined with Rebol, only it actually exists in a fully mature and practically applicable way, and which is endlessly extensible to work with anything else that exists in the world of technology.

The truly great thing about starting with Baserow as a foundation, is that not only do users become enabled to do real work that is traditionally a huge time sink in any development work, developers are just as enabled to connect with and extend the foundation of any Baserow database/app, in any way (UI, logic, connectivity, etc.), with the really pleasant to use API. You're not blocked into difficult to access/control systems. It's all wide open, and you can use any language, or any tool such as n8n - or choose Appsmith, Tooljet, jam.py, etc. - anything that can connect to a REST API, and/or respond to a Webhook request. The building blocks just all fit together so neatly. There's something fantastically about building easy, safer, simpler, and more powerful and productive systems with less and less effort :)

For my needs, all that's really required go extend Baserow, in all the most likely required ways, will be Flask, to handle the Webhook endpoints, and to deliver some basic UIs within the framing of the Baserow builder (in iframes). For UI, just some very simple Bootstrap, jQuery, etc. is probably all that will be needed the overwhelming majority of the time (and of course, that's easily generated by GPT, Gemini, etc.), because all the general page layout, navigation, authorization, etc. is handled by the Baserow application builder. Flask is great for building quick API endpoints, and delivering little web based UI interfaces (I use it most for quick utility interfaces), but fastAPI, Bottle, etc. all work well too. Flask just has million + 1 plugins that make all the most necessary integrations possible, very easily. And of course Python can be replaced with any other programming language ecosystem - and I am very interested to see just how productive, widely capable, and performant n8n is in some production work. Any implementation which just works, doesn't require debugging cycles, etc. is intriguing... For me, I think Python + Flask + AI generation will likely be the quickest and most broadly capable solution... but I may even integrate Rebol for old time sake :)

Baserow sounds really interesting. From your description, it sounds a lot like an updated version of DabbleDb (bought and closed by Twitter around 2010).

DabbleDb looks like it was interesting (from an old YouTube video). It's really too bad that older efforts like it just disappear forever. I'd love to dabble with it :) That's why I'm so glad many fully open source solutions are currently available. Another potentially viable alternative to Baserow may be NocoDB + Appsmith (plus n8n, Python, etc.). NocodDB can connect with more RDBMSs, where Baserow is limited to Postgres under the hood. NocoDB doesn't include an application like Baserow's, however, thus the reason for Appsmith. Baserow is just simpler to use, however, and even asking non-technical users to learn/use 2 separate tools, no matter how simple they are, could potentially lead to less likely adoption. What struck me about Baserow was the practical package of tools it consists of, which can really get non-technical users (and collaborative groups within an organization) to a point where they can actually create useful databases and web apps/sites, without any other tooling at all - and then extending that foundatioon with code (or other tools such as n8n) is as straightforward and simple as possible. Baserow is just this great mix of simple-to-use, but powerful-enough tools, all in a single solution, to create complete-enough applications to actually give owners, managers, and employees significant power to manage data for real business uses, to handle the *full scope of entire business processes, including the ability to build secure public-facing web sites and apps from private internal data - without any other tools required... yet still, critically, it's capable of being extended by pro code in any conceivable way. There's just something about the facility of Baserow which has struck me, while showing non-technical users how to get started with it. Showing the database part to new users takes literally just a few minutes, I haven't experienced any resistance while demonstrating it, it seems to make sense to total newbies, and there's virtually no learning curve to begin. Gradually exposing more features seems to progress surprisingly naturally for non-technical users, and adding the application builder is simple enough for anyone who's got some motivation to achieve slightly more technically challenging goals (still within grasp with just a few hours of orientation). It feels like a perfect mix - just enough power to really be useful and extremely productive, every step of the way along a very quick and easy learning curve. It's almost impossible to do that, for typical office workers, with anything else I've ever tried. Tools need to be *immediately productive to even grab the first moment of attention from most potential new users. Jam.py is still superior in many ways to Baserow, from a developer's point of view - and people *can use it immediately to build database schema, and CRUD UI interfaces with no-code. But for any other sort of development effort, it immediately requires Python, HTML/JS/CSS, Bootstrap, jQuery, etc. Of course that's fine for developers - and for cases where systems need to use a particular RDBMS, and in any cases where resources are more constrained, it's a better fit, and it does genuinely enable practical no-code database interaction. But there's just something much more mainstream feeling and inviting about Baserow, for non-technical users. It looks and feels simple and professional, modern, etc. It seems to be immediately intuitive and not scary at all for new users. Import a CSV and you've got a database. Click and drag some headers to adjust schema, click some buttons to create filtered, sorted and grouped views, etc. It looks the way, and responds the way normal users expect a typical user application to respond. Using it doesn't feel like 'development' work, and this isn't true, in quite the same way, with any other no-code system I've seen so far. People get spreadsheets, and they seem to get Baserow in the same way. It just feels like a natural, intuitive, visual interface, but it enables *much more power and connectivity than even collaborative tools like Google Sheets. I'm really excited to watch Baserow take root in the workflows of clients who've started using it. I can see how using it could significantly affect the way software solutions get implemented, and even imagined/conceived by business owners, managers, employees, etc. I've been searching for that holy grail for a few decades, and I see a brighter glimmer of hope towards that goal, with Baserow, than I have previously. And using it doesn't feel like painting anyone into a corner.

Another part of the equation with custom in-house application development has to do with how ongoing support, code updates, IT management, etc. are handled in an organization. I still support applications which I wrote years ago. It's common not just for employees, managers, and other users (contractors, client resources, etc.), but also supporting IT staff and key technical resources to move on to other positions, leave their company, etc. I have this vision about tools such as Baserow, which involves multiple users and stakeholders all understanding how their software development system works, at least to some useful degree, so there's never a sole support kingpin who, if they leave an organization, is a single point of failure. Beyond that, having a group of employees who can support their own tech needs more completely, can be a tremendous time, money, and problem saver for any organization. When human resources change at an IT company who hosts some server for applications I've written, and a server machine has to be restarted, for example, I inevitably get a call, and need to take some time to help with documentation that previous employees have misplaced, help get everything running again, etc. And that means downtime for employees at their jobs. Very often a chain of calls and emails gets sent before I even hear that someone needs help (in those situations, that IT chain of command is supposed to help users more quickly - if I hear about it, there's been a complete failure somewhere along the line...). I just know that the more users are enabled to fully manage their own systems, the better support can be handled. Not only that, but if teams can plan and execute their own application development updates according their own usage needs, and respond to/satisfy requirement requests that come directly from clients, the speed and responsive nature of how companies can deal with their own common daily workflow challenges, can be improved tremendously. Typically, that situation only occurs when companies have in-house developers and/or other technically capable staff - which is not the case for most small-medium sized firms who must focus on their core business requirements. Adding a small software feature can often tremendously improve the daily lives of employees who use in-house software, as well as the satisfaction of clients - but in a typical outsourced software development workflow, the people using the software often never even get a chance to discuss simple aspects of software use, such as UI issues that could be updated to perform more naturally, with developers who write code. Improving software UX has so much to do with enabling that communication, and organizing responses well. If users themselves are empowered to improve all aspects of their own software workflows, then that process can be improved dramatically, and everyone can work more effectively. Just replacing Google Sheets and Forms with the database part of Baserow, with it's autogenerated forms and REST API, goes such a long way to enabling better and more malleable software workflows for employees. The next level of Baserow no-code functionality - the Application Builder - enables so many more common specialized uses to be implemented for the data tables in the Baserow database. That's enough to enable a tremendous variety of workflows in businesses of all sorts. And of course, if you use basic Python and Flask to extend those applications, there's no shortage of developers who can come in and quickly update those pieces (that sort of work typically involves common knowledge and skills which are widely available). A new developer brought into a project doesn't need to spend days/weeks getting oriented to the entire massive code base, when those extensions are typically just a few hundred lines of code which can be understood immediately, and further updated just as easily by GPT, Gemini, etc. I've been interested in reducing software development complexity, for a few decades, and I've found only a few fantastic tools along the way, which have made so many things in life possible - but so few of them have actually been usable by a majority of non-developers. I genuinely think Baserow can satisfy that possibility, in a way that is practical and complete enough to be extremely productive and powerful. I expect to make some tutorials shortly :)

I originally wrote this years ago, when I had had some success getting owners, managers, and employees to write their own software with Rebol: https://compute.anvil.app/#?page=moredepth I since shortened that document, because I had been using Rebol to do that, and Rebol stopped being a viable solution after 2012. Since then I've focused on writing software for institutions, often collaborating with other developers, or at least IT, project management and security teams, etc. I think Baserow could help me pick up where I left off with Rebol, and provide an even more effective modern solution, perfectly capable of handling a large majority of the work I see still being required (often desperately needed) at organizations of all sorts.

As I see more videos and tutorials about n8n, it's interesting to see that the integrations which are commonly used and demonstrated first, such as Google Sheets for example, are simply used as a poor man's database system, to store rows of columnar data - just because Google Sheets is familiar to a large percentage of the average office worker population. The database system in Baserow is far more powerful and scalable than using Google Sheets, and I've seen that users of Google Sheets take to the Baserow DB system immediately, so I think that can easily and quickly replace Google Sheets, and several of the other commonly used n8n integrations, for any user. Many other n8n features, such as form processing, are likewise simply poor man's solutions to other features in Baserow which can scale more effectively, and provide more custom functionality, more custom UI layout, etc., using both the Baserow database and application building features. Other integrations, especially those involving hosted services such as Twilio, YouTube, e-commerce platforms, etc. are absolutely useful, and they do offer powerful additional capabilities which are typically required to build all sorts of modern applications... BUT those solutions can typically be implemented with just a few lines of Python code, and can be hosted at a light weight Flask endpoint, with great ease. So n8n is certainly a valid tool to pair with Baserow, especially for employees who want to stick entirely with no-code solutions, but my current sense is that using Python (and AI to help generate code), is a better path for any user who wants to expand Baserow applications to integrate with third party services. With the help of generative AI, Python + GPT may also be easier to implement. Let's see if that perspective changes as I get more experience working with clients to implement some n8n integrations - I'm certainly open to that possibility...

The biggest limitation with Baserow is that it only uses Postgres as the internal RDBMS (as does Anvil). That's not really any sort of technical limitation in terms of capability, but it will keep Baserow from being used in organizations which are married to a particular tech stack - typically MSSQL, which is used by government and other large organizations. For those environments, my big guns have been Anvil with SQLAlchemy and/or plain SQL along with a database driver. SQLPage has also been useful in MSSQL-based environments, because those organizations tend to have analysts, DBAs, and other tech employees who are deeply entrenched in pure SQL for every part of there workflows. SQLPage is also particularly useful for connecting with existing SQLpage schema, and building utility applications/UIs for that schema. I suspect I could have saved myself from having to write a few thousand lines of code building data grids, queries, and CRUD interactions if I'd used Jam.py in MSSQL environments over the past few years - again, Jam.py is a real gem when it comes to developer productivity. I've never found anything else quite like it (wish I'd known about it 13 years ago!) - it's the reason I'm exploring more no-code tools at the moment. It's really opened my mind to how productive certain no-code solution possibilities can be (as well as safe/reliable/trouble free for no-code users to work with). Jam.py is great for developers who want users to create schema and CRUD grids/forms with no-code, and then want to be able to extend that foundation with pure code, with very lightweight resource requirements. Baserow is great as a foundation for users who want to build everything from *multiple databases to multiple web apps/sites, entirely with no-code, in a multi-tenant environment which can be extended by simple API code and/or other no-code API integration solutions. NocoDB with Appsmith looks like a potential alternative to Baserow, for environments where working with only a particular specified RDBMS is acceptable. Nocodb version 250.2, or using an integration via n8n does apparently support MSSQL. Data API Builder is another solution I'd like to get to know, which could be paired with Appsmith, or directly with MSSQL. And Appsmith can also be used with Baserow, so I'll likely focus on building some tutorials for that too. These tools are actually fun to use. After using generative AI so much during the past 2+ years, to increase productivity, it's nice to explore more deterministic systems which are truly ultra-productive, fully self-contained, and comprehensive in terms of installation requirements, project management, etc. Baserow gives me a feeling that's similar to when I started using Anvil, but the entire build system is open source and freely installable and controllable on your own server. The open source Anvil server has been fantastically powerful and comprehensively useful, and everything in a project can be built with pure code and delivered entirely using Anvil-app-server, but those hosted IDE tools at anvil.works are sure productive! With Baserow and these other open-source no-code systems, it's great to see something like an entire hosted SAAS platform that's so quickly, easily, and freely (MIT & beer) installable on a self-hosted server. And BTW, VPS hosting solutions have gotten to be great. A2 is fast (but more expensive after your first contract ends (I did 3 year contracts - still pretty inexpensive after that)). Hostinger has some nice features (SSH console in the browser, for example), and Contabo is fantastically cheap (reliable, etc.), starting under $50 per year for really capable servers. Atlantic.net has been a great solution for hosting that must be HIPAA compliant, starting around $2500 per year - they save a huge amount of expensive monitoring/security/IT work, and offer some real protection against liability. I'd like to learn more about exactly why Baserow advertises HIPAA, SOC 2, and other compliance. That's something I haven't seen with other self-hosted open-source no-code tools. If that's fully legit, together with Atlantic.net, that opens up some fantastic possibilities in health care software development (and in any other environment where security is critical).

Ok, new curiosity unlocked. I've been watching people generate the JSON which defines n8n workflows, using Claude. That may just trump any sort of other productive development workflow that I've seen yet. So n8n is now re-positioned near the top of the heap of no-code tools to work through...

Another thought about using Baserow with databases other than Postgres, could be similar to how we've used Anvil with MSSQL in a few projects (involving significant development efforts longer than a year). In several cases, IT and security teams approved the use of Anvil's Postgres back end, but only to store configuration information used by anvil-app-server. Then within Anvil server module code, we interacted with MSSQL using SQLAlchemy and/or a Python MSSQL driver and SQL (and sometimes making calls to stored procedures in MSSQL via SQLAlchemy, etc). In one of the bigger of those projects, we also made zero use of Anvil's auth system. Instead, we built a 2-stage auth system from the ground up in Python, using LDAP controlled by the organization - so that when DBAs removed an employee from Active Directory, those employees automatically lost access to the application. The second phase of the auth system enabled application managers to control internal access to features, for each given user (and usernames/hashed passwords for that system were stored in MSSQL tables, so it was all ultimately controllable by the organization's DBAs). So, we basically used only a small fraction of Anvil's most useful framework features in those cases. Because PHI was only ever stored by our application in MSSQL tables, which IT and security teams managed and monitored viciously, their security requirements were satisfied. We provided access to the Postgres config tables used by Anvil to handle its internal operations, so they could monitor that PHI was never being entered into the internal Anvil Postres database system. For those projects, Anvil was basically useful as a development environment, for handling project files, building UIs, routing front end interactions to back end functions, editing server and UI code in the browser based IDE, etc. - and those few features alone still led to huge productivity boosts in the full scope of the project work (not to mention easier access for some critical team members to take part in development). Baserow could be used similarly, as a basic web development shell to handle simple page layout, styling, navigation, auth, and any DB operations which don't involve PHI - and basically all the guts of PHI CRUD are handled by any other development system which connects to MSSQL. As with the use of Anvil, this negates most of the deep productivity benefits of using the framework, but just as with Anvil, what's left of the usable components in the framework can still be significantly helpful in improving productivity. For example, if all queries are performed using SQLAlchemy, UIs are laid out with Bootstrap, and all those pieces are delivered at Flask endpoints - those are all very lightweight bits of code, which can be kept neatly modular - just like the calls to Anvil server functions from front-end UI components were in previous projects. Keeping those MSSQL queries separate, and not having to interweave them in a larger project codebase that includes building UI navigation, page layout and styling, auth, etc. is a nice and neat way to separate concerns. You lose all the productivity benefits of Baserow's database system (and its integration in Baserow's applicaiton builder), just as we lost the productivity benefits of Anvil's ORM integration (autocomplete in the IDE, etc.), but the overall effect is still that the project moved much more quickly, and each MSSQL interaction was neatly separated in easy to manage codebase bits. Of course, in this configuration, SQLAlchemy and Python don't need to be the tools used to handle interactions with MSSQL - any productivity improving tools could be integrated within the basic Baserow project layout. Those integrations are all just achieved with iframes, so any system capable of producing web UI can be dropped in.

One of the things that comes with Baserow, even the open source version, is a pile of pre-made templates organized for all sorts of businesses/purposes, include database schemas and complete applications. I installed every one of them, and used the export function to save all of them to zip files. That project export and import functionality in Baserow is great BTW - your can download all the databases and applications, including all the database structures, application code, and/or even all the data in all the tables within an entire workspace, with a single click. Install another instance of Baserow on another server, upload the exported zip file (which you can open and freely explore in its entirety - it's all just JSON, XML, image files, etc.), and your total complete workspace is migrated, data and all, with a single click. That is absolutely slick.

I added this summary to com-pute.com: https://compute.anvil.app/#?page=nocode I'm having especially good initial success getting clients using Baserow. It's certainly a permanent addition to my tool set.

I've started making tutorials for Baserow. Here are a few simple examples that will be in the first videos: https://forum.101compute.com https://forumauth.101compute.com It's been taking about an hour to explain how to use the entire Baserow database & application builder system, and fully demonstrate how to build some fundamental apps like that, which make use of multiple linked tables with various filtered and sorted views, authorization, navigation, some styling, etc. I've never seen such a simple development system which can be used immediately by users with zero technical background, and which is so easily extensible. The page about no-code on com-pute.com has been updated: https://compute.anvil.app/#?page=nocode For my needs, Anvil is still the go-to framework for big projects, because it's proven itself in such a wide variety of projects. Jam.py is my current favorite for quick in-house projects, and I'm hoping to put it to use in bigger efforts (it's so flexible, and can save so much time - I just haven't had a new big client who I've wanted to start with it yet). My hope for Baserow and n8n is to get clients building their own in-house solutions, or at least building the database parts, whenever possible. Since all Baserow database features are available via REST API, that makes the whole system nicely decoupled from other development tools, so I have no qualms building with it. The way jam.py connects with any common RDBMS, makes me feel similarly comfortable building with it (I've already made a few little tools with both jam.py and SQLPage, for example). I do think the Baserow API model is going to be more flexible, simpler to connect with, and potentially more productive than typical SQL interfaces. I have been searching for accessible production-ready solutions like these for several decades, and have high hopes they will enable non-technical users to accomplish a lot on their own - they're a perfect fit for AI assisted software development.

This recent experience with no-code reminds me of looking at REI3 previously: https://rei3.de/en/features I think it's unfortunately a bit harder for non-technical users to learn, but the open source version has many more features than Baserow, so it may be worth taking a look at it more. When I evaluated it previously, the features were impressively comprehensive, but I had a sense it was a bit less easily extensible than pure code tools, and not as easy to use as most no-code tools, so I never built anything for production with it...

Looking at it again, REI3 packages up so much of what's needed to build production business applications, but I think it's just too complicated for the audience that would be attracted to Baserow and n8n. It's a shame, REI's features are really comprehensive.

Some even more basic Baserow tutorial demo apps: https://todo.101compute.com https://todo2.101compute.com

Some even more basic Baserow tutorial demo apps: https://todo.101compute.com https://todo2.101compute.com

Reflecting on why REI3 didn't strike me to be as effective as Baserow, the most important piece of a no-code effort is the database. That's where Baserow really shines. Compared to jam.py, the Baserow database has more features and is just strikingly easy/intuitive to use. The number of data types, the simplicity of UI, the facility of linking relational tables, the ability to create sharable views with table/gallery/form and other optional layouts, the number of built-in formulas, filter/sort/group/aggregate features, and the whole multi-tenant/multi-user workspace system, is just so dead simple and slick. But the most important part is the automatically generated REST API access and web hooks for any database which users create. This is what makes it so straightforward to extend, with code and/or tools like n8n. Baserow's database is a great no-code foundation, and enough to solve many data management issues all on its own, without ever even building an application. It's a far more capable and simple to use drop-in replacement for Google Sheets and Forms, for example, for most typical data collection and storage tasks, and basic computation tasks. The feel of a nice professional SAAS-like interface makes it especially approachable - it feels like a modern, instantly accessible and intuitive 'environment' for users to work in. And of course, if you want to pay $10 or $18 per month for a pile of extra commercial license features, you can do a lot more without every building custom application features (tons more UI features, integrations including AI fields, etc.). Even without the application builder piece of Baserow, just giving users a way to build that database with an API and web hooks, is what forms a solid basis for building applications. You can start with that and build any required application interface and functionality, using *whatever development system is appropriate - code, no-code, or any mix. It's the fact that the database and all its features are automatically available via API, which opens it up to universal access by any tool, and the web hooks provide the ability for your own custom endpoints to be automatically called whenever any specified data in the database changes. Build applications from the database, using *any tool which can access an HTTP endpoint, including n8n and other no-code systems that add functionality and connectivity to virtually every other commonly used SAAS and office tool. The Baserow Application Builder is basic, but it adds just enough capability to build authenticated, public facing access to data in the database, in a simple enough way that office workers can actually build useful web sites and apps from their database, without needing any other code, and without ever touching any other tools or seeing a line of code. Beyond that, extending whatever they build is simple, with *any software development tools - either no-code tools which office workers can learn to use, or any language/tool which a developer can integrate immediately, using any light weight framework of choice and some simple decoupled code.

Hi Nick, I like a lot the experience you have gained with no-code like tools and I am learning a lot. I have a question: which tool do you suggest to create mobile (Android/iOS) apps?

Progressive Web Apps (PWAs) with Anvil have satisfied my needs for mobile, because I generally don't build apps for the app stores. PWAs can be installed with an icon the home screens of Android, iPhone, and Chromebook devices, and can work offline, so they're functionally effective for users. In the past, I used SAP Build App (formerly Appgyver), Thunkable, NSB Studio (formerly NS Basic), and Flutterflow to build actual mobile apps. Flutterflow was absolutely kicking at the time, especially for building really nice UIs.

I added some more Baserow examples: https://teachers.101compute.com (a music instructor search app) https://contactus.101compute.com (a basic Contact US form)

And a really basic web site example which pulls teach info from the database: https://websiteexample.101compute.com

Since the beginning of the year, I've been fully immersed in projects which involve millions of lines of SQL code, many tens of thousands of MSSQL columns, views, and deep relational schema complexities, every imaginable compliance and security requirement, endless IT challenges, systems which handle PHI and money, and all the human challenges which are involved with building systems that are critical for clients' livelihoods and organizations' function. Building little tutorials examples with no-code tools for a few days is pure joy!

I created some Baserow tutorial videos: https://www.youtube.com/playlist?list=PLgTEMdNoNNOQ_TpDkt8Ruc6CTu6cYeBzm They are very raw unedited first run-through recordings demonstrating how to use the Baserow no-code Database and Application builder. They cover how to create a Supply Purchasing database, Todo List CRUD app (versions with and without authentication), Public Forum app (auth and no-auth), Search tool, Contact Us Form, and Basic Multi-Page Web Site. They're suitable for users who've never used Baserow and never done any sort of software development work (5+ hours of screen recorded walk-throughs of building complete applications). I'll re-record these all at some point to make much more concise and clean versions, but until then these may be useful to new users.

I added a few more walk-throughs to the Baserow tutorials. The last one demonstrates the basics of extending Baserow with any programming language/tool that can interact with REST APIs. I'll add a bunch more in this category of tutorial, to demonstrate all sorts of integrations, as well as interesting UI extensions, as well as using n8n to perform the back-end integration work, instead of Python.

Even without the Baserow Application Builder, its database API system, along with the Database Builder, is fantastically productive. Baserow's database UI/features absolutely demolish other backend tools like Pocketbase, Appwrite, etc., when it comes to ease of use and speed in creating/editing tables. The addition of the App Builder, as simple as it is, really does enable no-code users to accomplish just enough to actually build useful authenticated apps and sites. Together with the Baserow Workspace tools (user groups, version management, import/export/migration, etc.), Baserow forms a very effective multi-tenant project management system. And the key is, it's instantly understandable by absolute beginners, and it's so quick to get comfortable using. The way it integrates with other programming languages and tools is super slick & simple too. For Baserow no-code users, it's dead simple: just pass some values to a custom API URL, and display results in an iframe. For developers it's also dead simple too: just accept some passed values and return whatever UI output/interface is required in the Baserow iframe. This is a really clean and practical separation of concerns. BTW, I built the first version of the little geographic distance demo app, which I used to introduce extending Baserow with APIs, using Flask, but the version that made it into the video was built with Anvil. Anvil actually pairs great with Baserow as a development server environment because you can create a free Anvil account and begin writing REST APIs immediately, without having to configure any server environments - and then you can of course move any production code to your own servers and run with the open source anvil-app-server.

Baserow is an especially interesting paradigm shift. I started pairing it with Anvil to extend capabilities with Python, but now I'm building a tiny Flask framework to do that work with a lighter micro back end. Together with some generative AI, new productivity levels unlocked &#129299; Any other programming languages/tools, n8n, etc. can be integrated the same way. I absolutely love the potential to enable clients to take a significant part in their own development efforts. *Very little* training is required to enable offices workers to start building core bedrock pieces of new applications with Baserow: database schema, project management, auth, web UI, etc. can be outsourced to client work, with some ongoing hand-holding to ensure good schema principles and safe implementation choices are enforced. Pair with special monitored VPS hosting, and so many core IT and security issues can get taken care of with far fewer resources. The separation of concerns appears to work out really nicely with Baserow, in actual practice. No-code users pass values to a custom API URL, and display results in an iframe. Developers just accept those passed values and return whatever UI output/interface is required for the Baserow iframe. And much of that 'developer' work can be accomplished by tools like n8n, or any programming language tools which work with REST APIs. Baserow's automated API generation and web hooks enable that - it's that primary capability of the Baserow platform (automatic REST API access to any database table), along with the absolutely dead simple database UI, project management, and CRUD application builder features, that enhance productivity. Baserow effectively eliminates so much of what SQL, ORMs, AJAX, GIT, JavaScript, Bootstrap, jQuery, React, and complex tooling that frameworks like Django, Flask, Rails, etc. are used to accomplish, along with essential network and IT skills needed to handle routine project management requirements (Linux and other OS configuration skills, SSH command line handling of session managers (like tmux), environment managers (like venv), file and directory handling, etc.), and knowledge about endless other tools - all those things are essentially wrapped up into an absolutely intuitive, extremely easy to use, no-code interface, in Baserow. That's what makes it possible for average computer users to build genuinely complex databases, to safely store, filter, sort, and query thousands of columns of information, with hundreds of linked tables, after just a few hours of instruction - and then to build auth, styled UI, navigation, etc. around that database, and then to connect that all with other software tools via REST API, all with zero code. All those things are 100% automated in ways that completely eliminate code errors, complexity, frustration, and wasted time/effort. There's no debugging or testing needed to ensure SQL queries are written correctly. There are no API endpoints to build, no serialization of data to JSON structures for AJAX transfer, no parameter lists to wire up between front-end and back-end functions (you even see live dynamic values from any data source you pick, visually, directly in the IDE, as you simply point and select database schema). There are no command line interactions needed to configure environment settings for each new project, or to migrate existing projects (either on the same server or between development and production environments) - just clickable selections. Building complete API accessible schema can be as fast as importing a CSV, JSON, or XML document. There's no HTML, CSS, JS, Bootstrap, jQuery, React code, etc. to wire up (that's all visual, and you click a button to see how responsive layouts adjust to different sized screens). Any back-end or front-end tool can connect directly to your database tables, and to the entire work environment, without any ORM or SQL, or any requirement for those tools to even be installed on the same server. You can build any extension as a black box, with any tooling that is effective (including other no-code tools like n8n). And if you want to dive deeper, you can build custom components for the framework, with Django under the hood. It's how all those features play out in practice that's striking. Working with Baserow doesn't feel like 'development' work, or writing code. It wraps up so much of what typically takes a lot of detailed effort, into dead-simple quick and natural interfaces. So many complex solutions I've seen and used over 40 years, to 'simplify' every level of the development process needed to create end-user data management applications, get beat immediately by the Baserow tooling. That's why I say it's an interesting paradigm shift. It accomplishes a lot, to form a rock solid application foundation, in a way that's so easy to integrate and extend with almost any other programming tools. And there's so much more I haven't mentioned here which is available in Baserow's commercial features, like AI fields (automatically connect GPT, Claude, Mistral, etc.), AI formula generation, a bunch of useful UI components and features, etc., if you want to pay $10 or $18 per month. I won't go down that path, because most of features are easy to add with code - and if you use any of their commercial offerings, you have to pay for user seats, and their SAAS offering all come with data caps - none of which is true of the open-source system. The open source license, BTW, is MIT (use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the software, with the only requirement being the inclusion of the original copyright notice and permission notice in all copies or substantial portions of the software). I'm using Python with Baserow right now, but I'm going to spend some real time integrating n8n, to offer even more no-code solution capabilities to clients...

There has been a main theme in so much of what I written about creating end-user software, for 25+ years, after a prior 20+ years of using software development tools, languages, and environments. That writing (about actual accomplished work) has all been about enabling productivity in the natural world, enabling normal human activities, as opposed to just building tech environments. I've always been excited by how technology leverages effort, enables organization and communication, and controls useful systems in the real world, etc. I've always been interested in how the massive majority of non-technically minded people can be enabled to create their own simple technology solutions, instead of being trapped into using systems developed specifically to paint users into obligatory, complex, expensive commercial locked-in ecosystems. Rebol enabled the first true realization of those hopes. There were so few (or really no other) tools which ever enabled those goals, anywhere nearly as effectively, for many years. In the past few years, I've used a pile of actually powerful and useful tools, not so much for non-technical users, but for developers. SQLPage was one of them. What a cool little tool for analysts, DBAs and anyone with SQL background. And jam.py is such an awesomely simple little system, with a no-code interface to DB schema and CRUD, plus some other critically useful and effective tooling (auth, automatic logging, soft-deletes, ORM, front-end/back-end wiring). And jam.py had actually existed in anonymity and oblivion for many years. And of course, for me, Anvil+Python has been a great package of tools. But I had stopped trying or even hoping for solutions which non-technical users could implement, even though that possibility still seems just as deeply worth while as it ever was. LLMs, and software development systems based on them, are absolutely exciting, and people are using them. I can't wait to see how tools like Lovable evolve. But there's something about having an open-source no-code system which can form the basis for building complex database systems, without requiring any AI help, but is still perfectly suited to being extended by AI generated code - which can enable really powerful capabilities, so simply and immediately. Baserow and n8n have been the first tools in the past few years which have gotten me excited, toward the end of enabling non-developers. The idea of building production software with LLM code generation alone, without the significant oversight of a developer/engineer, is still not viable for deep and serious production work involving lots of complex schema and features, security concerns, etc. But with Baserow, n8n, etc., the potential for more and more of that work to be accomplished easily and safely by non-technical users, increases dramatically - and when paired with some LLM generated code and some experienced human developer/engineer guidance, I think the possibilities are impressive.

What just happened to me after writing the last post, is a *perfect example. A client called to get some help with tmux sessions and user configuration in Ubuntu, along with HTTPS configuration, file management, and some other server management tasks related to several existing projects on their VPS. It took about an hour, nothing difficult to deal with, but it sucked some time from other priorities in my schedule. Every one of those things would have been automated by Baserow. I can think of hundreds of hours of work I could have avoided with that same client, on previous projects - not just project management, but CRUD and UI tedium which could have been eliminated with Baserow.

I went poking around with psql in the embedded Postgres database, in one of my test installations of Baserow. It's always good to see SQL can be used to access everything (I'd recommend using a stand-alone postgres install, so more tools can connect easily), but wow, the UI and API are certainly each orders of magnitude more pleasant and productive to use than SQL!

I don't think I've mentioned it, but one great feature of Baserow is real-time updates. If you make a change to any cell and any database table, every view, for every user, is automatically updated in real-time, without requiring any refresh. For many applications, this can be a significantly important feature, and implementing real-time updates often either takes a lot of work, or requires particular infrastructure. This is just one more benefit to add on the huge pile of features enabled by Baserow. I've been writing a new business plan based on Baserow, n8n, and other no-code systems. With existing clients, initial efforts have been extraordinarily successful so far - for me these tools really constitute a whole new world, they provide a foundation and context for AI tools to be applied and become more useful/capable, and they enable owners, managers, employees to take a fundamental part in building tech which reshapes workflows and reforms entire business operations. I'm still using Python to extend Baserow, but have built a tiny framework to implement and edit Flask endpoints which integrate directly with any Baserow database and application UI. That workflow is so lightweight and simple to use, together with AI code generation, it enables users with only some basic coding background to jump right in building extensions. It's much easier, for example, than orienting new developers to work on a large Anvil project code base, much simpler to separate concerns. It's also quicker to orchestrate workgroup access to only the pieces which need to be attended to. Basically, you provide access to any database, table, column, etc. with an API key which enables only the create, read, update, and delete permissions you want to enable for those pieces of the database. You can create as many different API keys as you need, and it only take a few seconds to click on some checkboxes in the Baserow UI. The REST API access to the database is far simpler to work with, and more universally understandable than some custom ORM which would required for any particular web framework - and it's entirely language agnostic. You can use any tools you want to return UIs which display any output, from computations based upon data in the database, or otherwise (connections with 3rd party system of any kind, etc.). I think this may end up being the most practical architecture I've ever seen. There's a world of n8n users out there already, and they'll know immediately how to build extensions for Baserow databases and applications. There's absolutely no trouble building one extension with Python, one with n8n, one with Rebol, etc. So whenever a business owner, manager, employee needs a special feature built, they can use whoever is available in-house at the moment, who has some skill with any programming technology whatsoever, or get on fiver and hire a someone to build a feature. The on-boarding to bring someone new into a project virtually nothing, and the ability to separate their work from the rest of the entire project is dead simple.

Next on the list for me to explore is Windmill: https://www.youtube.com/watch?v=lxqdncP8XR4 Holy crap that looks like a slick system - so much more configurable and capable than I expected when first looking at it. This is not a no-code system, but it looks like a great pairing with Baserow, to do anything that can't be done with Baserow, with lots more control UI styling, connectivity with existing systems, APIs, etc. Use any of the common programming languages. Open source.

It's a damn shame, the Windmill open source license limits number of users, groups, etc. :( That keeps me from spending any time with it, for now. Windmill is a full code solution, so maybe still a useful tool for some personal project which don't involve collaboration. It's also possible it could be used as an alternative to the little backend Flask framework I put together for Baserow. Hosted Anvil is also a super quick and easy alternative for users who don't want to host their own server - you can use just the back HTTP API endpoint functionality, or embed entire full stack app with a front end, directly in Baserow - I've got some tutorials on that - it's a really quick solution to extend Baserow applications with Python. Hosted accounts are free forever at anvil.works if you don't need to install custom Python packages, then they stat at $15 per month, or you can self-host. I've set up quite a few self-hosted Anvil servers at this point - it's a heavy installation, but easy to manage. Baserow open source enables unlimited workspaces, databases, applications, users, etc. I still think the option to extend its features, for no-code users, is likely best handled by n8n.

It turns out, even n8n's license limits projects which pass users' credentials to 3rd party servers. This is one of the main sticking points I've always had with the entire no-code/low-code industry. I understand of course that companies can only build and support a quality product long-term if they survive financially. It's just a stark contrast that so many commercial development tools flourish with open-source foundations, and so few no-code tools are actually open-source without limitations. Baserow does enable additional features with 2 levels of commercial monthly/yearly subscription options, but the core system, including the app builder is MIT, with no limitations on the number of workspaces, databases, rows, users, API calls, etc. for the self-hosted version. There are limitations on the types of users in the open source database part of Baserow, but those limitations can all be handled by extending the system with your own custom code. So for now, Baserow does have the best total set of features I've ever seen in a completely open-source no-code toolkit. Jam.py is even less limited, but it only does no-code database, CRUD grids and forms, auth, logging and other core features - which may be enough for many clients who just want to be able to build DB and CRUD functionality, and don't want any other no-code application building features. Baserow's workspaces and it's general feel, though, just seem to be so much friendlier and productive for users without any development experience - and the builder part makes the prospect of genuine no-code really approachable. The other side of the argument is that some clients do prefer to pay for the Baserow commercial services. I was approached this week by a school organization in Thailand who had already decided to use Baserow (they do receive an education license discount). For them, with the number of user licenses involved, and the volume of work Baserow's commercial offering simplifies, they don't hesitate about their chosen subscription cost. I won't ever suggest encumbering a client with subscription service fees for tools, especially if they involve charging for or limiting users or usage volume, but that model clearly does work for some organizations and purposes.

I'm currently using Baserow in production work with 3 clients, and beginning development on 1 long-term project. In every case, client training has been staggeringly easy: Import CSV files from existing spreadsheets, set data types for imported columns, normalize schema, add formula/lookup/rollup columns to perform calculations and aggregations with linked data, create sharable views with required filters, sorts, groupings, password controlled access, etc. From there, depending on the project, optionally build user group tables and use the Baserow application builder to enable authenticated CRUD interactions with data sources (views), build navigation between UI pages, and/or share password protected views and automatically generated forms. Finally, build any external service integrations, special computations and UIs (anything beyond CRUD, filter, sort, group, authorize, and basic UI layout, styling, navigation), and perform any real custom software development work, by connecting with the Baserow database via API (using Python, n8n, any programming language/tool). I've built enough custom integrations in the past few weeks to know that the Baserow API is phenomenally simple to work with (much preferred over typical framework and language-specific ORMs), and the API/iframe based workflow enables flexible integration choices (using any tools that are best for a given job), and great separation of concerns - so onboarding a new developer to build an integration, and to keep them away from any deep code base, is dead simple and quick. The biggest initial training challenge is getting non-technical admin users who've never heard of an RDBMS, to understand how to normalize schema. 80% of that is just getting users to realize that if certain data values are used in multiple tables (for example, contact and demographic values), that info should be included in a separate table, so that the values are not duplicated and/or require updates in more than one place. Also, if table headers could potentially grow to include and unknown number of property1, property2, property3... columns, then those properties should be stored in a separate linked table which can expand to include any number of rows. And of course, lookup lists should be stored in separate tables, if they ever need to be editable, and/or related to multiple columns of values (using hard-coded dropdown selections for single values is not a problem in Baserow). I've been able to get started with clients by pointing them to a list of introductory videos which take about an hour to watch, and then spending 1-2 hours helping build the foundations of normalized, linked tables required for their project (typically starting with Excel/Google Sheets exports). For the quick projects, we'll typically run through a dozen-ish tables during a first meeting, and to get the client comfortable using the Baserow interface - and that's been enough to get off to the races. From there, they can build their own schema & views, and start asking me to build integrations/automations, to perform special computations, to connect data with third party APIs, to make use of web hooks to respond to any interactions with the database, to prepare documents in a given format, etc. I've been astonished at how well and how quickly this process has been going so far, with everyone who's begun to use it. I expect Baserow (and possibly jam.py) to be a permanent part of many development efforts with future clients. The particular features and benefits of Baserow, form a fantastic foundation for all sorts of projects.

The interactions with clients who are using Baserow, and the whole approach to the entire software development lifecycle, is so interesting and fundamentally different than normal. The typical cycles of collecting requirements, building prototypes, responding to change requests, running through agile adjustments to engineering choices, etc., all get eliminated or fundamentally improved. Instead, the process starts and progressing much differently. It becomes much more about using the knowledge clients have about their own data and workflows. By teaching them, very intuitively, along the way about how to normalize their own database, and to help build that database themselves (with whatever technical help is needed), many of the typical development cycles disappear. And when your clients inevitably say something like 'oh, we forgot to tell you about some ___ data source(s) or workflow(s) that need to be integrated, dealing with those situations goes back to starting with how the data sources fit into their understanding of their own workflows - and they can be directly involved in that process, instead of having to wait for a developer to build a schema, and an entire full stack prototype to demonstrate how a particular engineering choice may work for their needs. With Baserow, I'm able to get people who've never heard of SQL, to actually build sophisticated schema, with genuinely well thought out normalization, immediately - and that process happens before any development work is wasted building prototypes, going back and forth about adjusted requirements, etc. - every developers dream. I started this tiny tutorial for clients: https://nocode.101compute.com/schema_tutorial We're able to dive right into real schema engineering and normalization efforts, instantly, with Baserow. The key that makes a new sort of workflow possible is that Baserow eliminates all the technical challenges to building that sophisticated schema. Users instantly perform the tasks which would typically require 10's of thousands of lines of SQL code - including all the table creation, datatype selection, foreign keys/joining/lookups, creation of views with filters, sorts, groups, interfaces with authentication, etc. - and all safely, without any need to debug/test query code for any of those tasks. The no-code tooling in Baserow doesn't just save time/effort in development work - it enables this entirely different approach to engineering and software development workflows. The key is, all the schema which you develop with your clients, by working directly with them to properly organize and normalize core data structures - as useful as that is all on its own in the Baserow database UI (with all the features that UI enables: sharable views, forms, grids, galleries, etc. - that's enough for many projects, without doing any development work) - it furthermore forms the foundation architecture needed to satisfy any additional application requirements, because the REST API is automatically generated for any schema that gets created directly in the database UI (whether that work is accomplished by clients, and the developer just provides required help/guidance, or if a developer does any of that work, wherever needed - that's all easily collaborative). The API then enables any other software development tools to connect with the database schema to process data, integrate 3rd party services & any language ecosystems, to deliver more specialized UI interfaces, computational processes, etc. I'm just speaking from a few weeks of production work, but holy crap this has been interesting and more fruitful/productive than I ever previously though was possible. What I'm experiencing, working with clients so far, is a full realization of what I had originally hoped might some day be possible with Rebol, but it's far simpler to implement and on-board (truly zero resistance from clients - it's immediately understandable and instantly usable), and yet much more robust, than I could have ever hoped for, with any code based solution.

Jam.py enables many of these capabilities, but you must accomplish any additional custom development work within its established Python/JS code framework tools, using the built-in ORM, just as you would with any other framework. Jam.py is brilliantly engineered and lightweight, and generative AI can be used to speed up the development of any required application features, and the capabilities, plus the connectivity enabled by the 2 combined ecosystems of Python and HTML/CSS/JS, is virtually limitless - but it still requires code, and none of that can be used or even understood by non-technical client. The no-code features in Baserow are much deeper/broader, and much more ergonomic, instantly approachable and usable by clients with zero technical experience. It's the absolutely dramatic facility of Baserow's implementation which makes working with non-technical clients on schema, views, and even many core application features (auth, styling, navigations, etc.), the genuine game-changer.

This recent journey in no-code has been so enlightening. I originally became interested in jam.py because I realized it had the potential to replace so much CRUD work, especially the time consuming routines needed to create grids and forms with full CRUD capabilities. It's features could have saved many hundreds of hours just in the previous few years - mostly because I had to do sooo much grid-heavy work (sooo many custom tables with full inline CRUD editing features...). That's led to an unintentional evolution in my thinking about the whole approach to software development process and lifecycle. Software engineers have previously required years of experience, with many tools and skillsets, to effectively implement databases, authenticated user interfaces, and complex integrations with 3rd party services: Python, PHP, Java, C#, C++, Ruby, etc. HTML, CSS, JavaScript, Bootstrap, jQuery, React, etc. SQL and RDBMSs AJAX Django, Flask, Rails, etc. Network, IT infrastructure, and security knowledge Linux and other OS configuration & command line knowledge (ssh, tmux, venv, caddy, ufw, etc.) Skill with IDEs, supporting infrastructure, and deployment methodologies GIT and versioning system knowledge Docker, Kubernetes, and container orchestration Knowledge about endless other tools, languages, and frameworks... Rebol proposed to replace tools like that with simpler solutions, engineered from first principles. That proposal could have worked if it had become popular, but Rebol eventually lost because it couldn't keep up with the requirements to integrate with the rest of the world's tools and ecosystems. So now we're in this situation where the rest of the world's commercially successful architecture is pervasive, and the need to simplify not only development architecture and tooling is oppressive, but there is an even bigger necessity to connect everything. So what tools like Baserow and n9n do is dramatically simplify solutions to those requirements. All the tools and disciplines above are now built into, and fully automated by the newest no-code systems. That massive integrated foundation of useful tools, paired with dramatically simplified control interfaces, make it possible for any average computer user to build complex databases and connected software systems. The simplified interfaces and workflows make it possible for anyon to safely store, filter, sort, group, query, and perform calculations upon thousands of columns of information, with hundreds of linked tables, after just a few hours of instruction - and to integrate easily with virtually any 3rd party system. I'll share more specifics as these current and upcoming projects evolve.

To be clear about one point: compared to Baserow, jam.py enables far more flexibility to build any solution, with any degree of feature customization, which can possibly be accomplished within the constraints of the tools it's built upon (the RDBMSs it supports, its ORM system, as well as Python, HTML, CSS, JS, Bootstrap, jQuery, etc.). You have total authority to use those tools to dream up and build any, virtually limitless custom software capabilities which can be achieved within those ecosystems. For a developer, it's about as simple and productive an open-ended framework as I could imagine. And beyond being super-productive for developers, jam.py opens up the possibility of being used by non-technical clients, at least to build schema and CRUD interfaces which serve as a rock-solid foundations for more malleable interfaces, integrations, and complex systems. And of course, it's so light weight, and requires so little hardware or software infrastructure. All together, that represents a significant improvement over the approaches and capabilities of so many typical frameworks and tools. It's honestly brilliant. Baserow isn't nearly as flexible (can only use Postgres, for example, as its primary RDBMS), but the no-code database tools are slicker and more easily approachable than in other tools. They enable really complex schema development, and deeply capable shared views and forms with every sort of filter, sort..., real-time updates, etc., for people with zero experience writing code - in a way that is instantly useable. Beyond that, the no-code application builder is 'good enough' to be fundamentally useful for non-technical users. And the automatically generated API enables developers to integrate in any way, using any other development tools. It's that combination of deeply powerful no-code database tools, fundamentally useful no-code building tools, and the API interface to extend and integrate those tools, which hits a sweet spot which I haven't previously experienced. So, even if some of that system (app builder) is nowhere near as flexible or capable as any sort of full code framework, the ability to so easily extend and integrate it is what makes it so powerful in the end. This new development workflow and approach to working with clients who want to have more control and involvement in the process, is what's so exciting to me. In the past, I have exposed SQL and ORM interfaces to users, and in fact have built a mature methodology & set of tools to enable custom report building, for example, which integrates with SQLAlchemy and pure SQL, for users who wanted those capabilities, and had some technical background. SQLPage was also similarly useful in cases when users had SQL experience. But a full system which enables so much more involvement, from the ground up, with so much less effort, and so many fewer required skills and no required previous tech experience, just opens up so many doors to a totally different way of working with clients to develop complex software.

I added 2 more tutorial videos to the playlist at https://www.youtube.com/playlist?list=PLgTEMdNoNNOQ_TpDkt8Ruc6CTu6cYeBzm 1) A simple Point of Sale (cash register) app, which integrates with a small custom Python API (created in Anvil), to email sales receipts to buyers. 2) A quick and easy method to convert Google Docs word processor files to Markdown which can be displayed as web page content in Baserow apps (retaining layout without editing effort)

I'm looking at every alternative to Baserow which could potentially perform better or provide some benefit, but I haven't found any which I like more. Directus is very powerful, and has the most backend features, but it's just not easy for non-coders. It's not hard to use at all, it just can't compare with Baserow in terms of facility. It think for developers it's a really worth while tool to use (connects to all common RDBMSs, endless features). I'll certainly use it for a project to get to know it better, but I won't plan on using it for projects where no-code is a core part of the development process. Nocodb works very similarly to Baserow, and connects to Postgres and MySQL, but doesn't have an application builder. Saltcorn has many similar capabilities as Baserow in the end, it requires less memory, and can work with SQLite at well as Postgres, and I think it's a very interesting tool, but it's just not as easy, quick, and slick to use as Baserow. As simple as it easy, I think most average users would not enjoy working with it as much. Saltcorn does have Android and iOS app builders, so I will certainly work with it a bit more myself, but I don't think it's attractive and outrageously easy enough for the majority of people without software development experience to just get immediately. For every client with no software development experience that I've worked with so far, Baserow has made instant intuitive sense, and they've all begun using it immediately. I'm been only encouraged by how easily it's been adopted, and we can very quickly and easily begin working on normalizing significantly sized schema, multiple views with filters, sorts, groups etc., in just a few hours of work. It's forging utterly new paths to building software for clients. They know their data and their workflows, and they're able to work on building their database, and much of their application requirements, immediately. It's a completely different experience for me. Once I've got a bunch of projects under my belt with Baserow, I'll retrofit everything I've learned, into workflows with jam.py. I think most people with be able to use the schema building pieces of it almost as easily. There's just something so fantastically simple and intuitive about how normal business people have been able to use Baserow - it's very surprising!

For my own use and for use with some tech savvy clients, I'm focusing on Directus. It offers most of the backend features which are commercial offering in Baserow, free and open source. Unfortunately, the database interface in Directus is not as sleek as Baserow's, so I think average computer users might likely resist the learning curve. But for many of my clients who have technical experience, Directus is a great back-end foundation. It connects to all the common RDBMSs, the interface is still no-code (although not as simple to use as Baserow), and you can interact with SQL as well as auto-generated REST and GraphQL APIs. You can build multiple forms and views with multiple filters/sorts/selected fields, it has built-in graph/chart features, very fine grained auth, etc. It's the most powerful no-code back-end system I've seen which makes all the features entirely free and open-source. No general front end builder (aside from lots of view options for database tables (including calendar, kanban, etc.)), but still a huge productivity booster for projects that involve more technically capable admins.

Ugh. Ugh, ugh, ugh. I just found out today that going forward, Baserow will begin charging for authenticated users in their app builder, even in their open source version. I think that will kill the app builder for many purposes, and for the open source community. I don't yet know if existing released versions will be subject to those licensing fees, so there's a potential those existing versions could be used without fees, but I don't expect they would ever be updated. I've build authenticated systems already which connect with the Baserow database - it's ridiculously simple to do with GPT, but that still involves code. The main thing which really set Baserow apart from every other tool in the no-code space, is that they created the no-code app builder, which enabled authenticated access to the database, and up until now those auth features were totally free, unlimited, and open source. I think they've really shot themselves in the foot by converting that feature into a paid license product going forward. Ugh, this reminds me of the decisions Carl was forced to make by investors in Rebol. Ugh.

I'm pushing on to explore NocoBase (not NocoDB), which has many more core features than Baserow in the open source version (including fine grained auth). Their commercial offerings are expensive, but you pay once for lifetime ownership, rather than subscription. NocoBase does support more RDBMSs than Baserow, and it includes a full no-code application builder. As with all these no-code tools, I'll have to see how non-technical users react to the interface, since intuitive instant facility interacting with the system is most important to enable adoption. If a complicated interface turns away non-technical users, or even elicits a hint of resistance, it's not useful for the goals I have with the no-code approach. Saltcorn is still very interesting to me, because it's an end-to-end no-code system, including an application/site builder, without any commercial features or versions whatsoever, and because it can build mobile apps for iOS and Android, as well as web apps. It supports Postgres and SQLite only, which is suitable for many environments, and it's lightweight - not as light as jam.py, but it's features are all no-code. I'd like to see how users respond to the Saltcorn interface - it's clunkier than most of the other tools with commercial feature options, but if if users get it, it may end up being a useful tool. One final solution I want to explore more is Directus version 9 (because it doesn't have the $5million funding license limitation - there are no limits or restrictions on that version's open source license), together with Noodl as a no-code front end builder. Noodl looks powerful, and it can be entirely white-labeled, but development seems to have stalled last year, right after they released the open source version. It may be worth getting to see which forks are active, if any...

I really like Nocobase, it's a serious tool. It doesn't have the pizazz that captures new users in Baserow, but it's actually got many more features and layout possibilities in the application builder, and it doesn't try hard at all to push any commercial features. It feels and looks much more professional than Saltcorn, and will likely appeal to slightly more technically interested users. Tutorials to follow soon...

Baserow has confirmed that they will charge for auth users even in the the open source version of the builder. 5 users are provided for free, and monthly billing of $4 per user will apply to only active users in any month. This is a workable solution for all my current clients learning Baserow. That's an insignificant cost for businesses with a dozen admin users, for example. For situations where up to five roles are required, the 5 free user accounts can be treated as group/role logins. And for situations which require unlimited public logins, such as public sites where unpaid visitors need accounts, the current version 1.33.4 will always be available, frozen in its current form, to enable building for unlimited free users accounts, and it's a mature production version. Finally, it's dead simple to enable your own custom auth system by extending Baserow with some simple backend and UI code for any content that needs to be authorized, just using a plain old database table that stores user information, hashed passwords, etc., and building whatever UI is required to access authorized data interaction. The Baserow password field type automatically performs hashing, so this is all very easy to accomplish - just include your auth logic in your own custom code. Any developer can build a custom auth system like this in a few minutes, especially with the help of GPT.

GPT, BTW, is absolutely fantastic at working with the Baserow REST API - for building extensions, I prefer the API paradigm of accessing a database, over any traditional ORM methodology, SQL, etc. No contest. And all these no-code systems implement that paradigm. It's a huge game changer. So Baserow is still perfectly usable, in one way or another, even for systems that require auth user accounts. I'll make a video about all the solutions, so that the pay situation doesn't turn away potential users - it's like file uploads, any of the paid specialized UI interfaces, etc. - all those commercially available features just help to simplify creation for non-technical users, but you can roll your own custom code solutions so easily, for any requirement (I already did a few videos and created examples about several such solutions). In the meantime, Baserow's changing paid auth situation pushed me to temporarily dive into NocoBase, and I love it. More power and many more features - basically all the features you need to pay for in Baserow - are free forever in Nocobase. Nocobase can also use any of the most common RDBMSs as the database foundation, which is critical in some environments (especially MSSQL), you can use pure SQL right in the builder, etc. (and the SQL schema is easier to navigate, outside the Nocobase environment). NocoBase's existing UI builder is also much more robust than Baserow's, so it reduces required UI coding work, and all its other free features are integrated drop-in no-code solutions. I haven't seen another no-code system yet with as many free features - too many to list here. It does have a mature visual workflow system, for example, which can take the place of many tasks which n8n is typically used for. The only thing missing, compared to Baserow, is Baserow's super slick spreadsheet-like database interface. Don't get me wrong, it's still extremely easy, intuitive, and fast to use, compared to any sort of code solution, so I'm curious and excited to see how users with zero technical background take to it... NocoBase strikes me as a more capable all-around solution than Baserow, ideally suited for organizations which have a few technically savvy users in-house who perhaps aren't developers, but are smart, capable and driven enough to build entire end-to-end no-code solutions. The case studies on the NocoBase blog about successful implementations in large and small organizations are a great indication of how successful it already has been. These are exactly the sorts of situations that I've imagined no-code being useful for. No-code tooling has improved so much, and those already established real-life cases prove that it's not just a pipe dream to actually build successful solutions entirely with no-code. I think most no-code solutions will eventually run into some custom requirements which need code. What's so exciting to me is how easy it is to integrate those custom solutions, in all these recent no-code frameworks. I really do think the auto-generated REST API methodology (and add in GraphQL with some of these system) is far superior to the traditional ORM-in-a-framework engineering approach. It just separates concerns so much more completely, and enables any third party tooling to be integrated. You're not stuck with the integrated tooling built into a single framework. Most traditional frameworks enable REST APIs to be created, of course - but the difference is, you need to do all that *work in custom code that you have to write yourself - just like you need to do all the CRUD *work needed to create, read, update and delete records, in grids and forms, for example. And you need to build UIs for all the routine interactions that are part of *every single development project of any sort. It only makes sense to automate all those common pieces, to the point that even using code automatically generated by AI tools can't come close to the facility and control enabled by these super-sleek and well implemented no-code systems. Code generated by AI tools still needs to be debugged, tested, refined, and that takes work, and can lead to errors. Solutions implemented with no-code tools do not need to be debugged, tested, refined, etc. in the same way. They just work, and they are deterministically controllable. AI can then just be employed to help build custom features, and that work can be integrated in the easiest and most versatile ways possible. The biggest piece which is most important to me, though, with the whole paradigm of using no-code as a foundation for projects, is that it enables end-users to take part in the conception, the development process, the maintenance, and every other part of the entire life-cycle of a software project. It changes so much about the approach. And it removes the drudging work that sucks joy out of so much traditional coding work, in a way that feels joyful and relieving - similar to how AI code generation helps relieve drudgery with minutia. Current no-code tools provide a foundation for AI-assisted development, which far surpasses any expectation I could have ever imagined, for productivity and simplicity in creating complex software solutions, even just a few years ago.

Don't forget that all these systems are meant to be genuinely extensible, from the ground up - they all enable you to build reusable framework modules.

Saltcorn has the most plugins of any of these systems I've seen, 119 in the github account, all MIT: https://github.com/orgs/saltcorn/repositories?type=all You simply click on them in the 'store' and they're installed in your instance (and the store is an open source plugin pack which is installable on your self-hosted server): https://store.saltcorn.com/view/Extensions The creator of Saltcorn has been really hard at work on this for years, creating all sorts of practical tools. That's a really impressive list. All the comparable no-code tool have similar approaches: create database tables, create views with filters/sorts/groups/etc., place views in layouts, organize those views within pages of a public facing site/app, manage those apps as separate projects with the tool workspace. Saltcorn is the only one I've seen which doesn't hide any advanced features behind any sort of paywall - and it actually provides the largest number of features and extended capabilities, by a very very long shot, which potentially makes it the most useful for true end-to-end no-code development. You can build web apps and package iOS/Android apps with it too. It also appears to be the least known of all the comparable competing no-code tools. This one is going to take a little longer to really get to know completely, because the number of plugins is so extensive. The other no-code tools can be mostly mastered in a week or two, but just going through 119 plugins, plus all the base features in Saltcorn is a project (one I'm looking forward too!).

In the meantime, I've also gotten to know Nocodb (a totally different product than Nocobase). It's perhaps the simplest of all these tools - takes just a few hours to learn how to use all its features. Just like Baserow, it has an almost identical super-slick, easy to use spreadsheet-like interface, but it has no application builder component. The benefits of Nocodb are that it offers more free features in the open source version (calendar and kanban views, user access controls, for example are all open source), and it can connect with more RDBMSs than Baserow. Baserow only works with Postgres, and Nocodb connects with Postgres, MySQL and SQLite (and there may already be an existing version that works with MSSQL, which I haven't tried yet). That makes nocobase useable as a cool little no-code web based front end interface to SQLite, something which is useful all on its own. So, you have to build applications and front-ends over Nocodb entirely with other tools, using Nocobase's REST API and webhooks (just like with Baserow), where Baserow has enough built-in app building functionality to create complete basic navigable sites/apps, especially for CRUD interactions and user access control (auth) with the underlying database. I'm most interested in evaluating Appsmith, Noodl, and Tooljet as potential options to build front-ends and to integrate/extend features for Nocodb back-ends. What I'm finding with my current clients who are adopting no-code, is that the key requirement for their involvement is the super-simple spreadsheet-like database builder interface which Baserow and NocoDB provide. Saltcorn, Nocobase, and others have a more traditional wizard/steps interface which seems to me to be just as clear and simple to uses, but non-technical users all just glaze over as soon as they see that sort of interface. It's the spreadsheet-like interface which everyone is immediately able to grasp and begin working with. What an interesting psychological study... I think there may be a line drawn at that point, between what business people, office workers, etc. have the capacity/interest to take part in. They know their data and their workflows, and involving them with schema and query design to enable working with their own data, is where the real benefit lies. Even the dead-simple app-builder in Baserow, however, is more than non-technical users appear to want to dive into, at least initially. The great thing is, that's a nice clear line in the sand - giving admin end-users (owners, managers, and other admin staff) the ability to build schema, views, filters, sorts, groupings, etc., to import/export data between spreadsheets and database tables, to control multi-user access roles, etc. - that's what forms the necessary foundation to get them involved in a different sort of development process that eliminates many of the traditional cycles of gathering requirements, building prototypes, getting UX feedback, debugging, testing, repeating, etc. The spreadsheet-database interface in Baserow and Nocodb provide a 100% approachable workflow to involve users in building core CRUD foundations for an application, and any integrations/extensions can be handled with other tooling, including no-code UI tools (Appsmith, Tooljet, Noodl, etc.), other no-code workflow integration tools (n8n), and any other traditional software development languages/tools. The great thing is that all these tools are just really slick and productive layers over deeply established paradigm such as RDBMS, SQL, web UI, REST API, which are accessible/integrateable with any software development tooling. You can access any of the DBs with SQL, connect any of the tools with REST API and web hooks, and interchange an web UI ecosystem with any other, all very fluidly. Using Baserow or Nocodb, for example, doesn't keep anyone from building UI with any tool whatsoever. It simply eliminates all the barriers to working with data in the database, and improves efficiency because debugging and testing is not required for what would otherwise require a massive amount of SQL or ORM code. That's just all free, without any down sides. And if I want to connect a database created with Baserow or Nocodb with extensions available in Saltcorn, integrations available in n8n, APIs built in SQLPage, grids/forms built with jam.py, etc., etc., that can all be handled directly at the SQL level, or with REST APIs, web hooks etc. So many barriers disappear, and time consuming work is just eliminated.

I do think completely AI generated software solutions will replace all the tooling we currently have, for many purposes, in the not too distant future, but we've still got a ways to go - and even when that happens, I think there will be reasons for using current tools. I expect super-intelligent AI will eventually build better tools which perhaps humans won't even be able to understand. But we're humans, and for many purposes, we like doing things ourselves, being entirely in control, and enjoying the creative process. Some people live off-grid, and I'm sure some will choose to live entirely off the AI grid, for many reasons. Beyond that, I think some tasks just won't require AI, especially when they're so simple to accomplish as using Baserow, for example. I can imagine telling an agent or robot to go through a pile of documents, organize the data and upload that info into a Baserow table, where I can do useful things, and where other AI tools can easily connect with that data. In the meantime, I'm having so much fun learning these tools. Becoming totally proficient with Nocodb (from installation, to building DBs, to connecting other RDBMS, to integrating other tools with the NocoDB API, etc.) just took a single sitting. And non-technical users can use the most important parts proficiently in a few days. They're that easy to use. It's also so interesting to watch non-technical users just take to Baserow, and begin using it. It's that intuitive. I've spent a few hours with most of my no-code clients, demonstrating how to use the UI, import CSV files, set datatypes, explaining some basics about schema structure, foreign keys, lookups and basic normalization concepts, and they're off doing their own thing for all sorts of useful purposes - with the understanding that extending and integrating that data is easy for me to handle, whenever they need custom features/integrations beyond CRUD, queries, user management/auth, etc. And the database part of Baserow and NocoDB are effectively interchangeable, so you can pick your preferred features, but the core of each is basically equally effective as far as I can tell till now (I'll do some performance testing with large datasets this week...). And of course generative AI is fully involved in building any solutions on top of these tools, so no effort is wasted anywhere during the process of adopting and integrating these systems. Business software development is getting to be so much more productive than I could have ever imagined just a few years ago. It's amazing, software development tools had seemed such a mess, in very recent memory.

I understand that so much of this all sounds the same, but it's not. I could, for example, show new users how to create a data table in Anvil, using it's built-in visual builder, in a few minutes. I could also show them how to lay out a data grid and UI controls on pages, so that they look like a complete application, also in a few minutes. On the surface that appears pretty similar to what you get in most of these no-code tools. But then I'd have to teach them to write at least a few hundred lines of code for every page and functionality, just to perform all the basic CRUD operations, to wire up navigation and authorization, etc. And even if I could get a few rate non-technical people to learn how to do all that work, perhaps in a few weeks, all their code would need to be debugged, tested, and most likely heavily refactored before being put into production. All that goes away with these particular no-code tools. The devil is in the details, and these tools ready do address common problems, and dramatically reduce the workload and many possibilities for human error, throughout the most common phases of basic application development.

I have been through soooo many of these tools. Today I worked with appwrite, tooljet, appsmith, windmill, and others. They all have some promise, but most are just huge and way too complicated for non-technical users. I think Baserow will continue to be my go-to for non-technical users who have a reason to be involved in the development process. There's just nothing quiet as simple. I'll use Anvil to extend it with features and to integrate it with other systems. Anvil still continues to be my big guns for virtually any sort of work, although Flask gets used a lot for smaller projects. I still absolutely love the simplicity, light weight, and in-browser IDE features of jam.py. I'm coming to appreciate it even more and more after doing this deep dive of no-code tools. Jam.py is a more traditional framework with an ORM, but it's a complete system (it enables full extensibility, connectivity, UI building of any sort, etc.). It connects to every common RDBMS, and runs virtually anywhere (I've run the server even on my old Android phones and on decades-old laptop and netbook machines). There's massive capability, flexibility, and ergonomic facility enabled by that little toolkit - it's a truly unique gem, which just takes a few seconds to install, and the features are tremendous. For any client who has technical staff, but still prefers some core no-code capabilities, it will be a go-to. It pairs nicely with SQLPage too - that combination is fantastic for groups that involve DBAs, analysts and other pros. I'm hoping to get more opportunities to complete some big projects with it... Saltcorn will also get a lot more of my time. It think it has the potential to be one of the most capable and versatile pure no-code tools, with all its extensions. I just need to get more experience using it to see if it will fit in with the no-code plans, to satisfy some particular situations... Appsmith is also really powerful. It's a bit heavy and complicated, but it may appeal especially to clients who have some backend experience and need a no-code front-end tool kit. I'm going to have to see if n8n is worth introducing to people. My sense is that the sort of work people to with n8n is likely just better left to Python and other pure code tools, especially with the help of generative AI to write code. Finally, I've only spent a tiny bit of time with Windmill. It's not a no-code tool, but I think it may be productive as a way to integrate many of the no-code and full code tools with custom full-code back-ends, without having to do as much server configuration work. It's multilingual, supports a pile of integrations built-in, and can help build UIs. If it can prove that it adds some real productive benefit, it could potentially be worth its weight. When I get out of this no-code dive, I'm looking forward to running through some work with it, to potentially satisfy some of my own needs. For now, Baserow + Anvil, jam.py (+ SQLPage sometimes), and perhaps Saltcorn as I learn it better, should be able to solve any no-code development patterns that I'm interested in implementing.

Saltcorn is loveably simple, and it has an amazing number of built-in features and modules, but it's the least professional looking - plus I noticed it's been exploding memory use on several servers, so I hate to say it, but I think it's out of the running for any production work. NocoDB uses the least RAM of all the usable production quality no-code tools I've tried in this deep dive (aside from jam.py which is teeny, but also not all no-code), so I'm encouraged to work with it more. Baserow actually uses the most RAM of all these tools, and NocoDB has basically an identical database interface (plus it can use and connect to more RDBMSs). It provides similar multi-tenant workspaces, a spreadsheet-like schema interface builder for database tables, type selections, formulas, automatically generated REST APIs, webhooks, as well as unlimited user auth (and unlimited databases, tables, rows, etc. in the OSS version), and additional view features such as calendar and kanban which are paid commercial add-ons to Baserow. The big difference is that Baserow has a built-in no-code application (CRUD UI) builder - but I'm just not sure that's actually required for the no-code users I want to work with - as cool as it is. NocoDB is just the database part (with sharable authorizable views that provide filters, sorts, groupings, aggregations, formulas, etc. - all synced with authorized API access for users/groups). In my work, all these tools will eventually get paired with some Python framework, for integrating other systems, for document generation, to perform any computations of any sort beyond CRUD, filtering, sorting, aggregations, excel-like formulas in the database cells, etc., and for building specialized UIs. What I'm experiencing with no-code clients is that they dig in immediately with the database interface, and that's where their involvement is most likely to end. Tellingly, the overwhelming majority of application examples in Baserow are database-only (no web app built around them) - the database interface *is the 'app' interface for that majority of templates. The database interface handles auth and workspaces and schema building/linking and views and filter/sort/group/aggregate/formulas, etc., so for in-house applications, nothing else is needed. For building public facing apps from this sort of no-code foundation, Anvil is my preferred first go-to - it works great for building UI, calling the DB API, handling webhooks, etc., but of course it's heavy. Flask is my go-to lightweight framework, especially for projects that don't need a lot of front-end prettiness. I'm really starting to think that tools like Streamlit and NiceGUI may be a perfect fit with NocoDB, to provide application UI, deeper integration, logic, document generation, and all the rest of the real custom computing requirements needed to extend the no-code platform. NiceGUI especially, may end up being a great fit because it's built on FastAPI, so you can build REST APIs with it to handle webhook calls from the database (web hooks call an external API whenever a specified update or query is made to database rows, or when scheduled events occur, etc. - to perform some integration such as sending email or connecting with another 3rd party system of any kind to perform any sort of process). Again, Anvil and Flask are great tools for all of this, but it's great to have options, and these database systems really breath new life into the likes of Streamlit, because you otherwise need to use SQLAlchemy or SQL with it, which of course is not something I want clients messing with, and typically that code is integrated at least to some degree, with the UI and the rest of the application code. These API driven database systems with super slick UIs (Baserow and NocoDB especially) enable a great separation of concerns between the database layer and everything else, and they enable non-technical users to safely and easily build and interact with a database system to organize the data they know best - those clients know intimately what information they interact with daily, and it's that ability to change how requirements are established and how the production database can be built more efficiently and effectively, and continue to evolve more naturally over the lifecycle of an application, which is what's driving all my interest in these no-code solutions. I've been amazed at how much work my no-code clients have gotten done, with Baserow especially, in just a few weeks. This is the kind of work that would have required many months of effort in Rebol, for example, by experienced developers. And this is all without the help of any AI - that productivity enhancement comes afterword, to help build custom features from the database foundation. Baserow does more than I think is required, for how I want to implement no-code tools with clients (by including the application builder). I really like that NocoDB uses something like 1/20th the RAM (!), has many more free features and capabilities in the open source version, and can connect to more RDBMSs, but otherwise looks and acts almost exactly the same. A lightweight system to build UI and extend integrations/custom computation capabilities is what's needed to turn it into a real software development foundation. Anvil, Flask (+HTML/CSS/JS), Streamlit, NiceGUI, SQLPage (untested yet with these tools), and/or any other framework in any other language ecosystem all fit the bill. I'll also continue to work with NocoBase (totally different than NocoDB), because it's got a significantly capable app builder with fine grained auth controls, more UI and view features (calendar, kanban, great navigation, etc.), multi-tenant app workspaces, etc., and it uses much less RAM and other resources (about 1/6th that of Baserow). I'm honestly just not too worried about the size of Baserow, because it's multi-tenant. All these multi-tenant systems only get installed once, and hundreds of projects can use that same installation. Hundreds of projects, even with tools as small as jam.py and SQLAlchemy (even Rebol!), can end up taking up lots of resources because each single tenant install requires some duplicate environmental resources. These few weeks have been extraordinarily useful. The no-code options are getting narrowed down significantly, and I'm really familiar with all the benefits and drawbacks of each of the tools I've tried. I'm bummed that Saltcorn ended up being a flop for my needs (plus it's also basically single tenant BTW) - I had some initial high hopes for it, but what I'm left with feels fantastic, with lots of potential production solutions. I'm still going to spend time with n8n at some point, but a wide range of lighter weight Python solutions fit the bill better to extend and integrate the no-code tools, for my interests - especially with the ability to generate code with GPT, Gemini, etc.

NocoBase has a very capable application builder, and I just found out that style and script tags can be used inside Markdown blocks in NocoBase's Markdown renderer. It's powered by Vue/Quasar/Schema-form, and allows raw HTML with CSS for styling and animations, inline basic JavaScript, etc. You can include data pulled from database fields in moustache syntax, directly in Markdown text. All that dramatically improves NocoBase's layout and content capabilities (it's Markdown features are far and away more capable than those in Baserow). Nocobase already had the best navigation and fine grained auth controls, as well as lots of fully open-source unlimited features that are paid add-ons in the self-hosted Baserow distribution. It also connects to more RDBMSs, is multi-tenant, and uses about 1/6 the RAM and fewer system resources that Baserow requires. Additionally, it has a no-code workflow builder that enables users to accomplish much of what people use tools like n8n for (including built in AI tools, email, etc.). It doesn't have the slick spreadsheet-like database UI that Baserow and NocoDB sport, but it's definitely a strong contender with a professional look and feel, and it can be learned in a day. NocoBase also has a significant history of real world use cases at large organizations, with a strong track record in production environments. It's very quickly moving right to the top of my list of no-code tools.

I updated https://compute.anvil.app/#?page=nocode with the final results of this epic no-code deep dive. I extensively evaluated more than 15 no-code tools: https://baserow.io https://gitlab.com/baserow/baserow https://www.nocobase.com https://github.com/nocobase/nocobase https://www.nocodb.com https://github.com/nocodb/nocodb https://n8n.io https://github.com/n8n-io/n8n https://jam-py.com https://github.com/jam-py/jam-py https://rei3.de/en/home https://www.tooljet.ai https://www.appsmith.com https://www.fluxscape.io (noodl) https://directus.io https://appwrite.io https://supabase.com https://pocketbase.io https://saltcorn.com https://budibase.com https://www.crossui.com https://www.joget.org https://webstudio.is The winners for me are: Baserow: Pros: Super-slick, immediately useable spreadsheet-like database UI. Easy to use app builder for creating authenticated web sites/apps with CRUD. Security (even satisfies HIPAA requirements when configured/hosted/managed properly). The best multi-tenant workspace and project management, with the easiest version management, backups, and migrations. Everything in Baserow is easy enough for non-technical users to begin using immediately, and it's very powerful compared to every other system. Cons: Only uses Postgres - fine for most in-house private projects, but not for orgs with other existing database infrastructure. Baserow is also the heaviest resource hungry solution (although multi-tenancy makes this less of an issue in practice). Many features which are free in other tools, are paid add-ons to the open source version of Baserow. Auth users in the application builder especially, although this is workable, and the existing mature frozen version will always be available, with unlimited free auth users. The 'made with baserow' image is prominently visible everywhere (can be removed as a paid upgrade, but this requires paid user fees). NocoDB: Pros: A much lighter weight version of an almost exactly similar database system as in Baserow, with the same super-slick immediately useable intuitive spreadsheet UI, auto-generated REST APIs, webhooks, etc. Importantly, it connects to all the most common RDBMSs (where Baserow is Postgres only), including those with existing schema - this makes NocoBD the best system for providing no-code access to all the most common RDBMSs, especially in orgs that already are committed to a particular platform. Basically all the add-on features which require payment in Baserow are available for free in the open source version of NocoDB, without limits. Just like in Baserow, the database UI itself can function as the application interface for internal apps (the spreadsheet UI and sharable views with filter controls are the interface). NocoDB is also multi-tenancy, but light enough to support many installations on a single inexpensive VPS - so multiple orgs or department installations, for example, could be handled on an single server, all with separate admins and entirely discrete workspace environments. Cons: NocoDB does not include any no-code application builder for public facing apps/sites (although publicly sharable views and forms do go a long way). I'll pair it with Anvil or Flask for those purposes, and to extend it in any other way (but the REST API and webhooks will connect with *any software development language/tools). White labeling still requires payment, but the NocoDB imagery is much less oppressive than the Baserow image, and if you're building your own front end with other tools, this isn't an issue. NocoBase: Pros: The most feature-complete open-source app builder, with the most fine grained access/auth controls, navigation options and layout capabilities, plus calendar, kanban, gantt, map views, a built-in visual workflow editor (to handle complex logic, connections to third party APIs, emails, webhooks, AI integrations, etc.), all entirely free and unlimited in the open source version. White labeling is not much of an issue even in the OSS version - NocoBase links are hidden in menus, and a few inconspicuous text links. Connections to most RDBMSs are available. Access to database schema and data, at the SQL level, is the simplest of all the systems I've tried. Multi-tenancy is also well supported. Cons: The data source UI isn't the super-slick spreadsheet type which I've found non-technical users tend to adopt instantly (but it's still absolutely dead simple to use). You can use any of the common RDBMSs as the foundation data source for your install, for free, but connecting to other existing DB schemas requires a paid add-on (not so much of a problem because those situations typically involve orgs with some funding, and all the NocoBase add-ons are pay once for lifetime use, no subscriptions anywhere). Baserow has a great set of all-around features for clients who have a reason to use no-code, and completely non-technical users. The paid features offer some legit benefits for costs which are trivial in any professional implementation, and you can do everything you really need with the free features. NocoDB is a phenomenal light weight no-code database interface for building in-house apps on any common database, for completely non-technical users. Most orgs will limit their no-code involvement to the database parts anyway, and rely on developers to build custom public apps, UIs, and other extended features on top of that foundation. Office workers can learn this in a day (as with the database UI in Baserow). NocoBase is geared towards users with more of a technical bent, who want much more control over application details. It's still dead simple compared to any programming language tools, and very powerful/flexible. I'm looking forward to using it for any projects where it can serve as a productivity enhancing foundation for professional work, especially for clients with some technically savvy employees I imagine analysts, IT professionals, and technically capable owers/managers without much development experience really being able to do a lot with NocoBase.

All these systems enable users to perform CRUD work visually, and then developers can easily build isolated extensions to handle unique computations, data processing routines, UIs, and 3rd party integrations as needed. One of the key differences with traditional frameworks is that, along with enabling visual creation of schema and any number of views with filters, sorts, groupings, etc., the tools above all automatically create a REST API and webhooks, instead of relying on an ORM to interact with the database. This enables any software development tool to interact with the database (i.e., database interactions are not just limited to framework tools and/or SQL, and the code interface tends to be simpler and more productive with REST APIs). The whole no-code approach with the tools above eliminates a huge percentage of typical software development work needed to build front-end code, back-end code, database (SQL) code, data transport (AJAX) code, and serialization between all those different layers, along with all the debugging and testing cycles which are typically a time-consuming and potentially error prone part of that effort. All those pieces of the development process can be accomplished easily, reliably, safely, and securely accomplished by users without tech experience (and developer work is dramatically reduced). The ability to involve end-users in the schema development process, and even in some levels of logic, UI, workflow, and integration development, fundamentally shifts the engineering process away from the traditional routine of collecting requirements, building prototypes, building, testing, collecting UI and UX feedback, repeating... to one in which end-users, who know their data and intended workflows best, have the ability to understand and get involved in creating their database schema and other pieces of the application they'll use. Non-technical users typically need help with normalizing linked table structures, but the technical ability to create those structures can be learned in a few minutes with the no-code tools above. For any integration, extension, or computing capability which does require coding, that work is easily integrated with the tools above, with a separation of concerns handled as cleanly and simply as is conceivably possible. Developers don’t need a long on-boarding process, to get to know a huge code base and development stack, or clearance to work with an entire database & particular software development tools. They can simply connect to whatever database REST API system admins make available, using keys which provide access to only the bits they need to work with, and they can use any tools which are appropriate/approved (any language, framework, etc.).

I'm sure a huge percentage of professional developers immediately turn their heads away from any conversation which even includes a mention of the words 'no-code', but that's a seriously limiting perspective. There's a reason tools like NocoDB have 55,700 stars on Github. They are powerful, productive, seriously capable tools, and I think any developer who holds on to any hope of maintaining a competitive professional edge, should be fully able to use these tools to improve productivity, and to improve the whole approach towards working with clients and engineering solutions that are most effective and practical in production environments, in real organizations, with real people who face all the typical challenges involved in accomplishing real-world work on a daily basis.

I very much appreciate you documenting all this.

I hope it's helpful. The video tutorials for Baserow should get you going - maybe I'll do one with Rebol3 and/or Red just to show how to interact with the REST API (I already made one showing Anvil, Flask, and JS). I'm make some tutorial videos for NocoDB and NocoBase soon.

BTW, NocoDB enables JS scripts to automate workflows, perform CRUD and more complex operations, transform data, collect input from users with interactive prompts, integrate with external third-party services via HTTP requests, display results in formatted tables, markdown, and more - built right into the web interface, with code completion: https://nocodb.com/docs/scripts Also, the newest version of NocoDB support Postgres, MySQL, and SQLite. If you need official support for MSSQL, you can still get version 0.250.2: docker run -d --name nocodb-mssql -p 16000:8080 nocodb/nocodb:0.250.2 That's the only one of these tools which has MSSQL support out of the box for free, so it's a really special gem for environments which require MSSQL support. You can buy a current supported connector to MSSQL for NocoBase, with a lifetime license (no subscriptions for any of their products), which for an application builder with MSSQL support, is among my top 1 or 2 choices for future projects. Orgs which use MSSQL are used to paying absolutely huge fees for their infrastructure tools licenses, so the expense of a NocoBase MSSQL connector license isn't even a blip.

I sent the message below to one of my clients: I think you're going to be amazed by NocoDB and NocoBase. NocoDB is basically the exact same thing as the database part of Baserow, but has many additional open-source/free features like grid/form/gallery/calendar/kanban views, entity relationship diagrams, a JS code interface built in, and it requires about 1/20th the RAM and far fewer hardware resources to run. The UI is genuinely easy enough for users with no tech experience, to start using in a few minutes. NocoDB not only replaces admin tools like DBeaver and HeidiSQL, with an app that runs directly on the server (so doesn't require any local install - runs immediately in any browser on any machine) - it more importantly provides a REST API interface, so that *any programming tools (regardless of language), can connect to the database. It also enables web hooks, so that API endpoints you create in any language, can be called automatically whenever updates to rows occur, for example. So for example, you can use R and RShiny to build extensions, integrations, custom UIs, and to perform custom computations, on the database, all with just a simple REST API connection (which GPT can immediately write perfect code to utilize). Creating views with complex filters, sorts, and groupings, setting up any number of authorization access controls for particular users, etc., is dead simple, all entirely no-code. You can use formulas in the no-code interface, just like non-technical users are used to doing in Excel. So, an *enormous amount of the typical work writing, debugging, and testing CRUD, aggregation, and view code is 100% eliminated - and you can even have totally non-technical end-users easily build pieces of their own applications (this is legitimately and safely possible, in ways that could never be possible with code). You can even use it to set up web UI interfaces and network access to SQLite databases (as well as Postgres, MySQL, and MSSQL). I don't know of any other system which provides those services in the same way. NocoBase has even more features than NocoDB, including a very capable and professional looking no-code application builder (instead of having to work with HTML/CSS/JS), a deeply capable no-code workflow builder (to build logic, automation, and third party integrations with a flowchart-like UI wizard selection interface - without having to use any programming language), AI integrations, chart views, multi-tenant app management, super fine grained auth controls... I've been doing a deep dive on a massive pile of every imaginable no-code tool (several hundred hours over the past few months), and expect that these few tools will seriously improve productivity in every development project I work on going forward. They change the whole development process, right down to the core routines of how requirements are established, by enabling non-technical project managers, end-users, etc. to more clearly understand, communicate, and take part in the fundamental engineering/development process. Users can hand you spreadsheets, which immediately become full databases - and even do that work entirely themselves. The difference between these tools and jam.py is that jam.py requires code for everything except CRUD, schema building, UI forms, and UI grids (with no-code filters, sorts, etc.). Jam.py's no-code abilities are a super-productive add-on to what's otherwise a traditional web framework, with a database ORM that works in both Python and JS - and it has a built-in web based IDE. It's built on all the most deeply entrenched and widely used web building tools like jQuery and Bootstrap, enables direct SQL in code (as well as the easy ORM code interface, and the no-code interface), and is a tiny install. So it's an awesome framework, and it CAN be integrated instantly, without any troubles, with these other no-code tools, with SQLPage, and/or any other programming tools. None of these tools exclude the use of any other tools - in fact they all encourage and enable integration. The difference with the no-code tools above is that they provide even more no-code capabilities, and impose absolutely no requirements to use any language-specific ORM, UI building tools, etc. They automatically generate REST API and Webhooks, to enable any language tools, and other no-code tools like n8n, to interact with the database - on top of creating schema, views, filters, sorts, groups, etc. without code (which eliminates a massive amount of coding work and troubleshooting). The big thing that's bowling me over is how it's changing the way I can work with clients, and enable them to not only specify requirements, but easily and safely take part in building out their own database and application features - that's something I've dreamt about for 3+ decades.

Oops, this is the most recent version of that message: I think you're going to be amazed by NocoDB and NocoBase. NocoDB is basically the exact same thing as the database part of Baserow, but has many additional open-source/free features like grid/form/gallery/calendar/kanban views, entity relationship diagrams, a JS code interface built in, and it requires about 1/20th the RAM and far fewer hardware resources to run (so you can run it alongside everything else on your VPS, no problem). The UI is genuinely easy enough for users with no tech experience, to start using in a few minutes. NocoDB not only replaces admin tools like DBeaver and HeidiSQL, with an entirely no-code interface that runs directly on the server (so doesn't require any local install - runs immediately in any browser on any machine) - it more importantly provides a REST API interface, so that *any programming tools (regardless of language), can connect to the database. It also enables web hooks, so that API endpoints you create in any language, can be called automatically whenever updates to rows occur, for example. So for example, you can use R and RShiny to build extensions, integrations, custom UIs, and to perform custom computations, on the database, all with just a simple REST API connection (which GPT can *immediately write perfect code to utilize). Creating views with complex filters, sorts, and groupings, setting up any number of authorization access controls for particular users, etc., is dead simple, all entirely no-code. You can use formulas in the no-code interface, just like non-technical users are used to doing in Excel. So, an *enormous amount of the typical work writing, debugging, and testing CRUD, aggregation, and view code is 100% eliminated - and you can even have totally non-technical end-users easily build pieces of their own applications (this is legitimately and safely possible, in ways that could never be accomplished with code). You can even use it to set up web UI interfaces and network access to SQLite databases (as well as Postgres, MySQL, and MSSQL). I don't know of any other system which provides those services in the same way. NocoBase has even more features than NocoDB (similar names, but entirely separate products), including a very capable and professional looking no-code application builder (instead of having to work with HTML/CSS/JS), a deeply capable no-code workflow builder (to build logic, automation, and third party integrations with a flowchart-like UI wizard interface - without having to use any programming language), AI integrations, chart views, multi-tenant app management, super fine grained auth controls... I've been doing a deep dive on a massive pile of every imaginable no-code tool (several hundred hours over the past few months), and expect that these few tools will seriously improve productivity in every development project I work on going forward. They change the whole development process, right down to the core routines of how requirements are established, by enabling non-technical project managers, end-users, etc. to more clearly understand, communicate, and take part in the fundamental engineering/development process. Users can hand you spreadsheets, which immediately become full databases - and even do that work entirely themselves. The difference between these tools and jam.py is that jam.py requires code for everything except CRUD, schema building, UI forms, and UI grids (with no-code filters, sorts, etc.). Jam.py's no-code abilities are a super-productive add-on to what's otherwise a traditional web framework, with a database ORM that works in both Python and JS - and it has a built-in web based IDE. It's built on the most deeply entrenched and widely used web UI tools like jQuery and Bootstrap, enables direct SQL in code (as well as the easy ORM code interface, and the no-code interface), provides full access to the complete Python and JS ecosystems, and is a tiny install. So it's an awesome framework, and it CAN be integrated instantly, without any troubles, with these other no-code tools, with SQLPage, and/or any other programming tools. None of these tools exclude the use of any other tools - all the way down to the OS and RDBMS choices - in fact they all encourage and enable integration. The difference with the no-code tools above is that they provide even more no-code capabilities, and impose absolutely no requirements to use any language-specific ORM, UI building tools, etc. They automatically generate REST API and Webhooks, to enable any language tools, and other no-code tools like n8n, to interact with the database - on top of creating schema, views, filters, sorts, groups, etc. without code (which eliminates that massive amount of coding work and troubleshooting). The big thing that's bowling me over is how it's changing the way I can work with clients, and enable them to not only specify requirements, but easily and safely take part in building out their own database and application features - that's something I've dreamt about for 3+ decades.

I wrote this for a client who wanted more clarification about the difference between tools and what can be accomplished with each: NocoDB's UI is used to handle all admin interactions (creating databases, tables, schema and views, linking columns, adding formula columns), but for internal apps, the UI can also be used as an 'application' interface for database interaction purposes. Users log in and can see only the tables they've been granted access to, with the level of control they've been granted: full admin access to create databases, tables, schema, etc., or more limited access, for example, to only edit data in existing schema, only read data in certain tables, etc. Views can be created in NocoDB which filter and sort data in any way - this takes the place of SQL select queries (even very complex ones). Users can then further filter and sort views at runtime, so there is deeply versatile and composable select capability, entirely without code. Views also can be created to display selected data in various layouts: grid, gallery (card), form, calendar, and kanban. Those views can also be adjusted at runtime to further reorganize and filter returned query values. All views also enable create, update, and delete interactions, so everything you'd do with SQL is possible visually in NocoDB - and those interactions can be limited per user, in any interface. Views in NocoDB can also be shared publicly, with or without password protection, so you make a stand-alone data entry form, or even an entire grid interface with full data management features on a table, for example - and those views can be inserted as an iframe directly into web applications create with any other programming language/tool. In that way, the UI views you create with NocoDB can be treated as 'application' interfaces for users, with any level of varied auth access. The NocoDB interface can function as an application interface, in that users can select any tables and interact with them through visually created views. For many sorts of data management applications, this forms an appropriate and complete interface. If you want to create public facing web sites/apps, however, with content that appears in an entirely customized presentation, with visual layouts, navigation, and UI controls that can be configured to any degree, then you need to add a UI layout builder into the mix. This is what Baserow's 'application builder' does - it's basically a simple traditional web site layout builder, which also enables you to easily insert and interact with data from your databases, without any code. To put that distinction into perspective, the majority of Baserow's numerous free templates don't use the app builder. They provide complex starter templates, for example, one made to run operations at a school, others to manage inventory in retail businesses, to manage accounting, etc. - all of which are admin interfaces meant to be used by back office personnel. Those sorts of interfaces are all created entirely with the database part of Baserow (which is essentially exactly the same as what you get with NocoDB). Baserow additionally has some templates which are meant to create public facing applications and web sites. For example, they have a template which is meant to serve as the web site for a business which provides tours to cities in Europe. That site enables public visitors to search available tours, view pictures, read nicely formatted description text information, maps, etc., all of which are based on data pulled from the back-end database, which admins can edit and create views for. The difference with Baserow, is that you need to pay for some features, including authenticated access for larger user groups, certain view types, etc. (although there are endless ways to work around these limitations with custom code solutions). Baserow also only works with Postgres, so it's meant more for building solutions entirely from scratch, instead of integrating with existing back-ends already built on other RDBMSs (although it can work effectively with other tools that integrate with other back-ends...). Like Baserow, NocoBase does also include an application builder - with even more detailed controls, even more mature navigation and very fine-grained auth options - plus more totally free view types such as maps & many sorts of charts, as well as a deeply capable workflow builder which enables you to perform complex logic operations & integrate with 3rd party APIs, AI APIs, send emails, etc., without needing to use any code (i.e., instead of using any programming language). NocoBase's UI builder, however, is meant to build entirely non-public apps - it requires a login to access anything except publicly available forms (so it's not meant to build static landing pages or public web sites such as Baserow's city tour example). Baserow, NocoBase, and NocoDB all provide an automatically generated REST API, and webhook functionality, to make it really easy for 3rd party software development tools to integrate with databases you've created with those tools. Since REST APIs are universally accessible in any language, this eliminates the need for a language/framework-specific ORM (such as as SQLalchemy, or the ORMs in Anvil, jam.py, R, etc.), and/or any SQL, to interact with the database. Anything that can be accomplished by interacting with the admin interfaces of Baserow, NocoBase, and NocoDB, can also be accomplished via the API (including pulling filtered data from any views). Those automatically generated APIs enable you to build any specialized UIs to interact with data from your database, to perform any specialized computations (using any Python or R library, for example), to integrate that data with any 3rd party service, etc. And if you create any specialized UI view/control with any other tool, you can instantly pop it directly into any UI you've created with the Baserow or NocoBase application builders, as an iframe (so it appears as a natural part of those apps). With NocoDB, those unique UIs created with other tools just stand on their own. You can also create webhooks in your database system to call any APIs you create in a 3rd party programming tools, to be executed whenever a particular state or action occurs in your database (for example, when a row is added to a particular table, or on a given schedule) - without having to constantly poll your database on a repeated schedule in your application code. So you can create an application with Anvil, Rshiny, Streamlit, Flask, etc., all connected to your automatically generated database back-end, without having to use any particular ORM, and without ever having to write any code to create the APIs that enable this connectivity. This eliminates a massive amount of the typical work required in any traditional web framework (as well as the massive amount of SQL/ORM code). All that code, along with the associated debugging and testing cycles, just disappear from the development process, using any of theese no-code database tools. You can use any 3rd party no-code tools, such as Appsmith, Tooljet, Noodl, Webstudio, etc. to build front ends for any databases created with NocoDB, Baserow, and NocoBase, and you can use those third party tools to integrate with APIs created in any programming language, to perform more complex data processing and integrations with other systems. You can also use any low-code UI solutions which include language-specific back ends, such as Anvil, Streamlit, jam.py, Flask, Rshiny, etc. to integrate back-end logic using language specific libraries. NocoBase is about as feature-complete as could possibly be imagined, for in-house apps. It's UI layout, navigation, views, fine-grained auth, and workflow logic/connectively features are deeply capable, all without requiring any code. It has the greatest number of features which are available entirely for free, and all the available paid add-ons are purchased once, for lifetime use (never by subscription), so it's appropriate for building professional solutions which have absolutely no ongoing SAAS or usage fees. It has a bit longer of a learning curve, but still nothing even close to the complexity involved in using any full code programming solution. Baserow is great for projects where databases and apps will be created entirely from scratch, without having to integrate with a existing RDBMS structure, especially if there will be a public site/app associated. The spreadsheet-like admin interface in Baserow, which basically exactly the same as the one in NocoDB, is the easiest for non-technical users to grasp immediately, and its workspace project management features are killer. Creating new projects, version management, backups, migrations, etc., are all absolutely dead simple for non-technical users, without ever needing to touch a server command line. Backing up and migrating databases in NocoBase and NocoDB, for example, requires command line work. NocoDB is awesome as the lightest weight option, for admin management, views of any type with filters & sorts of any type, and auth management, when you need to build on, or integrate with any common RDBMSs. You just need to build custom public web site/app layouts and logic with other tools. Hopefully that clarifies a bit more. I expect that with the right tools, the overwhelming majority of time-consuming, routine, and fatiguing work can be eliminated from most projects. Just the custom, specialized, innovative computational work can be separated and completed with whatever tools are appropriate.

These were suggestions for a client: NocoDB should fit your purposes well. You, and any clients you have, can learn how to use it safely in a few hours, and master it in a few days, without any previous technical experience at all. I can show you how to integrate i with [your existing in-house development tools] and/or any other tools you're interested in mixing in. I set up a connection to our [previous project] development database, using version 0.250.2 of NocoDB (which has support for MSSQL). I could show you how we could fulfill a LOT of the requirements for that project with NocoDB - perhaps that would be the most sensible case study to understand how to actually implement significant solutions in NocoDB. Moving to the database part of Baserow from NocoDB, in case you ever have an interest in using its app builder, for example, requires zero learning curve. And integrating any other tools has virtually no limitations. For most cases when you need to build some public facing applications, you can do it with very basic HTML, easily generated with visual tools and/or GPT, and just include publicly accessible views and forms from NocoDB to handle interactions with your database.

Another momentary thought to save for later: Along with all the no-code deep dives, I've also been performing extended re-evaluations of front-end framework tools, both in the traditional HTML/JS world and among the Python-only alternatives. Webstudio and Fluxscape/Noodl are very cool and really powerful, among the OSS HTML/JS/React tools, to do complex UI layouts, public facing web sites, etc. (and GrapeJS is a super simple little tool that's useful) - but they're all complex to learn, and still require a third piece, an API framework of some sort to run Python, or back-end code using any other language(s). Flask ends up being the go-to for simple Python APIs, along with the flexibility to use any traditional web-based UI framework, but it can get really long-winded (require lots of code) to create even the simplest UIs, which can be attached to some Python code. Anvil has been a massively powerful workhorse that's enabled me to successfully complete more than 500 projects - but it's a huge framework to install on-site, it's memory hungry (fine for big projects, but a lot for little apps), and although you can build Anvil projects entirely using the open-source server and pure code, it's really most productive when you use the hosted visual builder at anvil.works (their SAAS product). You can use that builder for free, so it's not a big deal, and if anvil.works and their SASS visual builder ever disappear, you can still do everything in Anvil entirely with code - but I'd prefer not to have to ever do that with Anvil. So I'm dead-set on having a go-to lighter but still very powerful UI+backend alternative to completement the no-code tools - especially to support web UI and Python together. I've been re-evaluating all the integrated Python web UI tools: Streamlit, Nicegui, Taipy, Reflex, Solara, Flet, H2OWave, Shiny, PWIO, FastUI, Gramex, Flexx, Remi, etc. Along the way, I've been consistently struck by how successfully all the generative AIs are able to build apps with Streamlit, first shot. They now work as well with Streamlit as they do with Flask/HTML/JS/CSS/Bootstrap/jQuery (the gold standard frameworks for AI generated code). And Streamlit nearly universally requires the least amount of code to create any UI solution - and of course that solution can include integrated Python code to do anything that's possible in the py ecosystem. And Streamlit code tends to be very easy to read and edit. And it's a quick install, totally open source, and very well known. So I'm settling on Streamlit as the simplest possible UI and back-end Python integration system. I don't think it's possible to find anything easier and faster to work with. Streamlit does require code, but GPT, Gemini, Grok, Deepseek, Qwen, etc., can all build complete UIs and integrated Streamlit code solutions faster and more easily than is possible with visual builders. And it's got a massive thriving community and large corporate support, so I don't think it's going anywhere. I had soured for a while on Streamlit because it's methodology of re-running the entire script every time a UI value is updated, is unconventional, and takes some getting used to. But the fact is, it's extraordinarily productive. And now that AI's can generate code first-shot better for it than nearly any other tools, it's become really appealing. As an example, here's a Streamlit front-end with integrated Python code, which connects to the demo NocoDB Forum database at http://cmpt1.com : https://streamlit.cmpt1.com That was created entirely with ChatGPT, but it's very easy to follow the code - far and away simpler than any Flask+HTML/CSS/JS/Bootstrap/jQuery option. And here's a dead simple paired-down version of that example, still with full CRUD capabilities: https://streamlitsimple.cmpt1.com Hold on to your seat - that example is a TOTAL of 14 lines of code(!!!): import streamlit as st, pandas as pd, requests API_URL = "https://nocodb.cmpt1.com/api/v2/tables/meb0xsfem6bhqmo/records" HEADERS = {"xc-token": "MYAPITOKEN", "Content-Type": "application/json"} def fetch(): return pd.DataFrame(requests.get(API_URL, headers=HEADERS).json()["list"]) def create(title): requests.post(API_URL, headers=HEADERS, json=[{"Title": title}]) def update(rid, title): requests.patch(API_URL, headers=HEADERS, json=[{"Id": rid, "Title": title}]) def delete(rid): requests.delete(API_URL, headers=HEADERS, json=[{"Id": rid}]) title = st.text_input("New Title") if st.button("&#10133; Create"): create(title); st.rerun() for _, row in fetch().iterrows(): c1, c2 = st.columns([6, 1]) new_title = c1.text_input(str(row["Id"]), row["Title"]) if c2.button("&#128190;", key=f"s{row['Id']}"): update(row["Id"], new_title); st.rerun() if c2.button("&#128465;&#65039;", key=f"d{row['Id']}"): delete(row["Id"]); st.rerun()

That's pretty damn cool. I think the combination of NocoDB and Streamlit will end up being the most hyper-productive combination possible, to accomplish nearly any typical full-stack goal, without imposing limitations on integrating any other mainstream software development tools.

Minor revision of the 14 line example above, to increase nocodb's default limit of 25 rows: import streamlit as st, pandas as pd, requests URL = "https://nocodb.cmpt1.com/api/v2/tables/meb0xsfem6bhqmo/records" HEADERS = {"xc-token": "MYAPITOKEN", "Content-Type": "application/json"} fetch = lambda: pd.DataFrame(requests.get(URL, headers=HEADERS, params={"limit": 1000}).json()["list"]) create = lambda t: requests.post(URL, headers=HEADERS, json=[{"Title": t}]) update = lambda i, t: requests.patch(URL, headers=HEADERS, json=[{"Id": i, "Title": t}]) delete = lambda i: requests.delete(URL, headers=HEADERS, json=[{"Id": i}]) t = st.text_input("New Title") if st.button("&#10133; Create"): create(t); st.rerun() for _, r in fetch().iterrows(): c1, c2 = st.columns([6, 1]) nt = c1.text_input(str(r["Id"]), r["Title"]) if c2.button("&#128190;", key=f"s{r['Id']}"): update(r["Id"], nt); st.rerun() if c2.button("&#128465;&#65039;", key=f"d{r['Id']}"): delete(r["Id"]); st.rerun()

I'm as surprised as anyone to be suggesting Streamlit, but man, I'm shocked and excited about how well how well Streamlit code can be generated by even the little LLMs you can run on a laptop. I just used a bunch of models today to generate a pile of complete Streamlit apps, first shot. I have a sense it has something to do with how UI and logic code get mixed together in Streamlit - and Streamlit code really does end up being a *lot smaller and easier to grok, by huge a long shot, compared to most other UI options, so you don't end up with 4000 lines of Flask/HTML/CS/JS code that you've never completely internalized, when you have an AI generate lines. There's just nothing else which has been as successful, in many dozens of hours of applied testing, using AIs to develop working UI + backend code (most others fail utterly miserably in comparison). All the AIs do really well with Flask/HTML/etc also, but the resulting code bases are 20x as big, and much harder to use, integrate, and maintain. One of the cool things is that Streamlit pairs perfectly with SQLAlchemy and plain SQL, so you can use those tools along with any database you set up with NocoDB, instead of being forced to use the NocoDB API. That combo opens up a lot of doors for client involvement, without getting in the way of any other preferred development workflows, so the no-code side of projects can get done outrageously quickly and easily by end-users (and developers) - and of course you can mix in your ___ language tools wherever they're useful. Start projects with full code and connect NocoDB for non-technical users, or vice-versa, or do both at the same time :) I did a Baserow training last night with the admin employees of one of my clients who's driving full force into building all their in-house software with no-code. It's staggering to me how quickly office staff with just basic technical competence are able to start using that Baserow database interface (basically the same one as in NocoDB). I'm stunned at how much actual work they're getting done after just a little introduction - and there are so many additional benefits, like group communications within Baserow, which are likely to replace other products this client is currently using. Cool cool stuff.

If Streamlit's rerun-the-entire-script methodology gives you the willies, the best alternative is Panel: https://panel.holoviz.org It's got an approach to interactivity more like React, but built on their own pure JS reactive library called Param (i.e., instead of using React, Vue, or any other JS frameworks like jQuery, under the hood). Panel tends to be more verbose than Streamlit, but GPT works better with it than other lighter weight Python web UI alternatives I've tried. Here's a demo, and the code for this example is at https://com-pute.com/nick/forum_panel_auth_gpt2.py http://cmpt1.com:5006 Panel is a bit more complex than Streamlit, but also includes many mature plugins like Tabulator (a great JS datagrid library that I've used a few times in Anvil and in plain JS). The key is to pick one or two integrated web UI systems that you understand and like, and importantly, which GPT can help you build with. I've found that LLMs aren't nearly as skilled with Taipy, Nicegui, Reflex, Solara, Flet, H2OWave, Reahl, Shiny, Voila, PyWebIO, FastUI, Gramex, Flexx, JustPy, or Remi (oh my God, I've tried so many), as they are with Streamlit and Panel. LLMs work great with Anvil, but Anvil uses a visual builder, so GPT doesn't need to get involved as much with UI layout code when you use it. The difference between the list above and alternatives like Flask, Django, Jam.py, FastAPI, Pyramid, Brython and other Python frameworks is that they all require building UIs with HTML/CSS/JS/jQuery/Bootstrap/React/Vue/HTMX/etcetc. That not only requires learning HTML/CSS/JS/jQuery/Bootstrap/React/Vue/HTMX/etcetc, but the architecture required to integrate those systems, including routing, templating, AJAX, JSON serialization, etc., typically ends up involving *far more complexity. So not only do those solutions typically involve orders of magnitude more code, even though LLMs can do a great job building UIs with those tools, what you're left with is a massive quagmire of a code base that's much more difficult to reason through, update, maintain, etc. Jam.py eliminates a huge portion of that mess, and also includes the no-code schema CRUD UI builder pieces, but none of the LLMs are proficient with it, so you still need to at least be proficient with HTML/CSS/JS/jQuery/Bootstrap, and understand the jam.py ORM and its other unique framework conventions, to be able to get LLMs to generate useful code for it. Keep in mind that there's no reason to have to use Python for any piece of any application. Use an ORM and UI library in any language you want, and do as much of your logic and integrations using the ecosystem libraries in that language, then just add in Python or any other language whenever you need a particular tool from that ecosystem, to more effectively enable some end goal. You can do as much work as possible with ___lang, and only mix in Python whenever it enables a particular end-goal that ___lang doesn't handle well. The killer feature of Python is its massive ecosystem of libraries and existing integrations - especially its deep integration with CUDA and other core AI development frameworks. But as long as any language tool you use can connect to the same database and communicate via REST APIs (or any other mechanism like GraphQL), you can integrate them all without restrictions. That's true of all the no-code tools too. I'm doing all this recent work to evaluate every possible productivity-enhancing tool which can be used to enable clients to use no-code, and to most easily extend and integrate those no-code tools with everything else, because those capabilities together fundamentally change how the entire development lifecycle of projects can play out, and dramatically reduce development effort, frustration, limitations, etc., and helps to make clients and everyone involved happier and more able to work together effectively. All the parts are still just as interchangeable from the developer's point of view, but when clients can dive right in and work immediately with their own database and other pieces of the development foundations, the entire process of gathering requirements, building/testing/revising prototypes, getting UX feedback, etc. all changes. That approach/methodology is true for every piece of a development stack - if anyone involved in a project can take part in building UI, for example, that helps leverage everyone's effort more to actually begin implementing and clarifying requirements - even if any part of some contributed effort just helps generate prototypes which are eventually refactored using stronger production quality tools, that effort can help tremendously to move a project forward. Really building things is always better than drawing on the back of a napkin. If a UI prototype is created with Streamlit and Python logic code, and that UI needs to get migrated to Panel, Anvil or Flask+HMTL, for example, it's no longer nearly the trouble it used to be. You can get most of that accomplished just by uploading existing code to your favorite LLM, and asking it to convert the code to a different framework (as long as your LLM is really capable with each of the frameworks involved). That's a big reason I like Streamlit right now. Keep things simple and build with a framework that's the lowest code and complexity possible, and well understood by LLMs, then migrate to other tools only if/when production demands require heavier tooling. Refactoring is very easy with LLMs, and getting schema, logic, connectivity and some form of working UI implemented, especially using tools all in a single ecosystem (RDBMS, Python, web UI, etc.), helps to get end goals actually accomplished more quickly with as little pain, error, effort, and frustration as possible. Everyone I work with has different levels of technical capability among their human resources, and I'm trying to put together tools which each person can work with more effectively, without limiting serious professional development capability or getting tied into any single technology stack. The few no-code tools I've settled on (NocoDB, Baserow, NocoBase, N8N, Jam.py) and the few integrated Python UI tools (Streamlit, Panel, Anvil, Flask), as well as SQLAlchemy, SQLPage, and anything else that can help anyone involved take part more efficiently (every LLM of course), helps work get done better and leaves more time, energy, and money for fun, family, and life :)

I think NocoDB and Streamlit (or try Panel if you don't like Streamlit), is as good a set of tools to enable those possibilities, as anything I've ever seen and tried, and I've used and evaluated so *many. I still love Anvil and trust for my own work.

This is a top-level comparison between Streamlit and Panel, by the creators of Panel: https://panel.holoviz.org/explanation/comparisons/compare_streamlit.html And a great little migration guide: https://panel.holoviz.org/how_to/streamlit_migration/index.html

Use SQLPage, Jam.py, Anvil, or any SQL, Python, REST API, or web UI toolkit, for any piece you want to take part in building, and you're never gonna say 'crap we have to scrap that work'. UIs get converted pretty freakin easily with AI, so work with whatever tools you like for that, especially if the important pieces such as Python (or other language) functions which accomplish all the unique innovative work, can just get lifted and placed into another framework/IT environment, SQL schemas and REST APIs can be picked up immediately with alternate tools, etc. The more end-users and other stakeholders can take part in building any piece of a project, using those standards (SQL, REST API, web UI, popular language ecosystem), the less pressure is on any core development team to do everything/anything, and the happier everyone is at the end of a project, because everyone gets more say about how things work, and they get actual involvement assembling their own working parts, so the end result work exactly as desired. As long as any tooling integrates neatly with every piece of an organization's tech stack, there are no worries. All these dozens of tools I'm investigating orchestrate beautifully, leveraging the key connectivity standards above - and you can generally define a clear limit to their purpose, for a large set of potential users, including developers with any varied background. And all these tools can all be made orders of magnitude more productive with the help of generative AI. The important part is that if a tool can't live up to it's purpose in the end, all the work done with it doesn't ever get scrapped completely. My long-time ambition has been to make it possible for every layer of management, IT personnel, analytics, stakeholders of any sort, end-users ... and now AI agents employed by any of those people... to play as much a role as possible in accomplishing actual solid progress toward satisfying requirements (to actually tick off line items as 'done', or at very least working as prototypes built on scalable/malleable standards), and to eliminate endless agile revision cycles as much as possible, within the constraints of whatever pieces of OS, RDBMS, server and client architecture are required for everyone to get projects completed, as easily as conceivably possible. I see all these tools achieving a role in productivity improvements which are greater than what's possible in the near future with AI alone, by leveraging ground-breaking insights into human nature and how projects actually get completed more effectively - all playing by the rules so teams don't get painted into any corners, and so AI can help with every step. Remember, I thought it was astounding that I could build a typical generic app, with all the normal parts (database, auth, user management, UI, navigation, logic, etc.) in a 4 hour case study using only AI to write every line of code from the ground up (2 years before the term 'vibe coding' was even a thing) - but then building that same application in Anvil took me 15 minutes, without any help from AI. Consider that even a modest project like the Diabetes Registry took hundreds of hours to integrate with existing infrastructure, and then extrapolate how long that would take with generative AI alone (and no AI yet has the agency to even do all the work involved) - we're still quite a ways away from that reality, and who knows how long it will take. My goal in the meantime is to get projects like that to take something in the order of a few dozen hours, with 10% or less of the total work required, and much better satisfaction for everyone involved. All that is true, plus I'm having a blast working with all these super cool tech toys :)

Man, think what the ANTHC development experience would have been like if we hadn't needed to write any code to build schema, to write any code to query, filter or sort any linked data in views, to build any UI, data grids, forms or navigation, or to connect with the MSSQL database and LDAP infrastructure, to build auth features, logging features, etc. - and imagine if any user could further multi-filter, multi-sort, and group data from any schema or view we created, at will, any time, very easily, without needing our help at all - and imagine if they could have uploaded any Excel or CSV file, JSON, etc., and have a database schema created immediately from it, which could be instantly formed into a filtered/sorted view - and imagine any end-user view could be downloaded as a CSV or Excel file - and imagine if every view we created had an instant API built to connect it with other tools, etc. And imagine if we'd had AI to write thousands of lines of code from the very beginning, to evaluate, suggest, and implement library choices, and to help orchestrate work on the unique innovative pieces... That's a dramatically different situation than what was possible a few years ago. The crazy thing is, right now everyone seems to be moving away from no-code, exactly when the best no-code tools ever are being released, because everyone thinks that AI agents are just going to do it all this year. AI agents and robots will eventually do everything humans do, better than humans do, but that's not here yet, and I think the best no-code tools will only improve AI productivity and humans' ability to leverage AI long into the future, because there are so many potential problems related to not being able to understand how AI creations work, and to maintain control of anything we don't fully understand. Not having to do all the work of using tools, and not understanding how those tools work, is 2 very different situations. You don't have to be a whiz with Streamlit to understand what an LLM has created with it - but you better completely understand every line that's in a code base, before it gets put into production. If you can eliminate code complexity, fatigue, errors, testing, etc., by 90% and increase comprehension by 900%, you can leverage generative AI dramatically more effectively.

I've gone back to re-evaluate Budibase, and now expect it to be one of my first choice no-code tools. I had abandoned it in the past when they started adding paid features to the open-source release. But it's wrong to avoid it for that reason. As is turns out, of all the open-source no-code tools, Budibase actually may have the strongest and most complete set of core OSS features, despite its move to commercialize some functionality. First off, Budibase has an absolutely killer built-in web site/app builder, with good looking, smart, and flexible default layout/navigation options, which just work the way you'd expect for the overwhelming majority of cases, without any fiddling or extra effort. Basic common page designs, menus, navigation, default styling, etc. all look professional and are intelligently configurable without fuss. Baserow and NocoBase both have built-in application/site builders which integrate with their data sources, but Budibase's site building system enables far more capability and finer control than Baserow's, with many more built-in components such as integrated maps, QR/code scanning and display widgets, signature capture, charts, more flexible containers, multiple varied repeating elements and flex layout options, etc. - all very simple and fast to use. Also, it has the ability to create public web pages/sites that don't require login, which can't be accomplished with NocoBase. As it stands, I really prefer Budibase over tools like Appsmith and Tooljet. It's easier to use, can accomplish more kinds of work, and the integrations are more natural, from my perspective. Importantly, the Budibase app builder goes much further in one particular way: by enabling the import of open-source free add-on components, datasources, and automation *plugins - and the community has created a huge pile of those plugins, which are all totally free. The open-source version of Budibase enables the inclusion of 10 plugins per instance, which is a healthy limit for all but very large projects in big organizations that may have numerous complex integrated apps all running on a single multi-tenant installation. Budibase plugins enable every imaginable functionality, such as audio and video recording (all integrated with the Budibase database system), YouTube, Spotify, Google drive, Apple music, and other 3rd party service embeddings, PDF viewing, any conceivable UI and data management controls (calendars, kanbans, geolocation tools, JSON editors, custom datagrids, treeviews, navigation and file management systems, etc.). There's a curated list of some plugins vetted by Budibase, here: https://github.com/Budibase/plugins . Those plugins can be added to a project directly in the builder, without having to do any command line work (and can even conveniently be pulled directly from github repository URLs). And of course developers can create custom plugins, whenever needed, to support any project. This feature enables endless extensibility in Budibase, in a way that can by so easily implemented by end-users, directly in the Budibase interface, without any technical challenges, command-line server work, or code. Plugins simply appear as additional drag-and-drop components that work like every other native component in Budibase. That adds a ridiculous level of power and UI extensibility, for the level of simplicity and ease of use baked into the no-code system. Honestly, there are already more existing plugins to cover every possible need, than I expect to ever have to use. That whole built-in system just ensures the framework is outstandingly future proof, purely via built-in extensibility - and also makes it one heck of a powerhouse UI development tool which can compete with most pure code tools, not just in terms of productivity, but also overall capability. Budibase also enables super-simple multi-tenant project management, backup, and migration features, much like Baserow. Within a minute, I was able to move entire projects, with and without all the data in each project, from one open-source server to another, all with single-click upload and download. Man, that potentially saves so many hours of work when migrating from development to production environments, when switching server hosts, when duplicating projects, etc. It coundn't be simpler, it's just an instant process. NocoBase, in contrast, does require command line work to accomplish all those sorts of goals. Budibase also has a great undo-redo system in the app builder which is sorely missing entirely in both the Baserow and Nocobase builders (and I know how significantly helpful that can be, after using the comparable feature many times in Anvil project workflows). One huge advantage of Budibase is that it connects to more RDBMSs than both Baserow and Nocobase: MSSQL, Postgres, MySQL/MariaDB, Oracle, and even MongoDB, as well as a pile of other popular commercial data sources like Google Sheets, Firebase, Elastisearch, DynamoDB, S3, etc., all completely for free in the open source version. It automatically imports and syncs existing database schemas and data, and additionally has a built-in database option made on top of Couchdb, which comes with a full built-in management system separate from the Budibase user UI, for full IT server management. You can mix and match as many separate data sources as you want in any Budibase project, just like you can in NocoDB. All those features together, are huge. One little niggle with Budibase is that is does not support connections to SQLite. It also doesn't support every automated schema import feature that NocoDB provies (for example, deeply linked views require manual foreign key assignment), but a perfect solution is to simply insert NocoDB's admin interface directly into a Budibase page (with or without auth), if those features are ever necessary. Budibase *can directly import the Curl documentation examples created by NocoDB, for any API connection to any RDBMS supported by NocoDB, so it takes literally a few seconds to set up a connection in Budibase to NocoDB's REST API back end for any database (including SQLite). So I did just that - I connected Budibase to NocoDB's automated REST API for an SQLite database, and integrated that synched data source into a Budibase app, in less than a minute. I also connected Budibase and NocoDB to the same MSSQL back end, and performed round-trip edits to the schema and the data in both systems. It's dead-simple to integrate the 2 systems that way, along with any other SQL based tools. There's no work at all involved in performing any database schema migrations using any of these no-code tools - it's all entirely point and click immediate. Budibase can also directly use the iframe code generated by NocoDB for any admin interface or view, so integrating those is also immediate. That's the benefit which comes from having all these systems built on RDBMS and other common standards - and even the no-SQL DB options available in Budibase all just work together in exactly the same way - they're all available in the same unified interface, entirely without writing a single line of code or doing any hard work. That enables an absolutely stunning suite of connectivity within a single dead-simple-to-use tool. It should be pointed out that Budibase also has a spreadsheet-like database interface, very similar to the super-slick design in Baserow and NocoDB, which is much easier for non-technical users to grasp than the admin sorts of interfaces found in systems like NocoBase, Saltcorn, and others. Baserow's implementation is just the coolest, but Budibase is nearly identical functionally, and far and away better than most of the wizard and form-based interfaces found in other tools. Budibase includes a 'data transformation' feature in its no-code REST API connector, to easily get the exact data you intend, from API calls. You can peek and poke through layers of JSON values, all very easily. Budibase also has a great workflow system, which enables the implementation of formulas, logic, integrations, web hooks, etc., all without code, and easily pulls values from any integrated data source, to be used in logical evaluations and computations. That system also enables freeform Javascript to be included, and offers a commercial add-on feature to build code with generative AI, directly in the interface. You shouldn't need any other third party code to accomplish a wide variety of typical computing tasks, which go well beyond basic CRUD interactions. Budibase's authentication system is uniquely flexible, with a cascading visual drag-and-drop workflow-like interface that enables roles to share, inherit, and build upon the access features of other roles. You get 20 free users in the open source version, and unlimited public access to features that don't require authorization, which is better than the planned limitations for future Baserow builder releases (although you can continue to use the current mature version of Baserow which enables *unlimited users in the application builder, if you don't need future updates...). You can of course choose to use logins as 'roles' in Budibase (i.e., accounting@company.com, warehouse1@company.com, warehouse2@company.com, billing@company.com, etc.), or actually assign specific user accounts to up to 20 roles, so there's lots of capability to manage auth access in the totally free open-source version of Budibase. You can also integrate other tools such as NocoDB for unlimited auth access to CRUD functionality, and build any extended features with any other programming tools, to enable unlimited auth features of any sort. This typically just means building your own tables of users, hashed passwords, and roles, along with manual routing logic - never really a tremendous task - I've had to do that from scratch for a bunch of projects using other full code tools. For most businesses with more than 20 employees, if the goal is to enable full no-code in-house development by non-technical end-users, a $5/month cost for users is trivial. My current Baserow clients have been thrilled with Baserow's commercial offering fees, which are comparable. And for smaller apps in smaller organizations, a reasonable number of full-featured users is totally free. This strikes me as a sensible way for Budibase to commercialize its work and stay in business building great tools, without stopping small organizations from implementing Budibase without ever spending a penny. I expect to use Budibase as a project management and core development system which rivals those of Anvil and Baserow, along with UI and app building features that provide a super practical and capable mix of default good looks and functionality, many more layout and component features than Baserow, and deep extensibility. It's hard to look away from all those pre-built components and plugins, all so easy to use, without any code, and which connect to CRUD functionalities on so many DBs. For any functionality which can't get completed with the Budibase workflow logic tools, I'll just connect to simple Flask endpoints. That's how the separation of concerns should be handled for most projects - accomplish every routine piece/requirement in a system using the simplest to use tools possible, and enable integrations with more deeply powerful and complex tools/ecosystems, in the simplest possible way, without requiring any significant on-boarding effort for development team members. I'll likely continue to build database schema and queries with SQLAlchemy/Python, using any framework, ORM, UI or other tool systems which make sense for a project environment: Flask, Anvil, Django, Jam.py, etc., together with any other tools that are appropriate for any user and management groups involved in any project: Streamlit, Panel, SQLPage, pure HTML/CSS/JS/Bootstrap/jQuery/React/Vue, pure SQL, etc. - and any tools in those ecosystems, and/or any other programming language systems which any developers, analysts, designers, etc. feel most comfortable working with. All those pieces are perfectly naturally integrated in with all these no-code tools that I'm settling on. The key for me is having tools available which remove barriers that keep anyone involved in a project from completing any piece of tedious or time consuming work, which always ends up being the case when projects are built entirely with traditional full-code tools - and instead enable end-users and other stakeholders to take part in development to any degree, at any level, with any chosen no-code or full-code system, in any IT environment, with any OS, database, within any deeply entrenched security and compliance requirements, etc., and which enable generative AI to boost productivity and increase capability many-fold times more, every step along the life-cycle of a project. I expect that a go-to combination for me to build extentions to no-code projects will most likely often start with Anvil, and include NocoDB + Anvil/Flask(HTML/CSS/JS/Bootstrap/jQuery/React/Vue) + SQLAlchemy/SQL, for most situations when I want to enable no-code capabilities for end-users and others, without any development limitations or commercial fees. That's a very simple to use and lightweight stack without any limitations or commercial costs required. I expect that Budibase will be a go-to tool for teams that need to build projects with even more no-code capabilities, unlimited connectively to other tools, and a ridiculous number of professional quality built-in extensibility features, all without code. It's an ideal middle of the road balance of free no-code capabilities, with some great commercial add-on features, an absolutely killer UI builder, and the full connectivity that's needed to integrate with any other existing ecosystem, including every tool I mentioned above. I'm most interested at this point in getting Budibase implemented on some big production projects, to learn about any potential shortcomings/challenges. It's hard to imagine it won't be tremendously useful in many cases, even just as a basic UI, CRUD, database, and workspace manager, for many projects where I'd previously rely on Anvil as the core framework. I'm *so intrigued to see how non-technical users like it... Baserow will be a go-to for teams that have no issue paying for special no-code features such as group communications within the development and user interfaces, the absolute simplest possible UI and admin interfaces, specific HIPAA compliance out of the box (just host with a HIPAA compliant provider like Atlantic.net, or with an in-house IT team that manages security, monitoring, etc.), and for projects which are likely to be satisfied with only Postgres RDBMS for the entire life-cycle. NocoBase is still solidly in the mix for developing in-house apps (but not public facing web sites), when the right databases are required, and when the right mix of end-users/stakeholders are expected to build solutions. It's got absolutely killer unlimited fine grained auth, some really professional application UI and layout features, and multi-tenant app handling, plus it's a lightweight install compared to Budibase and Baserow (those both take up 1-2Gigs of serve RAM), but still requires a lot more RAM and resources than NocoDB or almost any pure code tool. I expect that the combination of Budibase and NocoDB, along with other totally free open-source no-code tools may end up trumping the total number of features in Baserow - at the expense of a bit more initial installation, and some potential added complexity initially integrating tools, ascertaining security and compliance requirements, and training users to use tools appropriate for their specific needs. Of course all that is required with *any other software development tooling, and any code tools involve orders of magnitude more complexity. Toss in Flask, Panel, Streamlit, and Jam.py as simple full-stack options for UIs connected to the Python ecosystem, and you've potentially got a full range of no-code, low-code and full-code tools which is more productive, malleable, and able to be used together by both technical and non-technical users, than Anvil or any other single framework. Along with Anvil, I've gotten to trust Flask for a huge number of projects. Generative AI dramatically improves your level of productivity when using Flask, so it's verbosity is no longer a stopper - and in many cases using generative AI is now more productive with Flask/HTML/CSS/JS/Bootstrap/jQuery/React/Vue, than it is with virtually any other systems. Alternative solutions to Flask, such as FastAPI, Bottle, and a few dozen other options can be perfect drop-in replacements, for projects which require Micropython, or in virtually any other environment. However you cut it, the stable of no-code tools which I've been lucky enough to evaluate and put to use during the past few months will dramatically improve productivity and the bandwidth which I have available to accomplish more goals and projects simultaneouly, more easily and effectively, with a tremendous reduction in effort, time, discomfort, tedium and troubles - and those tools will continue to pave the way for generative AI to complete more work effortlessly. This has been some of the most productive and satisfying learning I've done in 30+ years working with software development and technology tools in general. I'm astounded at how quickly and how much work non-technical users have been able to accomplish, immediately and with only a basic introduction and some ongoing guidance and training as needed. It's all very exciting and so rewarding to get these tools working!

This is a great Streamlit tutorial which covers all the basics, plus the most common session_state management issues: https://www.youtube.com/watch?v=o8p7uQCGD0U I hate the way they handle state in Streamlit, but it's undeniably productive. With Python, it's inevitable to eventually end up involving Flask, FastAPI and other similar alternatives in projects, because they are just so entrenched, flexible, versatile and performant. And using Flask just means handling UI with any traditional HTML, CSS, JS, Bootstrap, jQuery, React, Vue, etc. tools you like. I'm putting together a set of tutorials and videos to work up to everything in the app below. It covers everything from basic responsive layout, navigation and controls with HTML/CSS/JS/Bootstrap, datagrids with Datatable, inline editing in the grid with jQuery, database with SQLAlchemy, user management with Flask-Login, mail with Flask-Mail, CRUD database admin panel with Flask-Admin: http://xqx1.com:5005 That entire thing is a total of 463 lines - totally learnable. Creating a new account, running the lost password routine, and all other features are live. You can login as admin to see the default CRUD admin panel: email: admin@example.com password: admin

The IP address for that forum example is: http://154.38.182.180:5005

Budibase definitely has a long learning curve, which tracks right along with it's deep capabilities. Budibase's learning curve is longer even than NocoBase, especially when it comes to the application builder. Of course it's still easier to use than pure code, but there are a lot of details to understand and learn about - enough to frustrate and confuse users who have absolutely no technical background. After all these few hundred hours of evaluating no-code systems, Baserow is still the king when it comes to simplicity for end-user stakeholders to take part with. It's hard for users to make mistakes in Baserow, even when performing messy operations like changing data types in schema. Everything in its interface is just utterly intuitive and instantly accessible/understandable. It's that extraordinary simplicity which attracted me to the whole new world of recent no-code tools. Baserow is moving fast to add features such as automation (something which Budibase really excels at!), and they've already enabled freeform JS in their app builder. I see that syncing more data sources beyond Postgres and the few others they've already integrated (Github, Jira, etc.) is on their roadmap for the immediate future. When they get those milestones completed, especially the ability to sync other RDBMSs, it's going to be hard for me to recommend starting non-technical end-users with any other system. And of course for no-code automations in Baserow, you can already use webhooks to connect with n8n, to complete an endless variety of tasks, all with no-code. I think the best alternative to Baserow is NocoDB. It's got the same basic immediately intuitive database UI as Baserow, and it connects with more RDBMSs. It also provides unlimited auth and more view features for free, and it's light weight compared to any other no-code system (only jam.py is lighter, but jam.py is a more-code system) . NocoDB just doesn't provide any application building features. I think that's actually a practical cutoff for no-code capability - enable non-technical users to build their database schema, provide auth, perform all the fundamental CRUD, filter, sort, and view capabilities - in a way that's dead simple and utterly, instantly intuitive for in-house end-users, admin, employees and other stakeholders. Provide various levels of account access to the no-code admin interface, as well as sharable private and public views and configurable form interfaces with optional password protection, etc. Enable an automatically generated REST API to provide access to the database, from any automation system and/or programming language, and enable webhooks which can call out to 3rd party APIs for any conditional change to the database, scheduled interactions, etc. That provides a fantastic base system to work with in-house data, without requiring bespoke 'application' interfaces (the interface of the no-code tooling *is the application interface for in-house end-users), and it provides a rock solid foundation to build applications on, using virtually any 3rd party tooling/programming language - without getting in the way of any traditional SQL tools - it integrates perfectly and interchangeably, right along with those tools. I'll use Anvil and Flask most often to build bespoke application features for any of these no-code backend tools, but tools like Streamlit and SQLPage integrate beautifully, for users with some particular Python/SQL experience, for example - but *any other language and tool choice(s), in any ecosystem, work just as well. The key is to enable end-users to take part in building the foundational pieces of their schema and data management requirements with no-code. That's what entirely changes the development process, enables more stakeholders to actually accomplish application building goals, eliminates debugging and testing work, simplifies and speeds up the establishment of requirements (as well as a massive portion of the communication, agile prototyping and evaluation steps/loops), and shifts the scope of work for developers so that end-users can get many pieces completed on their own time, for their own needs and purposes - and ultimately derail development work with unexpected/unanticipated new/branching requirements *much less often along the lifecycle of an application.

The key to successfully achieving all those goals, to improve the software development life-cycle and workflow for developers, is the simplicity of the no-code interface, for end-users. If non-technical users have trouble using the no-code system you implement, they can cause more problems than they fix. Baserow and NocoDB satisfy that requirement best.

When I read back this one quote I wrote above about no-code: 'I think that's actually a practical cutoff for no-code capability: enable non-technical users to build their database schema, to provide auth, to perform all the fundamental CRUD, filter, sort, and view capabilities - in a way that's dead simple and utterly, instantly intuitive for in-house end-users, admin, employees and other stakeholders. Provide various levels of account access to the no-code admin interface, as well as sharable private and public views and configurable form interfaces with optional password protection, etc.' That's all entirely possible with Jam.py, plus Jam.py includes code editing/IDE features directly in its admin interface, so you never need to open an SSH command line to build application features. It also provides full audit trail logging, soft delete, and other very useful features out of the box. This is why Jam.py was my gateway drug to no-code. Jam.py is also entirely white-labeled and 100% open source through-and-through, without any commericial offerings, options, or branding of any sort. It's purely a profession software development tool, and not in any way a commercial no-code system tied to any SAAS offering of any sort. What's missing in Jam.py is automatically generated REST API, webhooks, and any form of no-code application UI building features beyond CRUD forms and datagrids/tables. This makes tools like NocoDB easier to integrate with any other automation system and other programming tools. I've also noted that NocoDB can import the entire schema of a complete database, whereas Jam.py can only import a single table at a time from a single database, and without as many automatic relation handling features. NocoDB automatically imports and displays existing foreign key values of any depth, for example (no other no-code development tool I've seen handles deeply nested relations as gracefully - NocoDB works as well as tools like DBeaver and HeidiSQL in that regard). NocoDB can also include connections to many databases simultaneously in a single workspace, and provides more configurable options for data views: forms with more no-code options and logic, galleries, calendars, kanbans, and filters/sorts/groups are easier to use than in Jam.py. Jam.py is geared more towards improving developer productivity on smaller projects with a single data source, and it's specifically perfect for anyone with prior experience in Python and SQL on the back end, and HTML/CSS/JS/Bootstrap/jQuery on the front end. It provides a no-code schema interface which non-technical users can absolutely learn to use quickly - on par with that of NocoBase, for example (more of an admin wizard-like interface), as opposed to the super slick spreadsheed-like UIs found in Baserow and NocoDB, which include every sort of intuitive point-and-click, drag-and-drop functionality that non-technical users can immediately see, put hands on, and begin working with, using formula columns, copy-paste column/row data interactions, etc., like in Excel. Those are the sorts of UI capabilities which make it possible to involve non-technical end-users to take part in the software development process without causing more problems than they fix. Jam.py is by far the lightest weight Python/web UI framework which includes useful no-code capabilities, but it's also not multitenant, and that can end up ultimately playing a big part in increasing RAM and other resource usage, over the long term on a single server. Spinning up many multiple instances of Jam.py in separate Python environments also means more time spent performing intstallation/maintenance work at the server command line. NocoDB's use of resources is pretty darn trivial (a few dozen MB RAM, for example) - so low that you could run dozens of multitenant instances, even on servers with the most minimal resources you'd ever see used for any production purpose (any sort of commercially hosted VPS for $50/year, for example). So I don't think that's ever likely to be a stopper for NocoDB. The resource requirements for big tools like Baserow and Budibase are much more significant (2GB-ish RAM, for example (including their embedded RDBMSs)), but their multitenant nature makes it unlikely you'd ever need to install more than 1 instance on a server, and even huge installs like that typically leave more than enough resources available to install and run all the other tools which are expected to be part of most project lifecycles, even on tiny VPS offerings. If you're going to install many ecosystem tools on one VPS, then you can always end up running out of resources - for example, install Baserow plus several anvil-app-server instances, an Rshiny server, n8n, and Node/NPM tools, along with several RDBMSs, and you're likely to grind a small $50/year VPS from Contabo to a halt. But situations like that aren't likely to occur, especially since the bigger no-code tools eliminate the need for so many other additional tools. Chosing to go with a huge no-code solution is a choice to make at the beginning of projects which are expected to grow and evolve for years. Installing NocoDB + Flask or Streamlit, plus SQLAlchemy, for example, doesn't even make a dent on the smallest VPSs with less than a GB of RAM. If I had to run an application server directly in some ridiculously small environment like on a phone or on other severely resource limited client/edge devices, then Jam.py may be the only no-code option possible, but for projects like that, I don't imagine I'm likely to have any reason to use no-code at all (probably just something like Flask+SQLAlchemy+HTML/Bootstrap/jQuery on ancient devices, or MicroDot+MicroPyDatabase in MicroPython, for example). Those few options cover every imaginable tiny environment/situation, and huge tools like Baserow and Budibase are perfectly useable in virtually any production environment. I think it's hard to go wrong with NocoDB in almost any situation. It doesn't get in the way of any other tools, it can be added on to existing databases/tools/applications, and it provides *so much potential no-code capability, to help end-users/stakeholders take part in the development process and to manage their own data without any developer involvement, across the entire application lifecycle. That potential end-user involvement is what enables development process to be improved so dramatically, for the development team, and for end-users/stakeholders.

Here are some handy instructions to customize Nocodb so you can include your own logo in views, and so the NocoDB links aren't so apparent on any of the auto-generated public forms and views: ----- TLDR to remove the NocoDB logo in views: This part is optional (list and backup original images): docker exec -it nocodb-mssql sh cp /usr/src/app/node_modules/nc-lib-gui/lib/dist/_nuxt/nocodb.EOS_OGkb.png /usr/src/app/node_modules/nc-lib-gui/lib/dist/_nuxt/nocodb.EOS_OGkb.original.png This is all that's required: wget https://com-pute.com/nick/nocodb.EOS_OGkb.png -O nocodb.EOS_OGkb.png docker cp ./nocodb.EOS_OGkb.png nocodb-mssql:/usr/src/app/node_modules/nc-lib-gui/lib/dist/_nuxt/nocodb.EOS_OGkb.png ----- TLDR to remove the 'Sign up for free' link in views: grep -rl "Sign up for free" /usr/src/app/node_modules/nc-lib-gui/lib/dist/ nano patch_nocodb_signup.sh This is the contents of patch_nocodb_signup.sh: #!/bin/bash # Container name CONTAINER=nocodb-mssql # Backup directory on host BACKUP_DIR=./nocodb-signup-backup mkdir -p "$BACKUP_DIR" # Get list of matching files echo "[INFO] Finding files with 'Sign up for free'..." FILES=$(docker exec $CONTAINER sh -c "grep -rl 'Sign up for free' /usr/src/app/node_modules/nc-lib-gui/lib/dist/") echo "[INFO] Backing up and patching..." for FILE in $FILES; do BASENAME=$(basename "$FILE") HOSTFILE="$BACKUP_DIR/$BASENAME" echo " - Processing: $FILE" # Copy from container to host docker cp "$CONTAINER:$FILE" "$HOSTFILE" # Replace text in host copy sed -i 's/Sign up for free//g' "$HOSTFILE" # Copy back into container docker cp "$HOSTFILE" "$CONTAINER:$FILE" done # Restart the container echo "[INFO] Restarting container..." docker restart $CONTAINER echo "[DONE] All 'Sign up for free' text removed and backups saved in $BACKUP_DIR" chmod +x patch_nocodb_signup.sh docker exec -it nocodb-mssql sh ----- TLDR to remove the 'NocoDB Forms' link in forms: nano patch_nocodb_forms_branding.sh This is the contents of patch_nocodb_forms_branding.sh: #!/bin/bash # Container name CONTAINER=nocodb-mssql # Backup directory BACKUP_DIR=./nocodb-forms-branding-backup mkdir -p "$BACKUP_DIR" # Search string SEARCH_TEXT="NocoDB Forms" echo "[INFO] Finding files containing '$SEARCH_TEXT'..." FILES=$(docker exec $CONTAINER sh -c "grep -rl '$SEARCH_TEXT' /usr/src/app/node_modules/nc-lib-gui/lib/dist/") echo "[INFO] Backing up and patching files..." for FILE in $FILES; do BASENAME=$(basename "$FILE") HOSTFILE="$BACKUP_DIR/$BASENAME" echo " - Processing: $FILE" # Copy from container docker cp "$CONTAINER:$FILE" "$HOSTFILE" # Replace the target string sed -i "s/$SEARCH_TEXT//g" "$HOSTFILE" # Copy back into container docker cp "$HOSTFILE" "$CONTAINER:$FILE" done # Restart container echo "[INFO] Restarting $CONTAINER..." docker restart $CONTAINER echo "[DONE] '$SEARCH_TEXT' removed. Backups in $BACKUP_DIR" chmod +x patch_nocodb_forms_branding.sh ./patch_nocodb_forms_branding.sh -----

So now the views and forms look like this: https://nocodb.cmpt1.com/dashboard/#/nc/view/584442aa-4c82-4407-b25b-72382c084770 https://nocodb.cmpt1.com/dashboard/#/nc/view/63694e96-0746-4a92-ac1a-642e3529a43d https://nocodb.cmpt1.com/dashboard/#/nc/form/434bf629-ffa0-46cf-be1d-798c5fb7493a

I'm going to continue this topic in a separate thread because it's too big for a single page.