To me it seems logical that designers should one day be building frontends through visual interfaces that are almost as malleable as tools like Sketch. It seems to me that many features from design programs (like Framer) seek to make design closer to development, and we've even seen a Git for design workflows. So why hasn't it happened yet, and will it ever?
Here's some problems that I can think of with visual programming:
- Version control: Not only the logic of the system, but the shape of the visual representation needs to be tracked... along with a lot of other metadata.
- Debugging: Visual programs need yet another step of compilation and translation, to go from visual to text to machine code. This makes debugging much harder to implement, if it's even an option.
- Architecture: Visual programming environments are usually optimised for a certain way of doing things. This effectively cements the architecture of your system.
- Refactoring: Without text, you're going to have a hard time renaming variables and moving things around, basically it's back to the mouse... you could go through the text-source files and find/replace variable names, but that defeats the purpose of the visual abstraction.
- Verbosity: Displaying the programs visually - usually a graph of nodes - is extremely verbose and cumbersome. Trying to navigate a large graph/tree and work out what's going on is difficult. Text on the other hand scales much better for large programs.
- Integrations: Integrating the system with obscure libraries is often difficult or not possible at all. Using a library in node or python is simple, in a visual environment you're generally relying on the pre-built components/nodes...
- Vendor-lockin: Visual programming languages are generally all propitiatory making them extremely hard to migrate off.
- High Complexity: A text-based language simply needs a compiler to run, as text-editors are interchangeable. A visual language needs a compiler and a visual editor, which makes development of the system much more difficult and complex.
Basically, I think text-based programming is here to stay. Text is simple, flexible, efficient, elegant and most importantly it's one of the most concise ways to convey logic of a system.
The other day I tried to reverse engineer a lego mindstorm program from a pan across it in a youtube video(stitching together screenshot frames with Hugin panorama editor), only to find that that visual language was dependent of a silverlight app, and OSX had deprecated it, so I could only use scratch to re-create the logic. Then the scratch editor crashed and corrupted my project file, which when opened in a text editor was just a big encoded data blob. So I started from scratch and took to copying the file (file (1), file (2)..) every so often.. I did not feel like the future to me..
Of course it doesn't feel like the future when you are maintaining your code with something other than modern practices.
https://github.com/hofstadter-io/hof
(sorry to post link twice in same topic, but seems helpful.to have it in the two spots more than not)
I can stand up a cluster of web servers that automatically scale to effectively infinite demand with a few clicks on the internet.
I can design a front end without paying attention to code and have been able to for 20 years.
No code is like AI. The goal posts keep moving. So you need to be more specific when you ask if it’s what’s next.
There's the common cases with businesses being built on top of a pile of Excel spreadsheets. It is also easy to take for granted, but things like hosting your own website, or setting up an e-commerce service could be done without much code for a very long time now.
But the cool thing is that nowadays, it is possible to do more sophisticated things, like spinning up interactive web apps that are backed by self-hosted databases with authenticated APIs, all without writing a lot of code. Is this a good way to build things? Maybe. It wouldn't be the most maintainable stack, but the barrier to entry is pretty minimal, and that makes it worthwhile.
But, "=SUM(A1:A10)" is code. Spreadsheets have a visual layout and mental model different from other programming languages, but they are code none the less.
I still don't know whether that's really true.
On one side, there's the observation I've made with low-code (having been at an org and bailing right around the time they started going down that road;) When I was at the 'free training' (just a sales pitch) most of the people there were from other medium to large size companies, a couple of those companies multinational.
B/c the sales pitch I've seen isn't to startups; it's to bigger orgs. It was actually pretty disturbing to listen to the sales rep explain as developers would leave through attrition/disgust at the product they could be replaced by 'non coders.' No, it wasn't exactly said like that but the sentiment was understood by all the developers (not managers) in the room.
Okay, so lets say that they clean up their sales act (lol) and actually start to go towards smaller business.
Those business are still going to wind up with a product that may or may not be maintainable long term, but are now guaranteed to be paying yearly licensing costs.
No thx.
Since I don't really do any math or accounting, I suppose spreadsheets are a type of flat-file database.
Also, I don't really get the hostility for code as a textual format. Text has a number of advantages that just haven't been replicated; it's a very compact format, reasonably standardized, can easily be refactored and can be universally edited. Also, I don't think it hinders learning about programming; learning the programming language syntax is the easiest part, IME. It took me about 4 weeks when I was 14 to learn Java. Learning how to solve problems with the language is a whole different ballgame and that wouldn't be solved by having a graphical programming language. There are cases where it is advantageous (e.g. Excel), but for the majority of use-cases, I think you'll find it hard to get more productivity with a graphical format.
> Software has really interesting economics where as the cost/feature decreases by a factor, say 1x, then the set of features that can be profitably worked on expands by like 10x, so paradoxically, as cost/feature decreases, it makes sense to hire more engineers and expand R&D budgets.
"No code" is part of this, IMO. If a "no code" tool made certain things easier (e.g. building a landing site with some functionality), then the business starts to see the next set of features that can/should now be built because that previous problem was solved, that can't be done with a "no code" solution and needs some R&D effort to build out. The cycle continues as "no code" tools get more advanced to cover those use cases, and then more new business use cases will come out as a result of having those new tools in place.
And then we write the code and our ecosystem gets broken and we build needless complexity, and we realize that 90% of the time a simple config file will work. And then we replace the config with a control panel. And then we need more options, so that becomes a slick GUI.
And so on, and so forth.
IMO we have been optimizing the design of digital experiences for professional/commercial applications for 30 years and we have about 30 more years before we get it "right" and that solution will be (more or less) HTML templates. A declarative low level language that expresses everything possible, surrounded by multiparadigm languages that can compose it, and user interfaces that compile visual representations into those contextually. There's no one best approach.
The latter is not impossible, but there is a tradeoff. As computers have endless capabilities, a hue number of design choices need to be specified in order to select/create the specific outcome desired.
This required information need can for the end programmer/designer be reduced by shrinking the potential design space through premade implicit descisions. Creating a 'stopwatch' app from scratch starting with a blinking cursor in an empty text file will require a lot more specification than creating it in a dedicated graphical stopwatch designer where all that is still needed is specifying the color of the start/stop button, but the former leaves you endless more possibilities than the latter.
Getting the above tradeoff right usually runs into the 80/20 situation. You can live with 80% of the choices made, they cover 80% of your needs, but for the rest...
And now your non-coder runs into a problem. Not only is the skillet promise now void, the higher level abstraction made in the 'no code' model is not crisply delineated, so the coder brought in to finish the job now has to understand the complexities of the code underlying the abstraction where the design tradeoffs were chosen not in favor of this under the hood meddling.
A similar problem occurs when a bug or unforeseen configuration breaks the no code veil. This is referred to as the 'leaky abstraction' problem.
In the end usually you still need a coder that understands the lower level. And specifitions for highly open systems are more efficient conveyed and maintained through textual 'code' than through other types of graphical editors.
You can create pure documents for the web without any code. Documents are, by nature, easily expressed declaratively; and it's not impossible to build an intuitive interface to express declarative data visually (or hide the data aspect completely in the case of a WYSIWYG interface).
Modern web pages are, in my mind, a sort of document/application hybrid (with few exceptions as of 2020). We have yet to find a better way to express an application than through textual code.
Procedural code is branching and time sequenced; how do you express that in a meaningful way visually? For some reason our imaginations find it easy to understand that the side effects of every line before this one are still around, and we're pretty good at picking up the concept of branching and jumping around the instructions; but I believe that's because the code is essentially a sequenced list of commands (and our brains are good with sequenced lists).
The attempts I've seen at visual programming remove common programming capabilities to fit more neatly within their visual medium; as long as that is the case, I don't see visual programming breaking out of being used strictly in DSLs (domain specific languages), which are often inherently limited.
I don't think a no code future is likely, as long as custom software is in demand; however I can see a future where fewer technician type roles require code. Of course that would require someone to spend a lot of money building a standard visual vocabulary of related tasks, excellent ergonomic interfaces, and extensible GUI systems; the type of things the FOSS world hasn't built much of a community for as far as I am aware.
Basically; you can run a rather medium sized company on google docs or ms office or a bunch of trivial crud apps hacked in php/AD; I know rather a scary amount of companies that do work like that. They are not the biggest companies (I know of at least one that has well over 150m revenue/year for the past 20 years; most others are smaller) but they also spend almost nothing on (that kind of) IT and it works. The corner cases are removed from the business process instead of hacked into the IT flow.
If you never learned your times tables, then used a calculator, imbedded calculation loops are tricky to troubleshoot .
" no code" layers this more deeply, creating a very large number of programming code lines, function calls and subroutines on interpreted code that runs slow anyway. It can be difficult to untangle when things just don't work right.
Interpreted code always runs slower that code compiled into machine code. Maybe adding in AI and machine learning will eventually be able to take this first-rev , " no code " prototyping and optimize it into an efficient, effective, fast system that is bullet proof, and intellectually protected.
You are right about the complexity hiding and difficulty therein. It's part of the reason ours is open source.
Would we consider a no code product to build the fundamental pieces or our actual product? Likely not based on the tools I've tried over the years.
Wish it wasn't so though. The disconnect/handover from design to implementation is still a bottleneck. Tools like Figma offer ways to export CSS, etc. but that's not really the main pain. The real time sync is in coordination, iteration, time spent on designs that change out from underneath you, etc.
People who still wanted static sites often kept them simpler and made them by hand, or used some scripts to tack on the complex parts (consistent nav bars, headers, footers, etc.) in a "compilation" step.
But it hasn't and I'm not sure we're there yet.
And no code I don't think has taken over the desktop world yet has it? That's a hell of a lot more mature area front end wise.
Some examples are 3d fonts and signage, interfaces without windows (widgets just float wherever), whole new deaths of UI elements and building blocks. Oh, and the mouse is gone in favor of hand tracking and the most amazing digital interaction I have ever experienced. One week in and my mind is still blown by the possibilities.
Granted ... SSDs finally came to PCs too, eventually ;)
Docs are a bit MIA, so I haven't pushed it much yet, but you can check out the lib/gen dir and the Cue files for examples. I'm very curious to hear what more developers with strong opinions about low code think.
