15 ms·

The Railsification of SaaS

149 points by keithwhor 6y ago

keithwhor 6y ago
Hey all, I wrote this to talk a little about how I think about the future of software development in the next decade; I'm happy to chat about it if anybody has any questions or additional thoughts. :)
- ufvy 6y ago
  Unfortunately Autocode doesn’t use graphql
  - keithwhor 6y ago
    You're half-right - we have a specification called FunctionScript [0] that can act as what's basically a universal translation layer for any API. You just generate a proxy to it using FunctionScript. So it's possible to add GraphQL APIs to our stdlib, it's just not convenient right now. All of Shopify is a GQL API, for example. The reason we don't support GQL APIs natively is because we designed Autocode to follow the best practices of the top API companies we knew; Twilio and Stripe. Both companies designed their SDKs in a way that feels natural: a call to their API is achieved via a namespaced function call -- it's very Railslike. Everything available in our stdlib follows that convention as we felt it was the most intuitive approach to API / SDK design. [0] https://github.com/FunctionScript/FunctionScript https://github.com/FunctionScript/FunctionScript
- ucarion 6y ago
  How do you square this: > You can’t share a Zapier integration universally. With then plugging Autocode? How is an Autocode integration any more universal than a Zapier one? Also, how are you building the code for the various integrations Autocode supports? Is there some underlying interlingua that you codegen from?
  - keithwhor 6y ago
    I'll show you. Here's an example of an Autocode "integration," or something in our standard library. It's a Halo API I added for fun. You can use the gamertag "citizen kwho" to find me. https://autocode.com/lib/halo/mcc/ https://autocode.com/lib/halo/mcc/ As you can see from the code examples, you just talk to it via an API key and a standard calling convention. It's completely portable. Autocode makes it easier to manage your tokens, code, etc. but you could port this to any Node.js codebase or make an HTTP request from anywhere. We have universal Ruby and Python libraries, too, but they're a little outdated. (Small team, have had to stay focused on Node.js for now.) Edit: I'll mention that technically anybody can add to our stdlib. We do a lot of the work ourselves right now, but it's fundamentally an open platform. Also see other comment re: FunctionScript specification and how we add APIs to the stdlib. :)
    - cdcarter 6y ago
      Is there a place we can see the source for that Halo API binding?
      - keithwhor 6y ago
        Not specifically for that API. I'd have to spend some time cleaning it up to open source it. But we have a really simple API connector example you can fork [0]. :) [0] https://autocode.com/app/keith/connector-pokefusion/ https://autocode.com/app/keith/connector-pokefusion/
- mchusma 6y ago
  Do you have a way to migrate Zapier zaps? I feel like since that is the dominant ecosystem, having a way to easily port Zaps would be very beneficial. Building one of these things correctly is significant work, and it's hard to justify the investment in new platforms.
  - keithwhor 6y ago
    Not currently. We don't currently see a lot of migration from Zapier, but we do see a lot of net-new development. It's definitely something we've thought about but we have just as many users using us for general purpose scripting and webhooks as API automation.
thinkingkong 6y ago
Seems like the technical side of vertically integrated saas opportunities, which is mostly where things are going. Weve more or less built the parts bins. Now the remaining growth areas are in highly specialized, specific verticals. The issue I see is actually more to do with moving the data vs moving the computing. We currently perform all these integrations by moving the data around then taking 1% of it to do something useful. I wonder if offering serverless in-situ compute and assembling the results would be easier.
- xbar 6y ago
  Thanks for something truly thought provoking this evening.
- lambda_obrien 6y ago
  It would be neat to use a sort of reverse-holomorpic encryption, where the client could send the server a computation to perform on some data the client had access to then return the results, but the server cannot see exactly what the computation is, stepwise, so at to protect the client's internal business logic.
  - webmaven 6y ago
    There were a bunch of CS theses starting in the late 90s along those lines, some of the general labels used were 'trustless computing' and 'fog computing' or something similar. Other keywords are 'enclave' and 'opaque'. David Brin also promoted 'translucent databases' as a way to allow computations on aggregate data without the possibility of revealing individual rows. Intel has a related technology platform called SGX (Software Guard Extensions) in this space that is aimed at being able to run your own trusted code on infra owned and operated by potentially malicious providers. On the activist front, Doc Searls has been pushing a marketing/commerce twist on the idea of user-owned and controlled data under the labels 'Project VRM' (Vendor Relationship Management) and 'The Intention Economy' but without much traction.
    - thinkingkong 6y ago
edoceo 6y ago
Why the switch from stdlib.com to auto code.com? The first name was much cooler
- aaronbrethorst 6y ago
  stdlib means something to you and me, but to a broader audience it may suggest that it’s where you might go to learn more about chlamydia.
  - keithwhor 6y ago
    ... this too, though most people we met were polite enough to not argue this point too aggressively. :)
    - aaronbrethorst 6y ago
      I mean, it's too bad: I like the name stdlib.com.
  - edoceo 6y ago
    Oof, I didn't even think of that
  - cossatot 6y ago
    sharelatex.com (a LaTeX collaboration site) shared the same issue.
- keithwhor 6y ago
  We couldn't find a commercial model for stdlib.com alone; which means we couldn't support a team to build it. We learned that we needed to be able to provide significant value upfront instead of asking developers to rely on an unproven standardization scheme.
hazz99 6y ago
I find this trend really interesting, and agree that its one of the potential futures of personal computing. I've heard, on HN, people lamenting that an early vision of computing –– people creating their own applications –– has not arisen. Most people, outside of CS, have no idea how computers work. I think this post, the no-code movement, and products like Zapier show that there is a future for this. People don't need to know how computers work to create their own services – SaaS applications abstract over the implementation details, and APIs provide the interfaces for prosumers to connect them and build their own solutions. I'd be curious to hear your thoughts on Zapier. How do you think we can go beyond "API connector" products?
- keithwhor 6y ago
  API connector products are pretty much ubiquitous and that's the biggest sign, to me, that there needs to be centralization and consolidation in the market. Zapier, Mulesoft, Integromat, IFTTT, Automate.io, [...]. And then every at-scale SaaS product ends up building their own automation platform internally. The list goes on and on. In a lot of ways it's an extremely fragmented market. Every single one of these products starts out with the same epiphany we had, which is some variation of, "there needs to be an API for APIs...". People keep putting a band-aid when what's really needed is an architectural refactor of how we deliver and connect APIs, full-stop. The problem is there's very little market incentive to standardize how API integration works because it requires the complex coordination of thousands of companies and millions of developers. The barrier to transformation is extremely high, so the catalyzing agent has to be spectacular. A product (or set of products) needs to come along that completely changes the game and creates a real incentive to standardize and adopt a common integration scheme and format. The worst-case scenario for Autocode, as I see it, is becoming just another integration tool for some specific vertical. What we're striving to deliver is an open ecosystem for integrations that's accessible to non-developers who are going to derive the most immediate value from it as an introduction to development, but attractive to professionals as a development target as well. That's an extremely difficult balance to achieve but the rewards are just as large as the problem, technically the entire industry could be made more efficient at scale.
  - 6y ago
deleted 6y ago
[deleted]
lambda_obrien 6y ago
I think we should try to encode types in a common notation and create a gobal package manager for them. Then get people to actually use the types and you'll get much closer to automating API connectivity. I think Tree Notation and a yet to be developed package manager based on distributed principles would be a good start.
- keithwhor 6y ago
  If you’re interested in this we should chat. Google and Facebook effectively pulled this off for the web (OpenGraph and Semantic Search), but it has yet to be done for APIs. FunctionScript has a basic type system that’s a superset of JSON but there should be an overarching semantic system to it all. Feel free to e-mail me, keith@ (company domain) and introduce yourself if you’d like to chat about it. :) https://github.com/FunctionScript/FunctionScript/ https://github.com/FunctionScript/FunctionScript/
  - lambda_obrien 6y ago
    I think to truly get the interoperability you see in sci-fi you're gonna need to upend the large stack we currently build on and reconsider what we want to do with our software and computers. Adding APIs to everything is great for today's world, but all you're doing is gluing things together still. As we get less from physical chips, we'll have to get more efficient in computation, which means more standardized data formats from the start, less security concerns by using capabilities and a linked permissions system, remote computation rather than data retrieval, and things like that. I think you have to take a several pronged approach, because even then you can't solve a problem like this with tech alone, you need other things like education, collaboration, freedom, and protection from maligned interests. That's really hard to do, I think maybe SpaceX did something on a similar level for space and soon internet connections, but they don't have free and open tech due to profit motives, so it's not advancing the state of space tech overall, just the tech at SpaceX. Probably, you need a large nonprofit foundation with billions of dollars to just buy it's way into the market to get something grand like that adopted. I might email you, not sure I have the motivation for API building and chatting about APIs that you seem to, but I do like generalizing problems into the simplest forms.
wideareanetwork 6y ago
Is this an old post? I thought this happened about 10 years ago.
voiper1 6y ago
My issue with these no-code/low-code things is bootstrapping. I can work on code for free on my computer, and then host it for $5 on a VPS/month. With autocode or retool I'm now dealing with $20 or $10/user or lots more if I need any usage. That's not throw-away money anymore...
- keithwhor 6y ago
  :)
- hazz99 6y ago
  Assuming a single free development account, I'd happily pay $10 or $20 per additional user if it means I can find a concept with decent product-market fit. I can then build it more cheaply myself. Iteration speed is incredibly valuable. You often only need <10 users to get an idea about how useful your MVP is.
- villgax 6y ago
  Are you interested in something which lets you host the application out, once it's built, yet providing the option to host it on your behalf?
  - voiper1 6y ago
    I'm not quite sure what you mean. Hosted option is great - it's just the free tier seems so limited to me. I get these guys want to make money - need to make money to support the service. As a "hacker" I want to mess around and try things, and these seem to cater to that... until you see the price.
cheriot 6y ago
> Railsification of SaaS > SaaSification of Rails > RubyGems of SaaS APIs If all you have is Rails, the world looks like a Rails analogy.
miki123211 6y ago
IMO the way we currently do APIs is backwards. APIs should offer a way to run your own code in a sandbox, close to where the data is. That way, you don't have to worry about fine-grained or coarse-grained requests. All clients make just one request, supplying the code needed to retrieve the data. Of course, the untrusted code should only be allowed to use a restricted interface, depending on the scopes/permissions. It would be even better if the code could be statically analyzed, to determine the best SQL queries to perform. This would require a pretty radical rethinking of our stacks, but would bring great benefits. APIs would be simpler to make, and webpages would load much faster. We could even give third parties access to very sensitive information, as long as their code would be constrained in what it could return. Think of a service that requires KYC/AML verification. Your government could give it access to all your private information, but allow the code to return a single true/false response to preserve privacy. Much better than the current method of sending ID scans everywhere and praying they never get leaked.
- janekm 6y ago
  What you are describing used to be called "mobile information agents" in the late 90s ;) Sandboxing technology wasn't really quite ready for that at the time time... (not sure if it really is now, though arguably WASM is closer than JVM was) https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.544.6649&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.54...
  - HeyLaughingBoy 6y ago
    I completely forgot about information agent technology. It was supposed to be the Next Really Big Thing but seemed to fizzle out completely once the hype died down. Was it ever used for anything significant?
    - janekm 6y ago
      Nothing I’ve come across, though I feel one could make the case that many of the ideas live on in some shape (Web APIs, serverless/lambda, Etherium Solidity, Service oriented architectures...).
mtberatwork 6y ago
> In the 1990s we saw the mass industrialization of web development with PHP and Apache HTTP Server. This isn't really true. PHP4 wasn't released until 2000. Sure, OK, while there were people using PHP3 in the 90s, it wasn't nearly as ubiquitous to the point of "mass industrialization". PHP3 wasn't even much of a language to begin with and if anything, Java/J2EE was the stack used for "mass industrialization" (Java's role is still dominant in most domains today). Perl was also a much more popular scripting language at the time.
- nickserv 6y ago
  Completely agree. When I started un the late 90's and early 2000's, it was mainly CGI/Perl. PHP was seen as very amateurish, and Python didn't have the massive ecosystem it has now (Zope sucked). And that wasn't really industrialized, mainly lots of ad-hoc internal frameworks.
- acdha 6y ago
  ASP and ColdFusion, too. We had clients switch to PHP 3 because it was so much faster and less buggy (!) but that was definitely seen as a bit of a gamble.
- keithwhor 6y ago
  I had originally written this as a much longer piece — probably double the length — where I covered the history including CGI / Perl but edited for brevity. I never had experience with J2EE personally which is why it’s missing. I was 12 in the year 2000 and had just started web development — because of that PHP retains a sense of primacy in my mind. Forgive the bias :).
  - minhaz23 6y ago
    would love to read the original piece if you had no objection to sharing
    - keithwhor 6y ago
      It's lost to the void of lack of version control on Medium. I'd consider writing a new piece in the future, will let you know when I get to it!
webmaven 6y ago
Other than nitpicking the terminology/analogies used, I find myself in broad agreement with this post, although I would have liked a bit more analysis (even just backward looking) in terms of the market dynamics (eg. why PaaS lost it's early momentum and we backslid to assembling custom platforms out of IaaS components and services, the cautionary tale that OpenStack presents to efforts like OpenAPI, etc.), but I understand why not revealing one's thoughts on strategy might be the smarter choice. OTOH, I really would have expected Heroku to be mentioned in the 'SaaSification of Rails' section (since Heroku is literally 'Rails as a Service'), if only to state that it wasn't the intended meaning of the phrase (although Heroku's add-on marketplace can be seen as a stab in that direction).
- pas 6y ago
  PaaS lost because big corps are usually complex. Heroku is not enough for them. AWS got big due to it providing the services/components/building-blocks for big corps. Why talk only about big corps? Because that's where the money is unfortunately.

149 points by keithwhor 6y ago

Hey all, I wrote this to talk a little about how I think about the future of software development in the next decade; I'm happy to chat about it if anybody has any questions or additional thoughts. :)

ufvy 6y ago
Unfortunately Autocode doesn’t use graphql
- keithwhor 6y ago
  You're half-right - we have a specification called FunctionScript [0] that can act as what's basically a universal translation layer for any API. You just generate a proxy to it using FunctionScript. So it's possible to add GraphQL APIs to our stdlib, it's just not convenient right now. All of Shopify is a GQL API, for example. The reason we don't support GQL APIs natively is because we designed Autocode to follow the best practices of the top API companies we knew; Twilio and Stripe. Both companies designed their SDKs in a way that feels natural: a call to their API is achieved via a namespaced function call -- it's very Railslike. Everything available in our stdlib follows that convention as we felt it was the most intuitive approach to API / SDK design. [0] https://github.com/FunctionScript/FunctionScript https://github.com/FunctionScript/FunctionScript
ucarion 6y ago
How do you square this: > You can’t share a Zapier integration universally. With then plugging Autocode? How is an Autocode integration any more universal than a Zapier one? Also, how are you building the code for the various integrations Autocode supports? Is there some underlying interlingua that you codegen from?
- keithwhor 6y ago
  I'll show you. Here's an example of an Autocode "integration," or something in our standard library. It's a Halo API I added for fun. You can use the gamertag "citizen kwho" to find me. https://autocode.com/lib/halo/mcc/ https://autocode.com/lib/halo/mcc/ As you can see from the code examples, you just talk to it via an API key and a standard calling convention. It's completely portable. Autocode makes it easier to manage your tokens, code, etc. but you could port this to any Node.js codebase or make an HTTP request from anywhere. We have universal Ruby and Python libraries, too, but they're a little outdated. (Small team, have had to stay focused on Node.js for now.) Edit: I'll mention that technically anybody can add to our stdlib. We do a lot of the work ourselves right now, but it's fundamentally an open platform. Also see other comment re: FunctionScript specification and how we add APIs to the stdlib. :)
  - cdcarter 6y ago
    Is there a place we can see the source for that Halo API binding?
    - keithwhor 6y ago
      Not specifically for that API. I'd have to spend some time cleaning it up to open source it. But we have a really simple API connector example you can fork [0]. :) [0] https://autocode.com/app/keith/connector-pokefusion/ https://autocode.com/app/keith/connector-pokefusion/
mchusma 6y ago
Do you have a way to migrate Zapier zaps? I feel like since that is the dominant ecosystem, having a way to easily port Zaps would be very beneficial. Building one of these things correctly is significant work, and it's hard to justify the investment in new platforms.
- keithwhor 6y ago
  Not currently. We don't currently see a lot of migration from Zapier, but we do see a lot of net-new development. It's definitely something we've thought about but we have just as many users using us for general purpose scripting and webhooks as API automation.

thinkingkong 6y ago

Seems like the technical side of vertically integrated saas opportunities, which is mostly where things are going. Weve more or less built the parts bins. Now the remaining growth areas are in highly specialized, specific verticals. The issue I see is actually more to do with moving the data vs moving the computing. We currently perform all these integrations by moving the data around then taking 1% of it to do something useful. I wonder if offering serverless in-situ compute and assembling the results would be easier.

xbar 6y ago
Thanks for something truly thought provoking this evening.
lambda_obrien 6y ago
It would be neat to use a sort of reverse-holomorpic encryption, where the client could send the server a computation to perform on some data the client had access to then return the results, but the server cannot see exactly what the computation is, stepwise, so at to protect the client's internal business logic.
- webmaven 6y ago
  There were a bunch of CS theses starting in the late 90s along those lines, some of the general labels used were 'trustless computing' and 'fog computing' or something similar. Other keywords are 'enclave' and 'opaque'. David Brin also promoted 'translucent databases' as a way to allow computations on aggregate data without the possibility of revealing individual rows. Intel has a related technology platform called SGX (Software Guard Extensions) in this space that is aimed at being able to run your own trusted code on infra owned and operated by potentially malicious providers. On the activist front, Doc Searls has been pushing a marketing/commerce twist on the idea of user-owned and controlled data under the labels 'Project VRM' (Vendor Relationship Management) and 'The Intention Economy' but without much traction.
  - thinkingkong 6y ago

edoceo 6y ago

Why the switch from stdlib.com to auto code.com? The first name was much cooler

aaronbrethorst 6y ago
stdlib means something to you and me, but to a broader audience it may suggest that it’s where you might go to learn more about chlamydia.
- keithwhor 6y ago
  ... this too, though most people we met were polite enough to not argue this point too aggressively. :)
  - aaronbrethorst 6y ago
    I mean, it's too bad: I like the name stdlib.com.
- edoceo 6y ago
  Oof, I didn't even think of that
- cossatot 6y ago
  sharelatex.com (a LaTeX collaboration site) shared the same issue.
keithwhor 6y ago
We couldn't find a commercial model for stdlib.com alone; which means we couldn't support a team to build it. We learned that we needed to be able to provide significant value upfront instead of asking developers to rely on an unproven standardization scheme.

hazz99 6y ago

I find this trend really interesting, and agree that its one of the potential futures of personal computing. I've heard, on HN, people lamenting that an early vision of computing –– people creating their own applications –– has not arisen. Most people, outside of CS, have no idea how computers work. I think this post, the no-code movement, and products like Zapier show that there is a future for this. People don't need to know how computers work to create their own services – SaaS applications abstract over the implementation details, and APIs provide the interfaces for prosumers to connect them and build their own solutions. I'd be curious to hear your thoughts on Zapier. How do you think we can go beyond "API connector" products?

keithwhor 6y ago
API connector products are pretty much ubiquitous and that's the biggest sign, to me, that there needs to be centralization and consolidation in the market. Zapier, Mulesoft, Integromat, IFTTT, Automate.io, [...]. And then every at-scale SaaS product ends up building their own automation platform internally. The list goes on and on. In a lot of ways it's an extremely fragmented market. Every single one of these products starts out with the same epiphany we had, which is some variation of, "there needs to be an API for APIs...". People keep putting a band-aid when what's really needed is an architectural refactor of how we deliver and connect APIs, full-stop. The problem is there's very little market incentive to standardize how API integration works because it requires the complex coordination of thousands of companies and millions of developers. The barrier to transformation is extremely high, so the catalyzing agent has to be spectacular. A product (or set of products) needs to come along that completely changes the game and creates a real incentive to standardize and adopt a common integration scheme and format. The worst-case scenario for Autocode, as I see it, is becoming just another integration tool for some specific vertical. What we're striving to deliver is an open ecosystem for integrations that's accessible to non-developers who are going to derive the most immediate value from it as an introduction to development, but attractive to professionals as a development target as well. That's an extremely difficult balance to achieve but the rewards are just as large as the problem, technically the entire industry could be made more efficient at scale.
- 6y ago

deleted 6y ago

[deleted]

lambda_obrien 6y ago

I think we should try to encode types in a common notation and create a gobal package manager for them. Then get people to actually use the types and you'll get much closer to automating API connectivity. I think Tree Notation and a yet to be developed package manager based on distributed principles would be a good start.

keithwhor 6y ago
If you’re interested in this we should chat. Google and Facebook effectively pulled this off for the web (OpenGraph and Semantic Search), but it has yet to be done for APIs. FunctionScript has a basic type system that’s a superset of JSON but there should be an overarching semantic system to it all. Feel free to e-mail me, keith@ (company domain) and introduce yourself if you’d like to chat about it. :) https://github.com/FunctionScript/FunctionScript/ https://github.com/FunctionScript/FunctionScript/
- lambda_obrien 6y ago
  I think to truly get the interoperability you see in sci-fi you're gonna need to upend the large stack we currently build on and reconsider what we want to do with our software and computers. Adding APIs to everything is great for today's world, but all you're doing is gluing things together still. As we get less from physical chips, we'll have to get more efficient in computation, which means more standardized data formats from the start, less security concerns by using capabilities and a linked permissions system, remote computation rather than data retrieval, and things like that. I think you have to take a several pronged approach, because even then you can't solve a problem like this with tech alone, you need other things like education, collaboration, freedom, and protection from maligned interests. That's really hard to do, I think maybe SpaceX did something on a similar level for space and soon internet connections, but they don't have free and open tech due to profit motives, so it's not advancing the state of space tech overall, just the tech at SpaceX. Probably, you need a large nonprofit foundation with billions of dollars to just buy it's way into the market to get something grand like that adopted. I might email you, not sure I have the motivation for API building and chatting about APIs that you seem to, but I do like generalizing problems into the simplest forms.

wideareanetwork 6y ago

Is this an old post? I thought this happened about 10 years ago.

voiper1 6y ago

My issue with these no-code/low-code things is bootstrapping. I can work on code for free on my computer, and then host it for $5 on a VPS/month. With autocode or retool I'm now dealing with $20 or $10/user or lots more if I need any usage. That's not throw-away money anymore...

keithwhor 6y ago
:)
hazz99 6y ago
Assuming a single free development account, I'd happily pay $10 or $20 per additional user if it means I can find a concept with decent product-market fit. I can then build it more cheaply myself. Iteration speed is incredibly valuable. You often only need <10 users to get an idea about how useful your MVP is.
villgax 6y ago
Are you interested in something which lets you host the application out, once it's built, yet providing the option to host it on your behalf?
- voiper1 6y ago
  I'm not quite sure what you mean. Hosted option is great - it's just the free tier seems so limited to me. I get these guys want to make money - need to make money to support the service. As a "hacker" I want to mess around and try things, and these seem to cater to that... until you see the price.

cheriot 6y ago

> Railsification of SaaS > SaaSification of Rails > RubyGems of SaaS APIs If all you have is Rails, the world looks like a Rails analogy.

miki123211 6y ago

IMO the way we currently do APIs is backwards. APIs should offer a way to run your own code in a sandbox, close to where the data is. That way, you don't have to worry about fine-grained or coarse-grained requests. All clients make just one request, supplying the code needed to retrieve the data. Of course, the untrusted code should only be allowed to use a restricted interface, depending on the scopes/permissions. It would be even better if the code could be statically analyzed, to determine the best SQL queries to perform. This would require a pretty radical rethinking of our stacks, but would bring great benefits. APIs would be simpler to make, and webpages would load much faster. We could even give third parties access to very sensitive information, as long as their code would be constrained in what it could return. Think of a service that requires KYC/AML verification. Your government could give it access to all your private information, but allow the code to return a single true/false response to preserve privacy. Much better than the current method of sending ID scans everywhere and praying they never get leaked.

janekm 6y ago
What you are describing used to be called "mobile information agents" in the late 90s ;) Sandboxing technology wasn't really quite ready for that at the time time... (not sure if it really is now, though arguably WASM is closer than JVM was) https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.544.6649&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.54...
- HeyLaughingBoy 6y ago
  I completely forgot about information agent technology. It was supposed to be the Next Really Big Thing but seemed to fizzle out completely once the hype died down. Was it ever used for anything significant?
  - janekm 6y ago
    Nothing I’ve come across, though I feel one could make the case that many of the ideas live on in some shape (Web APIs, serverless/lambda, Etherium Solidity, Service oriented architectures...).

mtberatwork 6y ago

> In the 1990s we saw the mass industrialization of web development with PHP and Apache HTTP Server. This isn't really true. PHP4 wasn't released until 2000. Sure, OK, while there were people using PHP3 in the 90s, it wasn't nearly as ubiquitous to the point of "mass industrialization". PHP3 wasn't even much of a language to begin with and if anything, Java/J2EE was the stack used for "mass industrialization" (Java's role is still dominant in most domains today). Perl was also a much more popular scripting language at the time.

nickserv 6y ago
Completely agree. When I started un the late 90's and early 2000's, it was mainly CGI/Perl. PHP was seen as very amateurish, and Python didn't have the massive ecosystem it has now (Zope sucked). And that wasn't really industrialized, mainly lots of ad-hoc internal frameworks.
acdha 6y ago
ASP and ColdFusion, too. We had clients switch to PHP 3 because it was so much faster and less buggy (!) but that was definitely seen as a bit of a gamble.
keithwhor 6y ago
I had originally written this as a much longer piece — probably double the length — where I covered the history including CGI / Perl but edited for brevity. I never had experience with J2EE personally which is why it’s missing. I was 12 in the year 2000 and had just started web development — because of that PHP retains a sense of primacy in my mind. Forgive the bias :).
- minhaz23 6y ago
  would love to read the original piece if you had no objection to sharing
  - keithwhor 6y ago
    It's lost to the void of lack of version control on Medium. I'd consider writing a new piece in the future, will let you know when I get to it!

webmaven 6y ago

Other than nitpicking the terminology/analogies used, I find myself in broad agreement with this post, although I would have liked a bit more analysis (even just backward looking) in terms of the market dynamics (eg. why PaaS lost it's early momentum and we backslid to assembling custom platforms out of IaaS components and services, the cautionary tale that OpenStack presents to efforts like OpenAPI, etc.), but I understand why not revealing one's thoughts on strategy might be the smarter choice. OTOH, I really would have expected Heroku to be mentioned in the 'SaaSification of Rails' section (since Heroku is literally 'Rails as a Service'), if only to state that it wasn't the intended meaning of the phrase (although Heroku's add-on marketplace can be seen as a stab in that direction).

pas 6y ago
PaaS lost because big corps are usually complex. Heroku is not enough for them. AWS got big due to it providing the services/components/building-blocks for big corps. Why talk only about big corps? Because that's where the money is unfortunately.