Not sure about this - where I agree with you is that it's likely to see a movement to visual tooling in areas that are inherently visual, e.g. front-end (and then especially the presentation layer of the front-end), but in other areas I'm not so sure.
What we need (I would think) is increasing the abstraction level, meaning that we'd not be replacing code with pictures, but we'd replace code with less code. I can definitely see that - the amount of code that currently needs to be written even for a trivial app is staggering.
I can hardly imagine that in 10 years from now we'll still be coding all of the pretty low-level and mundane stuff like user onboarding, login/signup and so on, which we're still implementing again and again, ad nauseam ... instead we'll probably just tick a few checkboxes somewhere, or add a switch to a console command, and voila it's all there.
And somehow I suspect that a lot (most?) of the software we're writing now won't have to be written at all, in 10 years from now - as in many other areas it might very well be the case that a lot of the work will be automated away by things like AI and so on, especially the more mundane and repetitive parts.
But, regarding code (text), it still has a number of clear advantages compared to diagrams and 'pictures' - easier to manage in version control systems, in many cases easier to reason about, and so on.
CEO of Restspace.io, which lets you build and integrate backends with tiny services and no code. Been CTO and developed across the stack at a range of agencies and startups.
What's really interesting is to consider why these mundane repetitive tasks are not already abstracted away into code packages with config. What we see is that some of the work can be abstracted away e.g. Auth0 service or a React login form component. The problem is integrating these reuse elements vertically across the horizontal layers, and also how they interact with custom code and other similar components. In this example, how does the login component know where to find the Auth0 service? Does it tie you into Auth0 as a third party provider? Where are your users stored and how will your code and other components find them? Classic ASP.Net had a go at this as its components where server/client integrated but the resulting abstraction was leaky as a sieve and horrible to use. We need some innovations around code structure, reuse and interoperability to make this work. I look at some of this in this article: restspace.io/blog/Web%20reusabilit.... I'm also working on a way of having front end NPM component packages (like the React login component) express their back end API and infrastructure requirements declaratively and having a system which fulfils those requirements automatically on the back end.
That's very interesting ... having looked at Restspace, one thing that jumped out to me was the principle "Uniform interfaces to functionality" - that's very essential, example:
Something like Auth0 gives us a "chunk" of functionality (a service or a component, whatever you want to call it) that we can 'simply' drop into our app - this means writing less code, but we still write code, talking to the Auth0 API ... now, what if we don't want Auth0 but another service or component - we have to change our app, because that other service will have a different API - there is no standard!
In other words, because standard interfaces don't exist, we have to write "glue" code or adapters every single time. Even though we get a chunk of pre-made functionality, we still spend time because we need to fit a square peg into a round hole. This is what causes the "reinventing the wheel" syndrome, the feeling that as developers we're reimplementing the same trivial stuff time and again.
Compare that to the situation in other "industries", for instance construction or plumbing or you name it - those industries are chock full of standards, with names like DIN or ISO and so on. A plumber or an electrician buys a component (a pipe, or a faucet, or a transistor) with certain "specs" and then he/she can be sure that it will fit onto the other components he's purchased before.
Once we have these standard interfaces, then you can start inventing a very high level "specification language" which declaratively states what the components are and how they should interact. And then there would be a runtime which interprets this declarative "pseudo program" and makes the app or system come alive.
And for specific customizations or specialized parts of the system/app you could have "escapes" which allow you to hook into the program/runtime with snippets of code that you write in a conventional language (like Javascript).
Note that all of this becomes orders of magnitude easier if we reduce the degrees of freedom, so if we limit the options. So if we say, for instance, that we only support one target language (for instance, only Javascript, no PHP or Ruby or Python) then we reduce the complexity of this "platform" in a huge way. Same story if we'd say that we support only one database, and so on. So if we'd limit the number of options then we'd vastly simplify things.
(so part of the problem is that in the software world everyone and their brother (or sister) likes to invent their own programming language, database, frontend framework, CMS, and so on)
But, all of this is nice and good, but:
(a) pulling this off will require a monumental effort and a huge investment, and
(b) fragmentation won't end if a dozen alternative platforms like Restspace are popping up (in other words, there would still be no industry standard unless we make it so), and
(c) actually I'm afraid that there's not that much of an incentive to make this work, because you could very well argue that as an industry (developers) we'd be shooting ourselves in the foot!
In other words, the current situation where we're spending a lot of time eternally reinventing the wheel is of course a great job creator :-) and, in general we really like what we're doing, right now - so, in yet other words, in whose interest would this be ... at the same time I'm convinced that at some point in the future this status quo WILL change, whether we like it or not.
CEO of Restspace.io, which lets you build and integrate backends with tiny services and no code. Been CTO and developed across the stack at a range of agencies and startups.
Great response! Yes this is pretty much what I'm trying to do with Restspace. One way of standardising the connection between components is that even small components running on the same server all use the data structure of an HTTP message to communicate. Within the same server, code level routing sends these HTTP data structures without using the wire, but the runtime determines if the URL is external and goes across the net if necessary. This creates internal interoperability, allows the components to be distributed across servers however you like, and potentially pulls in every API available on the internet. Then the structure of the API is standardised across services providing the same functionality by adapting internal and third party services. For instance, the basic data API is simply to do a GET to read data or a PUT/POST to write data to a url. Data structures are defined by JSON Schemas. The service providing this API can have an adapter plugged into it which talks to the file system, MongoDb, S3, a SQL database or whatever.
This then enables a module/package to know where and how it needs to store data. For instance the 'full stack' auth package can be told a url in the data store API for storing user records, and it immediately knows how to do this, without restricting what underlying technology you want to use. An email package then also knows how to get user data and can just be wired up to the url in order to get the user data to customise an email template.
To your points, having been working on this for a while, the effort is actually not that massive, at least to get a set of core functions together. There would likely be some fragmentation initially but like most of these things, there are network effects at work and the winner of an initial battle would become a de facto standard. Dev has constantly been pushing effort up the stack and away from the generic into the more distinctive aspects of applications. I recently saw a Twitter threads where devs listed the things they hated doing repeatedly, and those are the things a system like this would be ideal for.
Very cool project and a great effort, I've saved this to my notes, looks worth trying out. By the way is it open source? I saw a couple of Github repos (github.com/restspace) but looks like that covers only a small part of it. Ah I see the answer here in the docs:
"We are also considering open-sourcing the runtime so you can run it wherever you wish"
So that would be "not yet but maybe in the future".
CEO of Restspace.io, which lets you build and integrate backends with tiny services and no code. Been CTO and developed across the stack at a range of agencies and startups.
Many thanks for the kind words! Yes, basically I'd love to open source this but it will never fulfil its promise unless there is some cashflow to support development. Quite likely it will work as an open source project with a paid for hosting like the model Wordpress has, however it needs some thought how to do that without losing the chance to make some revenue. I'll definitely open source components which it makes sense to do.
Ah yes this is 100% fair and valid. I think to maintain the advantages of text I'm a big fan of visualizations that derive from the code, like in the case of JSX Lite and Build so you can keep using all your code tooling and workflows and visualization is purely optional.
But also agree that some things are not as inherently visual like game and frontend dev. That said I've seen some interesting stuff around for visualizing data flow in code, which brings me back to the idea of (optional) visualizations on top of (text based) code, which can have multiple formats too (eg visualize and edit the same code as a data graph, text based, maybe even block based, based on what type of editing or debugging you are doing)
Well I don't have a crystal ball, so I don't know exactly what the future is going to look like, but I think it's safe to assume that things will be really different in let's say 10 years from now - I can't imagine that we'll still be doing things the same way, writing tons of code for mundane stuff like user onboarding and so on.
Probably somehow the abstraction level and the 'automation level' will be much higher. I wouldn't be surprised if we'd be coding in a very high level pseudo-code language, and/or with abstract diagrams - and these two would then be just two representations of the same "model" (round-trip engineering).
Yes, I feel that that might very well be our future - we'll just design a "model" and voila we'll have our app or your system - all of the low level details will be managed by some sort of runtime. And maybe AI will be thrown in the mix.
So, to a large extent this actually sounds a lot like what your post was suggesting? :-)
Ah yes absolutely. Also worth noting there are ways to do this without additional artifacts generated that could go out of sync too. Eg in the case of JSX Lite and Build they parse the (javascript) source file to an AST, store and modify that in memory only when editing visually, and changes are applied back to the source code without anything else generated or saved
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not sure about this - where I agree with you is that it's likely to see a movement to visual tooling in areas that are inherently visual, e.g. front-end (and then especially the presentation layer of the front-end), but in other areas I'm not so sure.
What we need (I would think) is increasing the abstraction level, meaning that we'd not be replacing code with pictures, but we'd replace code with less code. I can definitely see that - the amount of code that currently needs to be written even for a trivial app is staggering.
I can hardly imagine that in 10 years from now we'll still be coding all of the pretty low-level and mundane stuff like user onboarding, login/signup and so on, which we're still implementing again and again, ad nauseam ... instead we'll probably just tick a few checkboxes somewhere, or add a switch to a console command, and voila it's all there.
And somehow I suspect that a lot (most?) of the software we're writing now won't have to be written at all, in 10 years from now - as in many other areas it might very well be the case that a lot of the work will be automated away by things like AI and so on, especially the more mundane and repetitive parts.
But, regarding code (text), it still has a number of clear advantages compared to diagrams and 'pictures' - easier to manage in version control systems, in many cases easier to reason about, and so on.
What's really interesting is to consider why these mundane repetitive tasks are not already abstracted away into code packages with config. What we see is that some of the work can be abstracted away e.g. Auth0 service or a React login form component. The problem is integrating these reuse elements vertically across the horizontal layers, and also how they interact with custom code and other similar components. In this example, how does the login component know where to find the Auth0 service? Does it tie you into Auth0 as a third party provider? Where are your users stored and how will your code and other components find them? Classic ASP.Net had a go at this as its components where server/client integrated but the resulting abstraction was leaky as a sieve and horrible to use. We need some innovations around code structure, reuse and interoperability to make this work. I look at some of this in this article: restspace.io/blog/Web%20reusabilit.... I'm also working on a way of having front end NPM component packages (like the React login component) express their back end API and infrastructure requirements declaratively and having a system which fulfils those requirements automatically on the back end.
That's very interesting ... having looked at Restspace, one thing that jumped out to me was the principle "Uniform interfaces to functionality" - that's very essential, example:
Something like Auth0 gives us a "chunk" of functionality (a service or a component, whatever you want to call it) that we can 'simply' drop into our app - this means writing less code, but we still write code, talking to the Auth0 API ... now, what if we don't want Auth0 but another service or component - we have to change our app, because that other service will have a different API - there is no standard!
In other words, because standard interfaces don't exist, we have to write "glue" code or adapters every single time. Even though we get a chunk of pre-made functionality, we still spend time because we need to fit a square peg into a round hole. This is what causes the "reinventing the wheel" syndrome, the feeling that as developers we're reimplementing the same trivial stuff time and again.
Compare that to the situation in other "industries", for instance construction or plumbing or you name it - those industries are chock full of standards, with names like DIN or ISO and so on. A plumber or an electrician buys a component (a pipe, or a faucet, or a transistor) with certain "specs" and then he/she can be sure that it will fit onto the other components he's purchased before.
Once we have these standard interfaces, then you can start inventing a very high level "specification language" which declaratively states what the components are and how they should interact. And then there would be a runtime which interprets this declarative "pseudo program" and makes the app or system come alive.
And for specific customizations or specialized parts of the system/app you could have "escapes" which allow you to hook into the program/runtime with snippets of code that you write in a conventional language (like Javascript).
Note that all of this becomes orders of magnitude easier if we reduce the degrees of freedom, so if we limit the options. So if we say, for instance, that we only support one target language (for instance, only Javascript, no PHP or Ruby or Python) then we reduce the complexity of this "platform" in a huge way. Same story if we'd say that we support only one database, and so on. So if we'd limit the number of options then we'd vastly simplify things.
(so part of the problem is that in the software world everyone and their brother (or sister) likes to invent their own programming language, database, frontend framework, CMS, and so on)
But, all of this is nice and good, but:
(a) pulling this off will require a monumental effort and a huge investment, and
(b) fragmentation won't end if a dozen alternative platforms like Restspace are popping up (in other words, there would still be no industry standard unless we make it so), and
(c) actually I'm afraid that there's not that much of an incentive to make this work, because you could very well argue that as an industry (developers) we'd be shooting ourselves in the foot!
In other words, the current situation where we're spending a lot of time eternally reinventing the wheel is of course a great job creator :-) and, in general we really like what we're doing, right now - so, in yet other words, in whose interest would this be ... at the same time I'm convinced that at some point in the future this status quo WILL change, whether we like it or not.
Great response! Yes this is pretty much what I'm trying to do with Restspace. One way of standardising the connection between components is that even small components running on the same server all use the data structure of an HTTP message to communicate. Within the same server, code level routing sends these HTTP data structures without using the wire, but the runtime determines if the URL is external and goes across the net if necessary. This creates internal interoperability, allows the components to be distributed across servers however you like, and potentially pulls in every API available on the internet. Then the structure of the API is standardised across services providing the same functionality by adapting internal and third party services. For instance, the basic data API is simply to do a GET to read data or a PUT/POST to write data to a url. Data structures are defined by JSON Schemas. The service providing this API can have an adapter plugged into it which talks to the file system, MongoDb, S3, a SQL database or whatever.
This then enables a module/package to know where and how it needs to store data. For instance the 'full stack' auth package can be told a url in the data store API for storing user records, and it immediately knows how to do this, without restricting what underlying technology you want to use. An email package then also knows how to get user data and can just be wired up to the url in order to get the user data to customise an email template.
To your points, having been working on this for a while, the effort is actually not that massive, at least to get a set of core functions together. There would likely be some fragmentation initially but like most of these things, there are network effects at work and the winner of an initial battle would become a de facto standard. Dev has constantly been pushing effort up the stack and away from the generic into the more distinctive aspects of applications. I recently saw a Twitter threads where devs listed the things they hated doing repeatedly, and those are the things a system like this would be ideal for.
Right, I see what your getting at, very interesting ... looks very well thought out with these services, pipelines, data transforms and so on:
restspace.io/
Very cool project and a great effort, I've saved this to my notes, looks worth trying out. By the way is it open source? I saw a couple of Github repos (github.com/restspace) but looks like that covers only a small part of it. Ah I see the answer here in the docs:
"We are also considering open-sourcing the runtime so you can run it wherever you wish"
So that would be "not yet but maybe in the future".
Many thanks for the kind words! Yes, basically I'd love to open source this but it will never fulfil its promise unless there is some cashflow to support development. Quite likely it will work as an open source project with a paid for hosting like the model Wordpress has, however it needs some thought how to do that without losing the chance to make some revenue. I'll definitely open source components which it makes sense to do.
Yes I definitely see what you mean, I get your point, totally.
Ah yes this is 100% fair and valid. I think to maintain the advantages of text I'm a big fan of visualizations that derive from the code, like in the case of JSX Lite and Build so you can keep using all your code tooling and workflows and visualization is purely optional.
But also agree that some things are not as inherently visual like game and frontend dev. That said I've seen some interesting stuff around for visualizing data flow in code, which brings me back to the idea of (optional) visualizations on top of (text based) code, which can have multiple formats too (eg visualize and edit the same code as a data graph, text based, maybe even block based, based on what type of editing or debugging you are doing)
Right, I see what you mean - I'd call that round-trip engineering:
en.wikipedia.org/wiki/Round-trip_e...
Well I don't have a crystal ball, so I don't know exactly what the future is going to look like, but I think it's safe to assume that things will be really different in let's say 10 years from now - I can't imagine that we'll still be doing things the same way, writing tons of code for mundane stuff like user onboarding and so on.
Probably somehow the abstraction level and the 'automation level' will be much higher. I wouldn't be surprised if we'd be coding in a very high level pseudo-code language, and/or with abstract diagrams - and these two would then be just two representations of the same "model" (round-trip engineering).
Yes, I feel that that might very well be our future - we'll just design a "model" and voila we'll have our app or your system - all of the low level details will be managed by some sort of runtime. And maybe AI will be thrown in the mix.
So, to a large extent this actually sounds a lot like what your post was suggesting? :-)
Ah yes absolutely. Also worth noting there are ways to do this without additional artifacts generated that could go out of sync too. Eg in the case of JSX Lite and Build they parse the (javascript) source file to an AST, store and modify that in memory only when editing visually, and changes are applied back to the source code without anything else generated or saved