[arey_abhishek]

I'm a founder of Appsmith, a well-known open-source low-code platform. We offer an alternative to tools like Outsystems, Retool, and PowerApps. I often meet people who share the skepticism about low-code seen in this post.

It's crucial to understand the advantages of low-code for specific situations, especially in developing internal applications. These tools, often neglected due to limited resources or developer disinterest, can be rapidly and effectively created with low-code solutions. Low-code excels in scenarios where internal teams are overwhelmed and business users face long waits for features. Although it's not a cure-all, low-code is highly effective for certain tasks where speed and ease are key, despite sometimes facing limitations in customization.

Some modern low code tools are also evolving to be closer to web frameworks. Plasmic is one my favourite examples of this.

[knappe]

> Some modern low code tools are also evolving to be closer to web frameworks. Plasmic is one my favourite examples of this.

So this hits on one of my questions/observations. How different is low code to the generators of various web frameworks? I'm thinking things like Rails, Django and the like where a lot of the "low code" appears to be templatized. They sure feel VERY similar.

[m3047]

People have the wrong mindset about all this. The most continuously integrated / continually deployed code process in the world is desktop publishing. You draw. You press print. Something prints.

Contrast to printing per se: You have some text and graphics. You do wire frames. Now you have to decide about the next part of the process: are you going to go with litho or a more traditional layout process? Now you do either cut & paste or cast / etch / burnish plates and / or masks. Now you print, which actually involves doing multiple prints in different colors which all have to line up. (And that's the simplified version, it's a lot more complicated than that.)

Desktop publishing is actually a code development process. A Postscript(r) printer knows a programming language called "postscript" which interfaces to something in the printing engine which is called the "raster image processor". Postscript programs have libraries, and the printer gets transpiled code for the RIP to execute. (Does this sound like your web dev shop?) The location of the RIP has meandered back and forth on the workstation <-> server <-> print engine continuum due to various factors; this looks a whole lot like the compute / display continuum and the endless debate about how smart a display device needs to be.

Now, the color is never quite as good with DTP, mach banding, dithering, blah blah blah. Like I tell my wife, the artist, the only person who knows that's supposed to be insane blue, and that over there is outrageous orange is you. (When she prints cards she secretly does hand touchups with the true pigments which are a mote in her mind's eye.)

For most things on the planet, normal people will settle for desktop publishing's shittiness. What's not shitty about DTP is the democratization. Instead of one person publishing to a million, it's (potentially) one to one.

I wish, I truly do, that all of this mattered for the web but it doesn't. The web is largely free, and at the scale of free everybody gets the same unique experience. On the other hand if I have a $1,000,000 warehouse facility even if there are 100 people working there I want them to have the best experience possible. I'm going to tailor that experience based on job function, where in the facility they operate, what they do. If someone is missing a finger, they should have an interface which takes account of that. $50,000 piece of machinery with one user? Optimize that user to optimize that machine. Welding gloves, or gloves covered in fish guts? Special interface for you too.

A good low code solution comes with OT drivers, speaks to SQL and microservices; produces true and correct (legally speaking) audit / transaction / snapshot logs (because if someone gets poisoned by the product or loses a hand working with the machinery...); has MES (workflow) as a low code function.

[sfn42]

Man I read that whole thing and I have absolutely no idea what you're trying to say

[m3047]

"Low code" is not just literally some software library with a GUI on top. There is a whole CI / CD pipeline which kicks into gear. What does that GUI do, and what does it look like? In some fashion or other it lets you compose the application GUI; it doesn't have to be WYSIWYG like DTP or composing a slide deck, but many are. Although the GUI is ubiquitous, it isn't necessary. What is necessary is the CI / CD and devops pipeline in a box and the extensible ETL plan which allows it to be tied to business logic.

[jsunderland323]

Does seem impassioned though