A second look at "no code" tools (2019)

https://webflow.com/blog/no-code-is-a-lie

by tosh • 5 years ago

139 154 5 years ago

breck6• 5 years ago

What you want is "low code". Or less rhymey but more accurate: "minimal code".

Historically visual programming tools did not create this. In fact they generated very bloated code. So visual programming tools got a bad rap.

But there's no inherent reason why they need to generate bloated code. And if well done they can indeed generate minimal code (and program synthesis advancements will help a lot here).

We worked on this from ~2010 at Nudge and we eventually solved it with the discovery of Tree Notation.

k__• 5 years ago

Why does it have to be visual?

If I can use a library or a framework that saves me from writing thousands of LoC, that's low-code too.

iamacyborg• 5 years ago

Visual inherently opens the product up to non-developers, which is where a lot of the commercial opportunity lies.

breck6• 5 years ago

It doesn’t. I think just often, including in the OP, the term no/low code is used to speak about the visual subset of the problem. I agree with you in that higher level text abstractions are low code as well.

auggierose3• 5 years ago

Discovery of tree notation, are you kidding me?

breck6• 5 years ago

https://giphy.com/gifs/mandy-moore-candy-s5h76W8pSJ5W8

phaemon2• 5 years ago

Probably not. I hadn't heard of Tree Notation before. Do you have a useful comment to make on it?

protomyth• 5 years ago

What you want is "low code". Or less rhymey but more accurate: "minimal code".

Kind of. What I really want is something that can round-trip to a textual representation and is heavily visual with the possibility of adding custom actions. I guess a BizTalk Orchestration built from the start to be a programming tool. I often think in my retirement I am going to take a crack at doing Excel as graph of tables and components.

Huggernaut• 5 years ago

I might have misunderstood your want but perhaps you'd be interested in where we're going with Storyscript? [1]

We're working on a primarily text, multi-modal "low-code" experience.

Or maybe you're suggesting the other way round, that you want primarily visual but with a way to interact with it in a text based format?

1. https://storyscript.com

theamk8• 5 years ago

That Tree Notation? https://treenotation.org/

I don't get it. The descriptions are pretty wild and make little sense to me:

Tree Notation is like a 2-dimensional binary and could be used at the lowest levels of computing.

But in practice, we have:

- Tree Notation, both data structure and a textual data format. A data structure only has one datatype, which is string value + a list of children. A textual format uses significant whitespace both in the beginning of the line and between the values. It seems to really hate punctuation for some reason, there are no quoting mechanisms or even quotes.

- Tree Language, a parser/lexer combo which generates AST in Tree Notation format. It allows embedding Javascript in the generated output.

- A bunch of examples made using the parser above -- there is some plotting tool for web data, HTML generator, and few toy DSLs?

Overall, I don't see anything particularly unusual about it. I see no advantage of Tree Notation data structure compared to usual string/int/list/dict core types most languages have. I see no advantage of Tree Notation textual format compared to others -- while it may be OK for very simple cases, I have a feeling that the lack of quoting and inability to wrap lines would get annoying fast. The Tree Language grammar does not seem very elegant either, it certainly seems harder to read than BNF variants.

breck6• 5 years ago

Your observations about the specifics are fairly good.

The big idea is about dimensionality. All of the TIOBE languages are 1-dimensional. Parsed as a linear sequence of tokens, transformed to an AST, compiled.

I'm claiming that these are chasmically inferior to 2 and 3 dimensional languages. Tree Notation is one very useful implementation of this bigger idea. In Tree Notation the shape of your source code is immutable during parsing. The AST and CST have the same shape. More abstract nodes stack up the z-axis like you would stack legos. Tree programs are isomorphic to geometric trees.

Human brains parse text in parallel, in 2+-dimensions, and rely on geometry for meaning (as opposed to position in a linear sequence). Computers can to. And my bet is that they will https://longbets.org/793/

It looks like a toy, but this will change everything.

Or I could be wrong.

https://giphy.com/gifs/latenightseth-seth-meyers-lnsm-4HnRkH...

bmgxyz• 5 years ago

When I started my last job, I thought I was going to be writing a lot of Python and C. It turned out that the position had a lot more React and TypeScript than I expected, and at first I was annoyed and afraid. I wasn't a frontend developer---or worse, a designer---but I didn't have much of a choice, so I dug in and learned the stack.

At first I resisted every change. What good is VS Code when I have Vim? Why would I learn TypeScript when vanilla JS has "worked" for me for so long? What's a Webpack config?

Once I began using the tools that my coworkers recommended, I started treading water and even swimming with purpose in the ocean of Web UI technology. I still have a lot to learn, but I probably would have kept on avoiding this area if my situation hadn't forced me into it. Letting my guard down and following the trends in my group helped a lot in this case.

The best lessons I learned during that period are that learning can't kill me and using good tools doesn't make you a bad engineer.

j-pb• 5 years ago

I'm glad that you had such a positive experience! After years of web development I'm just burnt out by the tooling.

Layers upon layers, just make debugging so unnecessarily hard. The tooling is brittle and buggy.

I've seen typescript compiler bugs, webpack segfaults, and whatnot. I've started to ban typescript and jsx from all future projects, and it's better, but still a nightmare.

Xevi2• 5 years ago

As a mainly frontend developer, I agree. I've spent more time configuring tooling, than writing code, in this new project I'm starting. I don't want to write plain JS, but the top used frameworks have strayed so far from basic JS that it's getting a bit ridiculous.

Svelte appears to get rid of some of the boilerplate and verbosity stuff you find in other frameworks, though it's still a pretty magic framework. Looking forward to trying out SvelteKit.

jspash• 5 years ago

I’m on the fence but painfully with both feet on the ground. However it wouldn’t take stiff wind to knock me back on to the plain ol JS side.

I’m currently “rewriting” a vue.js app for the sole reason that we’ve just lost a senior dev who was the only one who could stomach the thing. We’ve taken on two juniors in his place and there is absolutely no way they would be able to dig into this thing.

The process has been quite enjoyable and we’re just about at feature parity at 1/10 LOC. And the juniors are quite keen at picking up typescript and lots of other useful things along the way.

Had they just been dumped into the vue pool, things would have turned out much differently.

I await the day a few months from now when they “discover” this new thing called vue and want to rewrite the entire thing!

oraphalous• 5 years ago

Interesting that you're reacting against the Typescript trend...

I'm personally starting to wonder if/when the backlash against Typescript will gain steam.

mikesabbagh• 5 years ago

The thing is, complexity cant be destroyed. You can just move it from one framework to another

wwww4all• 5 years ago

Everyone should google MS Frontpage. And COBOL.

As the saying goes, “What has happened before, will happen again”.

Soon enough, there will be a new scripting language to simplify managing all no code services from the terminal. NoBash.

ehnto3• 5 years ago

SSR for frontend libraries was the queue for the current cycle to me. The description was "...and then some smart people figured out you could render the code on the server first!" So here we are, rendering UI components with server side languages again. But this time, it's Javascript!

One thing I never saw coming was that frontend technology would eventually take backend developers jobs, and that backend developers would be replaced by a mix of frontend devs and human AWS configurators.

cortesoft• 5 years ago

Isn’t this all on the same spectrum as all programming? Every programmer is using someone else’s code at all times. Even if you are writing in assembly, you are still relying on a compiler to turn your written words into machine code.

zabzonk2• 5 years ago

Even if you are writing in assembly, you are still relying on a compiler to turn your written words into machine code.

To nitpick, an assembler.

erikpukinskis• 5 years ago

It's sort of a spectrum yes... (or, really, there are infinite spectrums like the one you are imagining,) But there are also discontinuities on all of those spectrums.

The ergonomics of a declarative API are not continuous with the ergonomics of a procedural one. There's just a gap there which, when you cross it, you lose a bunch of things, and get a bunch of other things for free.

There'a also a huge discontinuity when moving from code to point-n-click, which is what the article is about. Many of the affordances of code cannot be replicated in a GUI, with ANY amount of effort. And vice versa.

jrochkind1• 5 years ago

Sure, you could consider it a spectrum, in terms of abstraction. So this article is focusing on things at one end of the spectrum I guess?

I think though there are some qualitative differences between purely/mostly pictoral/icon/graphical environments and textual programming languages.

yoz-y4• 5 years ago

I spent the first years of my career writing "no code" signal processing platform. It had it's ups and downs. We indeed had a lot of non-coder users and it made prototyping simple to moderately complex pipelines quickly. However relatively soon for anything actually useful we had to write more components, some of which were not really reusable because it's non trivial to hide the complexity. At some point most workflows ended up in a "python script executor", because in the end code is always more expressive.

Also, no version control. Or, in our case since we used XML for output: poor version control. Reading horror stories about Excel also confirm this, it is hard to do correct complex programs in visual environments.

Wowfunhappy5• 5 years ago

Also, no version control.

On Mac, Apple apps and other "Mac-native" programs save revisions automatically in the background. At any point, the user can select "Show Revision History" and scroll through a timeline of changes. I'm not sure if this works with Excel, but it does with iWork/Numbers, and I use it all the time.

Now, Apple's implementation is just a simple timeline—there's no equivalent of version tagging, or git blame. But all of that could be done within a graphical environment similar to Apple's. It wouldn't be as advanced as Git, but I bet it could do what 95% of people actually use Git for.

quietbritishjim• 5 years ago

You can also commit Excel files to a git repo. That lets you get back to old revisions and look at the commit messages. But you're not going to get a diff or git blame, which is what the parent comment really meant.

apcragg• 5 years ago

Going to guess GNURadio based on calling it a Python script executor that outputs xml. If that's true, I'd that it really starts to break down when the desired logic breaks from the "apply sequential steps to a stream of contiguous data" paradigm.

yoz-y4• 5 years ago

It was OpenViBE, but looking at GNURadio it looks fairly similar so I expect limitations would be also quite comparable.

Spivak• 5 years ago

I would have assumed that no-code tools would have actually shined with weird non-linear dataflows since they’re usually all graph based.

Kind of a shame really since having a dependency solver as core part of the language structure sounds really cool.

bmitc2• 5 years ago

Also, no version control. Or, in our case since we used XML for output: poor version control. Reading horror stories about Excel also confirm this, it is hard to do correct complex programs in visual environments.

Just because some visual systems don’t have version control doesn’t mean they can’t exist. It isn’t like text-based diffing just poofed into existence. Someone had to build them, and even then they aren’t all created equal. For example, I use P4Merge to diff and merge from Git instead of using the poor UX of the built-in terminal tools.

I would argue that visual programming languages are much more ready to be diffed and merged than text since they usually already represent a graph.

yoz-y4• 5 years ago

Graph annotations matter a lot for diffing I think. I think this is actually a good space to explore as it is a hard problem, and would require some serious UX research on how to handle this.

I feel that the one-dimensionality of text makes merging and reasoning about diffs simple, because they are easy to represent side by side. To diff something like an image, or a graph, you probably want to see them on top of each other, however that makes it harder to see the whole.

lmm• 5 years ago

That sounds like vaporware to me. I might be interested in adopting a visual programming system that had good version control. But so far they don't actually exist.

theamk8• 5 years ago

The problem is that text is universal, while each visual language is different.

One would need “universal visual language representation” file format if they want the visual languages to become as popular text-based ones are.

ktta2• 5 years ago

I have a similar experience as you. I worked on a Neuroscience/BCI focused signal processing platform, and also came up with the idea of having a "Python script executor". We used YAML though to store the pipelines. Seems like a very recurring problem.

yoz-y4• 5 years ago

Mine was also a BCI processing platform actually (OpenViBE).

enraged_camel• 5 years ago

I run a no-code agency, and my conclusions match yours: no-code tools are great for getting up and running, and for involving less technical people in process development. But sooner or later you'll need to do something that is outside the boundaries of the no-code platform's feature set, at which point extending it becomes a huge mess, because you then are forced to write code and hook it up to the no-code process in very strange and awkward ways.

Like you say, lack of source control is the biggest pain point.

code-scope• 5 years ago

Agree, Remind me of GWT (google web toolkit) - Marketing message sounds very good: Let your Java Developer write java, GWT compile it into Javascript and run it on the webpage.

In reality, it only works for "hello world" with 2 buttons. Anything non-trivial requires developers who are experts in Java, Javascript and GWT compiler/translator which translate JAVA to javascript. Debugging machine generated code was hell.

xmprt• 5 years ago

Difficulty in version control and testing is one of the reasons I don't think I could ever work in a no-code environment. It's an issue that I'm sure many people don't care much about but it's also a big reason I doubt no-code will ever overtake custom code solutions.

treeman79• 5 years ago

15 years ago I had a business try to force a group of us into such a system.

Almost everyone that agreed are still there.

Great way to kill a career.

recursive• 5 years ago

Different people value different things. Some people would seek out that degree of stability.

rajinl• 5 years ago

I worked for a startup that built a no code platform. The experience you had, was the same experience that the majority of our customers had. Its a general problem with low code. We tried to make the software easily extendable so that developers could refactor away the complexity, by easily adding new tools to the design surface. The approach worked quite well for internal projects, but was at odds with the marketing approach to the product, so it was never pushed to clients. Clients were sold a utopia of business analysts dropping some components onto a designer and hey presto. Low code can work, but in the same way as traditional dev, where code should be refactored into components that's are easy to reason about. The problem is that this is hard to sell. There is a very nice balance to be had with combining low code with traditional dev. Its just very hard to find that balance. Its far easier to write good code in a traditional language that in a low code environment. If you add to that the expectations created from low code demos, its mostly a recipe for disaster.

murukesh_s3• 5 years ago

I started building "no code" tools since 2004. I am also the author of codeflow - a not yet open sourced visual programming platform. I wish no code distinguishes between frontend no code(webflow, wix etc), backend no code(codeflow, mulesoft etc) and full stack no code(outflow, mendix etc). First of all this "no code" is being used for decades in fortune 500 companies and many of their major backend services are run on yesteryear no code. In fact it wouldn't be wrong if to state that all big financial companies use no code as part of their major backend stack (its called in different names such as middleware/soa/integration/etl etc), but they are all visual, drag-and-drop backend/business logic builders that would have required complex coding without them.

In my decades of experience there are of course many ups in no code, but as with any paradigm, the downs are highlighted the most and especially when you want to disrupt the text-based programming world that existed for almost a century now.

The major complaints about visual programming environment (backend) are:

1. Code is more expressive for experienced devs

Its true that code is much more expressive than generic graphical programming platforms for writing algorithms.. But how many of us write algorithms on daily basis?. What all of us do is glue various reusable pieces together to build the business logic. And for gluing graphical programming is actually superior - you can discover easily, dependent fields can be expressed easily etc. You need to use code in a properly designed no code system, but it's only 5% of the project. Now coming back to code being more expressive, if you look at algorithmic visual programming platforms designed for expressive coding like DRAKON (https://en.wikipedia.org/wiki/DRAKON), you can see that they are equally good or even better than coding.

2. No or degraded version control experience.

This is true as visual programs are still written to file as xml or json and there is disconnect between committing that vs seeing actual programs as graphs. This is a difficult problem to solve.

3. Incompatible or poor tooling

This is related to above point. Because visual programming tools need to distribute with a custom made IDE, the common tooling and CLI other available for generic text based programs can be lacking.

4. Hitting a wall

This is one of the biggest drawback I have heard from the devs so far. To be honest which programming platform have not made you hit a wall? In node.js you hit the multi-thread wall, in Java you hit the thread safety/performance(high memory usage) wall. In python you hit the performance wall. How do you solve it? Well in python you solve it using C or ASM libraries - and expose it to python. but you seldom hear a cry from python devs saying they reverted to C because python is slow or lacking.. Cos you learn to use the right tool for the right purpose. Similarly a well designed visual tool will let you do few things extremely well, but like no single programming platform can do everything extremely well, same is with no code or visual tools - for e.g. see DRAKON for writing expressive or algorithmic code.

5. Performance not on par.

Most of visual programs tend to not focus on performance as the priority is different. However this can be solved with compiling the graphs to native code.

When we built Codeflow, we tried to solve 4 and 5 and in our opinion we succeeded to good extend. 2 and 3 requires more effort from the vendor and the community (which is hard because every visual tool is unique). and 1 is possible but require more research.

One way to think about visual programming is this way - imagine a world where graphical vector image editing tools evolved without mouse - i mean you literally have to code everything - right from the pixel you need to edit, the selection - everything. Smart designers (or more of coders) became experts in it and they can produce some great quality images. The tooling is also great as the tool existed for decades with hundreds of libraries and ecosystem surrounding it. Now you come up with a new paradigm where you can use mouse and make it easy for novice designers to use it - there are two benefits you tout - More artists as opposed to coders can now create images - its much more easy to build the images. The coders on the other hand are not in favour of the new tool both subconsciously and consciously. Consciously because the new tool, while better in many aspects are no where near the previous precise tool in expressing the image - and tooling as well (version control, transformations, plugins etc). Subconsciously because somewhere they feel their decades of experience is not relevant anymore.. this is controversial but i have felt it when interacting with senior devs. (Similar to how many don't want to move away from vi/m to vs code for e.g).

BatFastard• 5 years ago

I hate to be the guy who say back in my day... but back in the 90's there was a tool by Borland (anyone remember them?) who created a no-code, low-code tool called Delphi. It was awesome, I used it on a few front end projects and it active data source tools made laying out complex UI's so painless. Of course this was back before Rest APIs and the internet for most part. But it kicked some serious ass.

ant6n2• 5 years ago

I found Jetbeans was somewhat similar, about 15 years later.

jfim• 5 years ago

Jetbrains or netbeans?

ekianjo• 5 years ago

Delphi still exists: https://www.embarcadero.com/products/delphi

tonyarkles• 5 years ago

And https://www.lazarus-ide.org/

adjagu• 5 years ago

Unless I have stumbled across something different it appears as if this is still being developed. I have no idea if what I have linked is even remotely close to what you remember it being.

https://en.wikipedia.org/wiki/Delphi_(software)

https://en.wikipedia.org/wiki/History_of_Delphi_(software)

cosmodisk3• 5 years ago

This was my first exposure to development when I got my first PC. Delphi was amazing for creating User interfaces,as those were the days were 99% of windows apps looked the same ( except Winamp). I even managed to create some useful programs for myself. Shame I dropped it and moved on to 3D modeling for a bit and only returned to development more than a decade later. Who knows what would have happened if I haven't dropped it then..

zabzonk2• 5 years ago

Speaking as a once professional Delphi programmer, I can assure you that Delphi programs have lots of textual code in them. The IDE generates empty functions for event handlers, but you have to write textual code to do the actual handling.

theamk8• 5 years ago

You could theoretically create a database editor without any code. Drop a database connection component, connect a datasource to it (which defines table name), create a "scrollable box" and drop a text edit for every field, drop a few buttons and give them special functions like "save" and "cancel", and you should have an approximation of Microsoft Access form, but compileable to standalone binary.

I don't think anyone ever made projects purely in GUI though, there is always a need for some custom code to be written.

cosmodisk3• 5 years ago

If I recall correctly, it's the same as dropping UI components in Visual Studio and then assigning methods to events.

wormik3• 5 years ago

Delphi was a RAD environment (gui builder and component property editor) with pascal as a business logic impl language

qbasic_forever• 5 years ago

Visual BASIC is even older than Delphi and was the benchmark for low/no code app development. We called them RAD tools, "rapid application development". If you really wanna go back, hypercard on Macintosh was kinda the original that inspired them all (and even inspired the web we have today).

acwan93• 5 years ago

There’s also Clarion, whose platform is intended to generate code for you and you input your own custom programming and business logic if needed for a basic B2B CRUD desktop app.

I guess like history, SW dev trends also rhyme.

sels• 5 years ago

swyx• 5 years ago

oh wow, HN frontpage after 2 years! thanks to whoever submitted, I am the original author, happy to take questions here or via email/twitter (in bio).

DaiPlusPlus2• 5 years ago

Pretty much all of the examples you used of codeless tooling (drag 'n' drop programming, visual state machines and graph editors, database FK diagrams, etc) still still require an undergrad-level CS education - or considerable experience - to understand and use correctly - to that extent they're just time-saving tools that use a graphical UI to hand-wave away tedium in software development (not to denigrate them: time-saving tools and eliminating tedium is important!)- but I argue it's a disservice to everyone to let the uninitiated use these easy-to-use tools for production systems without necessary formal introduction (of course they're still a fantastic didactical aid).

A great example of GUI winning over code or the command-line is a UI to allow people to arbitrarily reorder items: a drag-the-grab-handle UI is a hundred-fold better than manually entering new sort-orders for each item in a command-line array or other UI. This is, at least, the very kinds of things that visual tooling should be used for by everyone from Scratch-lang kids to SV elites.

Another example you gave is of "visual interface editing" - but while you acknowledge the problems that FrontPage and Dreamweaver had decades ago, WYSIWYG is still dead, having retreated back to its origins in print-media design. The old VB6-era "drag controls from the toolbox onto the form surface" is dead because one cannot easily express any kind of non-trivial layout logic using that approach: things like CSS' flexbox, CSS grid (with auto-placement and auto-flow) and @media queries absolutely require one to grok CSS' visual formatting model, which in-turn implies someone will already be more expressive by writing CSS by hand instead of using a mouse to choose from some predefined options (I appreciate XCode's Interface Builder and constraints model is very nice and shows how it can be done right, but explaining how the constraints system works and how it should be used ends up with me having to redo the work of the designer on my team. Ugh.

Another issue with visual-tooling is that unless the tooling vendor happens to control the spec that it's generating code for then the tooling will invariably and inevitably fall-behind and have limited value for more advanced users (e.g. TopStyle) - or if the tooling is meant to abstract-away multiple different backends then the tooling is doomed to support only a common denominator and won't be taken seriously by too many people (e.g. MS Word's Save-for-Web) - we've seen both of these happen with visual tooling for the web, especially with Chrome's rapid frequent releases and the everchanging spec for CSS. Web-design is now even more inaccessible as it was in the late-1990s (and is no-longer the butt of jokes: turns out the CEO's 12 year-old nephew can't apply CSS selector specificity rules - which, I note, is another angle of CSS that visual tooling just can't accommodate).

DaiPlusPlus2• 5 years ago

(Sorry, I forgot to add my point!)

...so my point is, in light of what I said above, how much consideration should we really give to "no code" tools in each category (e.g. database/E-R, drag'n'drop block programming, GUI designers, etc)?

keyle• 5 years ago

So, using Unreal Engine you can literally make an entire 3D game with full next-gen graphics without dropping a line of code.

Now, shipping it to console will most definitely require some C++ and so would Steam I think.

But "Blueprints" are a visual programming language that seriously kicks ass. I believe the end product even compiles down to C++ classes so you don't lose much performance in release mode.

The only thing where it makes no sense is algorithms like A* Path finding, which are far more suited to be written in code than a gezillion nodes linked to each other in a screen of Spaghetti.

ehnto3• 5 years ago

I built a small game with blueprints and it was truly amazing.

I don't use them anymore because I am just so embedded in thinking of things in code, it became tedious to constantly convert code thoughts into blueprints. But I was definitely impressed!

I would probably use it for projects that are mostly art and only a little bit of logic. A walking simulator style game for example. But if I am building out bigger systems, I feel more comfortable in code.

prower• 5 years ago

Just yesterday marked the 1 year anniversary of Dreams, a PS4 entirely visual development tool.

The concept is similar to the UE4's blueprints, but even more visual and with a much more "general" language approach. (it also combines 3D modeling and music creation in the same editor).

While I think code is faster and more direct, it also require a quite specific type of person to "enjoy" it. Most people don't.

Humans are mostly visual creatures, so that's a great way to approach and create a piece of software, without having to learn an entirely alien dictionary and grammar just to thinker around.

boh• 5 years ago

Still not sure what distinguishes "no code" from pretty much every other software. Isn't Excel or Blogger "no code" tools? Why are these newish GUI based applications in this "new" category?

bccdee• 5 years ago

Blogger doesn't use code, but there's no does-use-code blogging equivalent. No-code tools are specifically meant to fit in the role of a programming language in application development, e.g. instead of writing your web application in python, you use a GUI no-code tool to build it.

ralphc2• 5 years ago

I do work in the Salesforce ecosystem, and they really push "citizen developers" and "administrators can write apps with low-code tools" and they push their low-code tool, Flow, as much as they can. I hate the clicky-draggy-droppy so much that I'm learning Racket to make a DSL that will write the XML's that Flow code is when you download it locally.

victor1062• 5 years ago

Why Racket for DSL’s? Why not Groovy or any other tools? Asking because I have a need to develop performant DSL’s and I am not sure where to start.

ralphc2• 5 years ago

Mainly a matter of "all the cool kids are using Racket for DSLs", more seriously the web sites, documentation, YouTube vids, Q&A's etc. say that one of Racket's specialties is writing DSLs and languages. I've used Lisps in the past and I can see how they can be used to turn their internal representation, S-expressions, into XML. In my case it doesn't need to be performant. I'm turning one file format - my language, starting with S-expressions, then a more palatable syntax - into the XML that will be uploaded to Salesforce.

jbm• 5 years ago

I definitely feel that. The number of weird database issues that come up with flows (SOQL limits that non-developers don't think of) is mind numbing.

My take away is you can't mix custom (APEX) code with flows without a lot of effort. At that point, giving people a database and an excel license seems the more honest route.

cosmodisk3• 5 years ago

When I started with Salesforce 6 years ago,I looked at Flow, I thought 'screw this' and went on learning Apex instead. Even. after all these years I barely touched it.

legerdemain• 5 years ago

I've had a lot of frustrations with "APIs are eating the world" over the last two years.

1. "No code" interacts badly with "infrastructure as code." Instead of a client library, you get a web admin console. If you want your configurations to be reproducible, durable, and auditable, you now have to build a client yourself or use a third-party client. Case in point: Snowflake directing users to a buggy third-party Terraform provider built by some random organization that's always several versions behind.

2. "No code" is much harder to test. You have to deploy changes to see them. You don't have the tools to mock them out. There is no local testing. At best, you can have a test environment. But to do end-to-end testing within it, you need to rebuild basically a mirror image of prod, since you can't mock any API boundaries nearly as easily anymore. As a result, a lot of "testing" ends up being done by pushing to prod and trying to roll back when needed.

3. "No code" often means surprise upgrades and feature changes that are out of your control. Some vendors (e.g., Databricks) mercifully display a toast in the GUI prompting you to update. Many just post some release notes somewhere and call it a day.

anotherevan• 5 years ago

Does anybody else remember PowerBuilder?

wormik3• 5 years ago

Yup, and how about Turbo Vision Gui Builder? It was great Gui scaffolder.

thorin• 5 years ago

Sure and Oracle Forms, Designer and APEX, Hypercard, VB GUIs, Django admin forms, Rails default forms etc etc. All code eventually and I saw some horrendous stuff in Oracle forms in the 90s

zed882• 5 years ago

As someone who writes code, I found bubble.io quite promising, until I hit the usual bottlenecks that comes with any no-code platform.

https://bubble.io/

But I can see the lure for masses, driven by the startup subculture, but the truth is that if you can master something like bubble, the transition to actual coding would be seamless and often very liberating.

arkitaip• 5 years ago

I could only stand Bubble for a day or two before it became too restrictive and yet complex for doing very basic stuff. Buffer suffers from the same issues as other no-code solutions but also has a subpar UI.

zed882• 5 years ago

Yeah I agree, there's lots of bloat as well, that's why I said that the transition of bubble tinkerers to actual coding with any high level languages and frameworks would be very liberating. Even a beginner could do a heck lot in something like RoR or Django, without even mastering the respective languages.

toyg5• 5 years ago

My experience with visual programming is that, as the required complexity of the tasks grows even just minimally, it frustrates skilled users without really empowering unskilled ones.

That's because the unskilled stays unskilled for a reason: they can't or won't dedicate the amount of focus necessary to learn a technology to any meaningful degree. They will do the minimum they are (very explicitly) trained to do, and that's it. Basic scripting is not hard; if you cannot (or will not) do it, chances are you cannot (or will not) formalize even slightly-complex tasks in a visual environment either.

And of course, visual environments are a productivity killer for the skilled, who then feel frustrated and eventually drop back into textual modes. This is self-evident.

Sadly, it's a marketing dream, so it keeps popping up in all companies in my niche. "If only we build a no-code graphical UI, accountants will become programmers!" - no they will not. If they were really interested in automating tasks and modelling problems, they would have already learnt VBA, which is very simple - smart accountants do it already. People capable of doing advanced math are capable of programming if they really want. Accountants who won't learn VBA will not meaningfully engage with visual paradigms either, because they are simply not interested in these activities. What really needs to happen is to empower smart accountants to be productive without involving IT. That doesn't need visual programming, it just needs a powerful set of VBA apis unshackled from "enterprise" permission systems.

mightyRodri• 5 years ago

That sounds like the trite old University Professor that says to 4/5ths of their students that didnt get an A: "You lack the passion and maybe you are not made for this".

@murukesh_s post wrote the retourt to that. Pointers and Windows had a substantial impact on shaping the reality we live in now. Putting all the responsibillity on the users shoulders and their "intelligence in math" is way to ego focused IMO.

toyg5• 5 years ago

Read it again. What I wrote is that accountants are smart. They already know how to deal with numbers ad variables, and control flows are trivial to learn in something like VBA. If they don't do it it's because they don't want to, and no amount of forceful simplicity will change that. In fact, visual programming often frustrates them more than it empowers them.

murukesh_s is obviously invested in this, so he's hardly an impartial observer, whereas I don't really care one way or the other and am just relying the experience of somebody helping users with these tools.

pembrook6• 5 years ago

That's because the unskilled stays unskilled for a reason: they can't or won't dedicate the amount of focus necessary to learn a technology to any meaningful degree.

The entire history of computers and software betrays this argument.

Every time we transitioned from a blank, text-command driven UI, to a visual one, we dramatically increased the percentage of the general population able to use something.

Think the transition from MS-DOS to Windows, UNIX to OSX, etc. By representing concepts visually, humans find them easier to understand.

In fact, I’d argue, most software innovation today is just making visual UI’s better. Think the single doc mode (photoshop) to artboard mode (sketch, figma). Single purpose (excel, word) to multipurpose (notion). Etc.

Notion is blowing up with 13 year old kids on Tiktok because it’s an easier UI to do spreadsheets and create documents and websites with. Which are fundamentally valuable things. In software, what is valuable, will be made easier over time.

Most B2B Saas tools are just crud apps. Not only is there no reason coding these apps has to stay complicated, but there’s economic incentive in making it easier.

Unfortunately, many people have a vested interest in keeping things complicated. Like people who get paid to create CRUD apps.

As the saying goes, it is difficult to get a man to understand something when his salary depends on his not understanding it.

sergiosgc• 5 years ago

I understand your point, and I also see where toyg comes from. Let me try to phrase it another way:

Some tasks are inherently complex. Take data modelling as an example. Properly designing a database requires formal training. There's no way around it, and when you mask database design with a UI, you get the worst of both worlds. The complexity is there, unskilled users won't be able to tackle it, and the UI gets in the way of professionals with formal training.

Naturally, there is a continuum of tasks to be done, some can be solved with a poorly designed solution. If a user is empowered to generate a subpar solution, it is still better than no solution at all. That's the secret for Excel being the second best tool for any data manipulation task (for each task there is a better tool, but excel gets the job done in all of them).

The error here is selling visual programming tools as the next evolution step, which will phase out text UIs. It's not. It's a different tool, for a different use case, to be used by a different cohort of users.

toyg5• 5 years ago

I agree on some of your points but not all of them, and some examples are downright wrong ("Unix to OSX" has nothing to do with visualization and all to do with reliability). We are talking about visual programming, not generic interaction.

One thing that your examples tend to have in common is that they deal with describing states (documents), not modelling processes. Maybe that has something to do with it. Describing actions ends up effectively requiring flowcharts, which is what visual programming typically ends up being, and that gets painful and slow tremendously quickly. That's why visual programming tools do not endure: because once you get skilled enough, you will find them annoyingly constrained.

I can just point out that my niche (accounting) is arguably one of the oldest in computing. Visual programming to address accounting challenges has been tried over, and over, and over, and it failed. every. single. time. It's a massive target that everyone hopes to hit, because the jackpot is massive, but I would argue that it will never happen. Excel keeps winning because it doesn't even try to play that game: if you want to do anything beyond instant calculation, it gives you VBA and off you go. That's what people really want: if they are smart enough to want advanced process modelling, they are smart enough to learn how to write an "if" block.

it is difficult to get a man to understand something when his salary depends on his not understanding it.

Believe me, there is also a large industry of programmers invested in visual paradigms; and their salary depends directly on not understanding the lessons of the past.

bryanrasmussen2• 5 years ago

Every time we transitioned from a blank, text-command driven UI, to a visual one, we dramatically increased the percentage of the general population able to use something.

Is there an upper bound to the benefits of visual information in comparison to textual information when handling complex tasks so that when a task reaches a certain level of complexity it becomes easier to represent it in text as opposed to visually? The history of human communication would strongly suggest that there is.

Fire-Dragon-DoL• 5 years ago

I think this is overlooking how faster is to develop for command line interfaces, as well as to how widespread command line software is.

What are the numbers considered when making these assessments? With visual software, we got way more adoption, but this doesn't mean the amount of software necessary increased. I'm pretty sure the majority of the software out there is made of command line tools. The amount of software a developer uses is very large and entirely made of small command line tools, there are entire O. S. made purely for command line usage (any server distribution really).

Finally, there is another giant elephant being overlooked. Software is written in text because in the hands of a skilled professional, text can be VERY visual. I don't have to prove this, there is extensive amount of poetry written to confirm this. Effectively a piece of software written by a skilled professional will greatly benefit every reader, and readers of software are way more than writers of software even in the software development world.

Your example about HTML and CSS is also a very special example. Effectively HTML and CSS are tools to build UIs, not "generic software". There is a lot of software out there that doesn't involves humans at all. I mean, cron is on the majority of the servers out there, it has no UI.

blacktriangle2• 5 years ago

I'm one of those people who gets paid writing B2B CRUD apps, so I certainly have economic incentives to keep CRUD in the hands of professionals. However, back in academia I spent a few years working on two different no-code platforms whose target users were PhD researchers, ie smart people with a professional interest in learning how to leverage no-code platforms.

Both projects followed the exact same trajectory: users ultimately rejected the no-code platforms and sent all of the programming work back to professional developers. Now the professional developers were hamstrung by layers of abstraction designed for non-developers and both parties were miserable.

Excel is the shining example of no-code enabling non-professionals to create powerful tools on their own, but it may be the exception and not the rule. Ultimately the challenges of programming are not the code, but thinking abstractly about data, and that's a real skill that developers have trained and non-developers have not, and I don't think it is solvable with tooling.

hermitcrab• 5 years ago

There is a place for code, no code and eveything in between. Code is more expressive. No code is generally faster (in the limited domain for which it is intended).

The big mistake comes when no code tools are overhyped, as happens so often. No code tools are only ever going to be applicable to relatively narrow domains. Trying to make them completely general, like a general coding language, is invariably a bad idea.

My https://www.easydatatransform.com/ tool is primarily a visual drag and drop tool for transforming data (join, filter, pivot etc). But one of the 50 transforms is a Javascript transform, so you can drop down and do some coding if you have a really obscure data transformation. That seems like the best of both worlds to me.

Cthulhu_• 5 years ago

I feel like I'm effectively writing a "no code" tool at the moment; it's a GUI whose user inputs will eventually be output as a configuration file that is fed into our core system (mobile network signal processing, in the broadest sense of the word).

In theory, end-users and operators could work in the configuration files directly themselves (it's a combination of XML templates and files, and .ini-like config files). The GUI is there to prevent footguns and add convenience.

Anyway it's not very visual, it's a lot of forms and pop-up segments with more forms, but still, one could argue it's a no-code environment. I should look into the area.

Mind you, I'm working on a rebuild and at the current rate it'll take me years to even start thinking of doing anything more advanced than replacing the existing forms.

[personal rant[ I'm not sure if I want to spend the next years at this company either; they're doing well enough financially but it's a slow burner. They're hiring, but the wages are stagnant and dare I say below market rate. I'll have to review in 6 months or end of year.

jackrowelle• 5 years ago

It gives a huge opportunity for people who don't know how to code. It can't be a lie.

littlecranky67• 5 years ago

Whenever I hear "no code", in my head I hear: no test pyramid, no CI/CD, no VCS, no documentation, no scalable database.

But I also hear "future rewrite by a contracted professional after MVP validation" which I like.

A second look at "no code" tools (2019)

Related Stories