8 ms·

Treeline (YC W15) Wants to Take the Coding Out of Building a Back End

62 points by particlebanana 12y ago

idealboy 12y ago
As a front end dev, this is a game changer. So pumped.
- orthoganol 12y ago
  Suspicious account, a little...
particlebanana 12y ago
co-founder here if anyone has any questions
- ernestipark 12y ago
  This looks great! I can imagine this lowering the barrier for building a quick side project significantly. I have a FT job so working outside of that stack means I have to spend a lot of time figuring out configs and other non-business logic related work. Now a question - say I have a Treeline app that works great for a little side project. But eventually the project grows really big, both in traffic and scope. Is there a way to get off of Treeline (export code?) or do you think Treeline can scale well in this case.
  - mikermcneil 12y ago
    Great question :) code is recompiled in realtime as a node app you can deploy anywhere.
    - ernestipark 12y ago
      Also just as a note, I would shorten that demo video by just skipping over that Twilio setup part.
  - particlebanana 12y ago
    You can take the code right now and download it and deploy it to any infrastructure provider you want! We provide a command line tool to sync code down and work locally or to package up and deploy.
  - sgress454 12y ago
    Treeline compiles your apps to Node.js apps using the SailsJS framework. Your code is available to you at any time via a command-line tool--we offer the hosted version as an added bonus.
- incomethax 12y ago
  Can you handle apps with background tasks? In my experience, the backend systems basically end up being a large repository of jobs that need to get backgrounded, and handed off to other systems. I would be even more excited if you could find some way to create and manage those effectively.
  - mikermcneil 12y ago
    Machines can be triggered via kue, cron, or any other process of your choice (since they're effectively just augmented JavaScript functions)
- fillskills 12y ago
  Would love to see it integrated with a front end building platform like Webflow. I just built a quick site with Webflow, but because it lacks any integration with DB/Backend it was only used as a landing page. Having this ability would let users create and end to end web product with only basic knowledge of programming.
  - mikermcneil 12y ago
    Cool idea, will check it out!
bottled_poe 12y ago
I've always thought building a web service is the easy bit. In my experience, back end systems fit more closely with a conceptual model than the front end. As soon as things get to the user interface, you have to deal with real world problems, unexpected workflows, interactions, user expectations, variety of platform specifics, etc. To me, UI implementation seems so much harder.
- mikermcneil 12y ago
  Agreed- the frontend is where the magic really happens. Our goal is to arm developers like us with a clean, transparent, and secure abstraction layer so we can focus on building awesome user experiences.
- sgress454 12y ago
  We're essentially in agreement--backend development should be the easy part, but it often ends up being needlessly complicated and broken. So many backend systems are made up of the same basic components, but they end up being rewritten all the time because they don't work well together or are poorly documented. Treeline aims to make that 80% of your app that's always the same and basically automate it for you, leaving you to focus on the creative part (the special sauce that makes your app great).
  - findjashua 12y ago
    I laud the effort of making it easier to build apps, but in my experience the backend stuff is mostly building the rest api and cron jobs, which are relatively straightforward. Imho, bulk of the complexity is in user interfaces with lots of moving parts.
    - mikermcneil 12y ago
      You're absolutely right. Which is why we should make the backend even easier :)
    - jmspring 12y ago
      Reading this, I am curious about the systems you've dealt with? If you are talking the back end basically being crud apps, sure, but most services, the bulk of the work is behind the scenese (rest apiece, etc)
arihant 12y ago
I think this service should have one-click deploy to other Node.js platforms, at least Heroku, Beanstalk and Bluemix. I have a feeling that their concept would be most useful on ipad/mobile. But for that to be useful there needs to be very easy deployment options that work with my hosting of choice. I mean, imagine finding a bug, being able to fix it on your phone, and deploying it immediately. If it works that way, I'm sold. Also, if this is aimed towards frontend devs primarily, then it should be noted that it is unlikely that a frontend dev would struggle with writing JS on Node. They are more likely to dislike the deployment.
- particlebanana 12y ago
  The one-click deploy to heroku button is in the works.
- sgress454 12y ago
  > They are more likely to dislike the deployment. Deployment is the worst, for everybody. We're definitely excited about the possibilities there--done right, you could wire up your app in Treeline and set it live without your feet ever touching the ground (or muck, as it were.)
- mikermcneil 12y ago
  Deployment system relies on sails deploy- Microsoft actually just contributed an open source deploy strategy for azure and Heroku expressed interest in contributing to theirs. AWS has also been very helpful. Will keep everyone updated as things progress.
hackerews 12y ago
How do we try it out? I've been in beta list for a few days! :)
- particlebanana 12y ago
  We are working on getting everyone in tonight or tomorrow!
- mikermcneil 12y ago
  Thanks for your patience! Working on it as fast as we can.
salimmadjd 12y ago
This looks very very cool. But, who is the target audience here? IMHO, this doesn't have the best Product/Market fit. I'm guessing the target is a non-programmer or just front-end guy who quickly wants to put together a backend. If that's the target, then why not provide a set of generic backend functions. For the mentioned target. I think you can limited to a simple set like: registration, authentication, user profile, follow (friend), add content (text, image, video), like, list content, list all liked, list friends, etc. This way you can become "Wufoo for backend".
- mikermcneil 12y ago
  Great question! Open source drag and drop functionality currently exists for things like sending emails (via mailgun or mandrill) payments (via stripe) sending SMS (via Twilio) social auth (via twitter, Facebook, or github) password encryption (via bcrypt) analytics (via segment.com) and over 100 other common functions
  - mbesto 12y ago
    But who is the target audience?
- capex 12y ago
  There's [0]hull.io, doing a lot of the things you've mentioned here. [0] http://hull.io http://hull.io
  - salimmadjd 12y ago
    Another person suggested, http://stamplay.com/ http://stamplay.com/
knappador 12y ago
How to know if you might be a customer: Did you make a mockup that needs a backend but have little backend coding experience and are sick of including a bunch of the same libraries? If yes, maybe. In short, they're integrating some commonly used API's and backend programs (Elastic Search etc) and putting a graphical programming model on top of it. Crappy backends are pretty easy to throw up on a VPS or Heroku these days. It's so easy that I'm likely to select an app server(s) and language based on what library (if any) is most critical to that particular request type. At first I wasn't sure who the target customer could possibly be. Was it a PaaS service? BackendaaS? A service like this lives in a weird space. It's almost only good for early product dev and when the team's backend devs are green. Things like having unit tests, scale, completely custom capability etc will drive everyone who makes a successful product out at the very time that they can start to afford paying a lot. Don't burn all your money yet ;-D
- mikermcneil 12y ago
  Definitely don't burn any money until you try the thing out :)
- sgress454 12y ago
  It's true that when this has been tried in the past, there's always been a point where the "magic" ends--where there's some functionality that you need which isn't included. Treeline is different because you can always create new components when you need them. The Machine specification (http://node-machine.org http://node-machine.org) is open-source, and you can upload new machinepacks to NPM (Treeline imports them automatically), or create them from right within the app. So the magic never has to end :) Or as PG put it, "You get to make your own blocks!"
  - knappador 12y ago
    I'd bump that point and the integration with API's way up in the site copy. My first thought as an engineer when I see graphical programming tools is, "oooh...another one of those." It's the most controversial selling point. If I know I can do 90% of my backend work fast enough to slap an MVP together, the tradeoff might make sense. My default plan is a VPS with Flask or some other cheapo web app server that can pull 300req/s. That's a step beyond just using Heroku, but also a valid competitive option. How would you position your product relative to Heroku in terms of power and how much schlep you trade for how much ease-of-use? I think it's very okay to be clear for now in order to convert well with your core customers.
practicalpants 12y ago
Yep, I have something vaguely similar to this which I've built over the years for my own projects, essentially generators for boilerplate for back end stuff, written with preferred libraries, coding styles, testing approaches, etc. From who I know, I think it's common for back end devs. Yet I've never really built 'a simple' app... It does always requires substantial time tweaking, customizing, and building things that just can't be automatically generated. I can't imagine for anything that's not just dead simple that you could take the generators all the way. But I see you're targeting front end folks, which makes sense. If they have simple use cases this could work nicely for them.
- mikermcneil 12y ago
  After building one of the largest backend frameworks for Node.js I completely understand where you're coming from. It's taken us a very long time to solve this problem, and I can say with complete intellectual honesty that I believe we've solved it. Check out http://michaelmcneil.com/post/112978579967/mikermcneil-outcome-oriented-programming-md http://michaelmcneil.com/post/112978579967/mikermcneil-outco... for a more technical explanation of how the compiler works.
lazyseq 12y ago
I don't normally comment here, but I'll bite on this one. ;tldr - I find the goal and customers here confusing, questionable, and not well thought-out. Additionally I find the founders insulting and naive in the article. I still don't get who is the current and future customer even after reading the other posts here and other available material. I fail to see line of business users writing anything in this as it is too complicated for them and too close to programming. I cannot see an experienced dev introducing this in a stack and investing the time in learning the tool/libraries, building a system visually (super slow), and tying themselves to a 3rd party unknown start-up this tightly. As for the indie developers mentioned in the article who cannot build a scalable back-end, who are these people? Why are they developing apps? Maybe I am a grouching aging developer, but I really don't understand who these people are - "Indie developers comfortable building the user-facing side of an app themselves, but who would need assistance to build out a scalable backend." I would argue that if you believe you are a person who builds apps, you should be capable of actually building the app you are building. Beyond that, you are just another person with an idea, which in our world means absolutely nothing. While I can see how people can build a prototype not knowing exactly what they are doing and become successful, the keyword here is prototype. A prototype doesn't usually need to be scalable. If you want and need scalability, you need to build something carefully which matches your app's use cases and real-world usage. This is a difficult problem and not one that can be solved by plugging in anything and waiving a wand. Listen, I've worked as a developer since the late 80s, consultant since the 90s, spent many years at Microsoft, and worked for a few startups. I suppose I am one of those weird people who doesn't care about the tools, language, whatever, just give me the task and I will find the best tools to do it, and learn them in hours if I must to get the job done so I am open to anything to help, but this app makes me feel like I live in the Twilight Zone. I have seen this exact product in some shape or form so many times whether it was Visual XXX or ABC Builder or even some layer on a product like SharePoint, Dynamics CRM, Wordpress, whatever. The closest tools that have had at least practical success I've seen have been Excel and Hypercard. My hats off to you if you can make it work, but really I have my doubts. There is nothing written so far that is convincing me or more importantly, that would convince any of my previous customers (including private, government, and start-ups) to use this. And I assure you that my past customers would like nothing more than to take shortcuts, not pay for my hours, and/or find some way to in-house many development tasks. There are just so many things wrong here I don't know where to start. I'm not saying this to be mean, but rather I am genuinely curious who would use this and why. On top of this, you have tons of related competition, and hype around everything from Wolfram Language to Eden in this space if we broaden the scope to visual builders in general. I think it's a bit telling that one of the first comments is, "Treeline is different." I am pretty sure everyone who builds a product like this says exactly this, including my former colleagues who built real, very large, and even well-selling products. I have never seen any product genuinely succeed in its goal here, at best these products just sold the sucker's line and did not retain their customers long-term. Alternatively, these products succeeded in something else, but failed in the "app" or "back-end" builder category.
imaginenore 12y ago
Yahoo Pipes 2.0?
naiv 12y ago
Is this for free? i cant find pricing information
- mikermcneil 12y ago
  Free for open source- still working out pricing for private projects, but will be affordable for indie devs. Basically it will be something I could have afforded back in 2010 when I was in school.

idealboy 12y ago

As a front end dev, this is a game changer. So pumped.

orthoganol 12y ago
Suspicious account, a little...

particlebanana 12y ago

co-founder here if anyone has any questions

ernestipark 12y ago
This looks great! I can imagine this lowering the barrier for building a quick side project significantly. I have a FT job so working outside of that stack means I have to spend a lot of time figuring out configs and other non-business logic related work. Now a question - say I have a Treeline app that works great for a little side project. But eventually the project grows really big, both in traffic and scope. Is there a way to get off of Treeline (export code?) or do you think Treeline can scale well in this case.
- mikermcneil 12y ago
  Great question :) code is recompiled in realtime as a node app you can deploy anywhere.
  - ernestipark 12y ago
    Also just as a note, I would shorten that demo video by just skipping over that Twilio setup part.
- particlebanana 12y ago
  You can take the code right now and download it and deploy it to any infrastructure provider you want! We provide a command line tool to sync code down and work locally or to package up and deploy.
- sgress454 12y ago
  Treeline compiles your apps to Node.js apps using the SailsJS framework. Your code is available to you at any time via a command-line tool--we offer the hosted version as an added bonus.
incomethax 12y ago
Can you handle apps with background tasks? In my experience, the backend systems basically end up being a large repository of jobs that need to get backgrounded, and handed off to other systems. I would be even more excited if you could find some way to create and manage those effectively.
- mikermcneil 12y ago
  Machines can be triggered via kue, cron, or any other process of your choice (since they're effectively just augmented JavaScript functions)
fillskills 12y ago
Would love to see it integrated with a front end building platform like Webflow. I just built a quick site with Webflow, but because it lacks any integration with DB/Backend it was only used as a landing page. Having this ability would let users create and end to end web product with only basic knowledge of programming.
- mikermcneil 12y ago
  Cool idea, will check it out!

bottled_poe 12y ago

I've always thought building a web service is the easy bit. In my experience, back end systems fit more closely with a conceptual model than the front end. As soon as things get to the user interface, you have to deal with real world problems, unexpected workflows, interactions, user expectations, variety of platform specifics, etc. To me, UI implementation seems so much harder.

mikermcneil 12y ago
Agreed- the frontend is where the magic really happens. Our goal is to arm developers like us with a clean, transparent, and secure abstraction layer so we can focus on building awesome user experiences.
sgress454 12y ago
We're essentially in agreement--backend development should be the easy part, but it often ends up being needlessly complicated and broken. So many backend systems are made up of the same basic components, but they end up being rewritten all the time because they don't work well together or are poorly documented. Treeline aims to make that 80% of your app that's always the same and basically automate it for you, leaving you to focus on the creative part (the special sauce that makes your app great).
- findjashua 12y ago
  I laud the effort of making it easier to build apps, but in my experience the backend stuff is mostly building the rest api and cron jobs, which are relatively straightforward. Imho, bulk of the complexity is in user interfaces with lots of moving parts.
  - mikermcneil 12y ago
    You're absolutely right. Which is why we should make the backend even easier :)
  - jmspring 12y ago
    Reading this, I am curious about the systems you've dealt with? If you are talking the back end basically being crud apps, sure, but most services, the bulk of the work is behind the scenese (rest apiece, etc)

arihant 12y ago

I think this service should have one-click deploy to other Node.js platforms, at least Heroku, Beanstalk and Bluemix. I have a feeling that their concept would be most useful on ipad/mobile. But for that to be useful there needs to be very easy deployment options that work with my hosting of choice. I mean, imagine finding a bug, being able to fix it on your phone, and deploying it immediately. If it works that way, I'm sold. Also, if this is aimed towards frontend devs primarily, then it should be noted that it is unlikely that a frontend dev would struggle with writing JS on Node. They are more likely to dislike the deployment.

particlebanana 12y ago
The one-click deploy to heroku button is in the works.
sgress454 12y ago
> They are more likely to dislike the deployment. Deployment is the worst, for everybody. We're definitely excited about the possibilities there--done right, you could wire up your app in Treeline and set it live without your feet ever touching the ground (or muck, as it were.)
mikermcneil 12y ago
Deployment system relies on sails deploy- Microsoft actually just contributed an open source deploy strategy for azure and Heroku expressed interest in contributing to theirs. AWS has also been very helpful. Will keep everyone updated as things progress.

hackerews 12y ago

How do we try it out? I've been in beta list for a few days! :)

particlebanana 12y ago
We are working on getting everyone in tonight or tomorrow!
mikermcneil 12y ago
Thanks for your patience! Working on it as fast as we can.

salimmadjd 12y ago

This looks very very cool. But, who is the target audience here? IMHO, this doesn't have the best Product/Market fit. I'm guessing the target is a non-programmer or just front-end guy who quickly wants to put together a backend. If that's the target, then why not provide a set of generic backend functions. For the mentioned target. I think you can limited to a simple set like: registration, authentication, user profile, follow (friend), add content (text, image, video), like, list content, list all liked, list friends, etc. This way you can become "Wufoo for backend".

mikermcneil 12y ago
Great question! Open source drag and drop functionality currently exists for things like sending emails (via mailgun or mandrill) payments (via stripe) sending SMS (via Twilio) social auth (via twitter, Facebook, or github) password encryption (via bcrypt) analytics (via segment.com) and over 100 other common functions
- mbesto 12y ago
  But who is the target audience?
capex 12y ago
There's [0]hull.io, doing a lot of the things you've mentioned here. [0] http://hull.io http://hull.io
- salimmadjd 12y ago
  Another person suggested, http://stamplay.com/ http://stamplay.com/

knappador 12y ago

How to know if you might be a customer: Did you make a mockup that needs a backend but have little backend coding experience and are sick of including a bunch of the same libraries? If yes, maybe. In short, they're integrating some commonly used API's and backend programs (Elastic Search etc) and putting a graphical programming model on top of it. Crappy backends are pretty easy to throw up on a VPS or Heroku these days. It's so easy that I'm likely to select an app server(s) and language based on what library (if any) is most critical to that particular request type. At first I wasn't sure who the target customer could possibly be. Was it a PaaS service? BackendaaS? A service like this lives in a weird space. It's almost only good for early product dev and when the team's backend devs are green. Things like having unit tests, scale, completely custom capability etc will drive everyone who makes a successful product out at the very time that they can start to afford paying a lot. Don't burn all your money yet ;-D

mikermcneil 12y ago
Definitely don't burn any money until you try the thing out :)
sgress454 12y ago
It's true that when this has been tried in the past, there's always been a point where the "magic" ends--where there's some functionality that you need which isn't included. Treeline is different because you can always create new components when you need them. The Machine specification (http://node-machine.org http://node-machine.org) is open-source, and you can upload new machinepacks to NPM (Treeline imports them automatically), or create them from right within the app. So the magic never has to end :) Or as PG put it, "You get to make your own blocks!"
- knappador 12y ago
  I'd bump that point and the integration with API's way up in the site copy. My first thought as an engineer when I see graphical programming tools is, "oooh...another one of those." It's the most controversial selling point. If I know I can do 90% of my backend work fast enough to slap an MVP together, the tradeoff might make sense. My default plan is a VPS with Flask or some other cheapo web app server that can pull 300req/s. That's a step beyond just using Heroku, but also a valid competitive option. How would you position your product relative to Heroku in terms of power and how much schlep you trade for how much ease-of-use? I think it's very okay to be clear for now in order to convert well with your core customers.

practicalpants 12y ago

Yep, I have something vaguely similar to this which I've built over the years for my own projects, essentially generators for boilerplate for back end stuff, written with preferred libraries, coding styles, testing approaches, etc. From who I know, I think it's common for back end devs. Yet I've never really built 'a simple' app... It does always requires substantial time tweaking, customizing, and building things that just can't be automatically generated. I can't imagine for anything that's not just dead simple that you could take the generators all the way. But I see you're targeting front end folks, which makes sense. If they have simple use cases this could work nicely for them.

mikermcneil 12y ago
After building one of the largest backend frameworks for Node.js I completely understand where you're coming from. It's taken us a very long time to solve this problem, and I can say with complete intellectual honesty that I believe we've solved it. Check out http://michaelmcneil.com/post/112978579967/mikermcneil-outcome-oriented-programming-md http://michaelmcneil.com/post/112978579967/mikermcneil-outco... for a more technical explanation of how the compiler works.

lazyseq 12y ago

I don't normally comment here, but I'll bite on this one. ;tldr - I find the goal and customers here confusing, questionable, and not well thought-out. Additionally I find the founders insulting and naive in the article. I still don't get who is the current and future customer even after reading the other posts here and other available material. I fail to see line of business users writing anything in this as it is too complicated for them and too close to programming. I cannot see an experienced dev introducing this in a stack and investing the time in learning the tool/libraries, building a system visually (super slow), and tying themselves to a 3rd party unknown start-up this tightly. As for the indie developers mentioned in the article who cannot build a scalable back-end, who are these people? Why are they developing apps? Maybe I am a grouching aging developer, but I really don't understand who these people are - "Indie developers comfortable building the user-facing side of an app themselves, but who would need assistance to build out a scalable backend." I would argue that if you believe you are a person who builds apps, you should be capable of actually building the app you are building. Beyond that, you are just another person with an idea, which in our world means absolutely nothing. While I can see how people can build a prototype not knowing exactly what they are doing and become successful, the keyword here is prototype. A prototype doesn't usually need to be scalable. If you want and need scalability, you need to build something carefully which matches your app's use cases and real-world usage. This is a difficult problem and not one that can be solved by plugging in anything and waiving a wand. Listen, I've worked as a developer since the late 80s, consultant since the 90s, spent many years at Microsoft, and worked for a few startups. I suppose I am one of those weird people who doesn't care about the tools, language, whatever, just give me the task and I will find the best tools to do it, and learn them in hours if I must to get the job done so I am open to anything to help, but this app makes me feel like I live in the Twilight Zone. I have seen this exact product in some shape or form so many times whether it was Visual XXX or ABC Builder or even some layer on a product like SharePoint, Dynamics CRM, Wordpress, whatever. The closest tools that have had at least practical success I've seen have been Excel and Hypercard. My hats off to you if you can make it work, but really I have my doubts. There is nothing written so far that is convincing me or more importantly, that would convince any of my previous customers (including private, government, and start-ups) to use this. And I assure you that my past customers would like nothing more than to take shortcuts, not pay for my hours, and/or find some way to in-house many development tasks. There are just so many things wrong here I don't know where to start. I'm not saying this to be mean, but rather I am genuinely curious who would use this and why. On top of this, you have tons of related competition, and hype around everything from Wolfram Language to Eden in this space if we broaden the scope to visual builders in general. I think it's a bit telling that one of the first comments is, "Treeline is different." I am pretty sure everyone who builds a product like this says exactly this, including my former colleagues who built real, very large, and even well-selling products. I have never seen any product genuinely succeed in its goal here, at best these products just sold the sucker's line and did not retain their customers long-term. Alternatively, these products succeeded in something else, but failed in the "app" or "back-end" builder category.

imaginenore 12y ago

Yahoo Pipes 2.0?

naiv 12y ago

Is this for free? i cant find pricing information

mikermcneil 12y ago
Free for open source- still working out pricing for private projects, but will be affordable for indie devs. Basically it will be something I could have afforded back in 2010 when I was in school.