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.
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.
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.
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.
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.
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.
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.
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).
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.
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)
outside the rest api, mostly crawling 3rd party apis, basic map-reduce aggregations, data sanity checks, the occasional s3 dump. No fancy distributed systems or machine learning stuff everyone else seems to be doing. How about yourself?
It's trivial if your app is just CRUD with domain specific fields, but there can still be some tricky parts;
* Sync'ing data between the frontend and backend if your app has any sort of offline capabilities. Conflict resolution is hard if you want anything better than just a dumb overwrite of what's there.
* Data munging for anything that isn't coming from a well defined API is a horrible and difficult task.
* Scaling and replication on a global scale is still a challenge. It doesn't affect many apps though.
You can knock up a decent REST API in Laravel/Express/Django/whatever in a few hours, but getting the data that you push through it still represents some fun and challenging aspects of app development.
Agree, those are all challenging problems to solve, but I haven't had the chance to work on them
1. we don't support offline mode in our app. Though, quite a few databases have a version number in their documents (es, couch etc), so the user can be shown conflicts if the server responds with a version mismatch
2. Luckily, I haven't had to work with any overly terrible APIs. The documentation is usually bad, but fiddling around with the req params/body usually gets me what I want
3. We're selling to businesses, so our traffic isn't at that scale.
I build whole systems, and have had specialized jobs ranging from 3D game programming to Machine Learning to Rapid Web App Dev. I've observed many the opposite. I would agree that interfaces have lots of moving parts, but part of what you try to do there is to reduce the complexity because it often means you are passing on too much to the user. I suppose there's a bit of Apple philossphy there.
Just cron jobs and REST APIs? Regarding cron jobs, we generally try to avoid them because communicating with them, getting good information, maintaining, and so on sucks. While I've written tons of cron jobs and still do, it's probably 1% of what I've observed happening in the back-end and usually a sign of a duct-taped system. This excludes baked-in unix tools that are actually supposed to work that way of course, rather I am talking things directly involving apps I build. As for REST API, not everything needs to be or should be REST. It introduces all kinds of extra layers of auth, slowdown, caching issues, and so on. For some domains, REST is a bad idea. Of course we use it where it makes sense, but it's not just some magic thing that is and should be used everywhere and anywhere to be representative of the bulk of back-end. Most REST services are built very quickly, it's rather the logic behind them that takes a long time.
As for concrete things I've encountered that are actually complex and happen in traditionally the back-end, I'd say none of these are straight-forward:
1. Caching - As it goes, other than naming, this is one of the most difficult things in computer science and happens everywhere in a good application, front, back, let, right, data, service, whatever.
2. Machine Learning, Sentiment Analysis, Analytics, OLAP, etc. - People forget that a big part of building a system is getting information back out of it.
3. Orchestration - this is hugely complicated. So much so, Microsoft created a very complicated and misunderstood product for it (BizTalk). Doing orchestration is still something no one gets. It happens in millions of forms and related manifestations.
4. Deployment - Versioning, machine provisioning, cluster management, and so on are all very complicated. There are tons of these things that fall under what many people call Dev Ops now too as well. I have yet to see magic here in any app. I challenge you to deploy a running system that is accepting live data transactions, then seamlessly roll it back without data loss, down time, corruption, weird states, unforseen bugs, and so on. No one has done this in full which is why this area is becoming increasingly full of solutions and start-ups. Whether it's Google App Engine, Azure, Heroku, your in-house AWS scripts, Chef, anything, I am telling you no one really does this 100% right. Supporting a real app is just as important as the app itself, and often the two have to communicate and be written in ways to make this work.
5. Streaming - Building streaming related back-ends is anything but simple and plug-and-play. No, I am not talking about streaming Tweets.
6. Data Migrations/Updates/Changes/Flow - Very important part of dev, and usually one of the top 5 time sinks. Complete nightmare and again products and libraries that help, but no magic bullets to be found here other than doing the work and putting in the time. As for simple cases, almost everyone deals with getting data in X form, transforming it to Y, and having it change form again after getting a reply from Z service. A huge part of people's time is simply manipulating data structures, at any place in the system and a reason why I tend to favor Clojure for web apps that don't need to be speed demons. As for migrations, ask someone to do one, then double or quadruple their estimate, sit back, and watch.
7. Authentication/Authorization - The world runs on more than just OAuth and Social Auth. Try dealing with people that have secure systems or many other systems that you need to communicate with, especially ...
Not trying to pick a fight, but again your team comes off as naive and essentially gives the middle-finger to probably the majority of the software developer community with comments like these. It seems like you guys simply have not worked on an actual complex system of any significant size or over-value the complexity of front-ends. I personally respect all facets that go into making software.
Anyway, I would argue there's no easy part and dividing things into monoliths at a conceptual-level is a mistake. Putting that aside, whatever part is comparatively (key-word) easier is highly dependent on the implementer. For instance if I build a system that just needs 1 input field, but then performs some sort of machine-learning or triggers some complex background dispatching, then that system is arguably much more complex on the "back-end." I think making big distinctions is a source of trouble to begin with and regardless I do about equal amounts of front and back-end work on my current start-up.
As for the special sauce, in many apps the special sauce is actually the back-end. I would agree everyone hates with dealing with 3rd party libs and so on, but the ways you deal with that information is important. I think the way Treeline is described in your website, this article, and video makes weird distinctions and conflations between what is front and back-end work and what are actual problems programmers actually have. I totally get the parts about plugging into another API and not having to write the fetch code, but honestly with a library or two or even implementing integrations with many libraries, the work is minimal. Adding the correct libraries is often an important choice.
To give you a concrete example, I do most of my current work in Clojure followed by Haskell, Java, and C. The choice of library authors doing things like using non-standard data structures that I then have to transform or directly consume, using/not using things like async channels, and so on from the ends of their APIs is a huge deal. It's not normally a problem to find a library that works with how you want to do things, but rather important that you pick the right one from the list of choices. If a Clojure library forces me to consume a core.async channel, I might not do it because I want to use something more general like a transducer to abstract that away.
Sometimes also the ways that I consume someone else's library are very unique to my app and provide a crucial difference aka special sauce. Consider for example that for years I had a client that had a huge advantage due to code my team created against some public APIs because we were able to stream, batch, and thread our interactions with this particular API in ways most people had not thought of or implemented. The fact that our integrations were based on self-calculated heuristics provided dramatic speed-ups over everyone else meant it looked like we could do things that would cause the client's competitors to think we had some special deal or wonder how it all worked. This is not unique to us, rather it is simply illustrative of the importance of optimizing your business activities in the back-end. Consider that most of wall-street high frequency trading as another example is based on this notion. While I am not claiming that everyone needs to do this, your generalization is the issue here.
It is funny because maybe our definitions of "back-end" are the issue. I tend to notice that the wheels on the front-end are invented time and again. How many different UI frameworks, patterns, controls, etc are there that get implemented from scratch? How many people end up composing their apps out of little more than paging, showing pictures, textboxes/checkboxes/pickers, form validation, css positioning, animation, and so on. I'd argue these are the actual repetitive bits that are tedious to write.
I am reminded of criticisms of forum software by the authors of discourse. They pointed out a lot of the special sauce things that...
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.
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.)
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.
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.
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
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.
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) 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!"
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.
We're not a production hosting platform--at least not at the moment. We do spin up a preview server for you to play around with your app while you build it in Treeline, but it's not meant to compete with Heroku or any such provider. Instead, we give you a way to download your project as a fully-formed SailsJS app which you can deploy anywhere that supports Node. You can also use the same tool to preview your app on your local computer while still keeping it synched up with Treeline in real time--hooray for sockets!
Okay, cool. Now that I've finished being uninformed enough to get questions out of the way, I'm guessing you chose Sails because it has some kind of JS DB for prototyping. I would spend time asking if Sails is the desired output format because, although I've only used it during a Startup Weekend fling, it feels like a framework, and don't forget that it's said that while you can plug your code into a library, in Soviet framework, code plugs into you -- I imagine that although a backend dev might be thinking, "Great, Node, kill me softly with 'undefined'" they would still kill if the implementation was really minimal with nothing in their way; if they like another JS framework or want to write a common backend for web and mobile apps, not having Sails' distractions in the way could be big for legitimately doing some of their work for them.
Another big feature would be doing the work to plug persistence into other DB's to make the output DB agnostic to some extent. Migrations would be the next step, but too much of a chore. All you need are to define data models for XYZ ORM/DB adapter to make the machine-generated step hit the right starting point for hand-off. If the ideal use case is in prototyping, I don't think migrations is in the right vein.
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.
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-outco... for a more technical explanation of how the compiler works.
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.
I really also have to question the attitude of the founders. I found a lot of the quotes out there about this product insulting. "Building the backend, however, is like stacking wine glasses: it’s not that hard, but if you make a mistake it’s a bigger issue to deal with." If building a back-end is not hard, then why do I need your product? It should just be easy as long as I test it and do a lot of checking to make sure the wine glasses don't fall. What makes me think that the founders of all people are the ones I should trust to make these decisions when the pitch for the product is insulting the people who actually build solid back-ends? I've built a lot of back-ends that people actually use and not once has it been an easy task. Even the jobs that took me less than a day I would never say were easy; perhaps I simply discovered humility and actually lived long enough to see what happens to systems 10+ years after they are used by real people.
I would also apply the above to front-ends - they are never just "easy." But front-ends you can mess up and fix them without too much catastrophe beyond perhaps annoyed/lost users/etc. When back-ends fail or are designed badly, we lose data, ability to gain insight into our business, can't satisfy company/client requirements, and so on. These are much more serious consequences than your app not being responsive or shiny, or looking like it came from a wannabe Craigslist fan. Both are important to success, but let's not pretend that our apps could be the next Google if we could only sweep away that pesky back-end. It seems on some level the founders agree here that back-ends going wrong are really a problem, but why does this start-up suddenly guarantee success here? Just the fact of using node.js + <insert db> does not make a back-end good. Using things the community generates also does not make something good. Back-ends are anything but one size fits all, or even one size fits more than a few people.
Producing a good back-end is actually very hard for anything beyond a prototype and an often misunderstood art form. I don't get this notion I see a lot that xyz programmer is a "front-end" developer and abc programmer is a "back-end" developer. You are not a developer at all if you can't learn anything you put the time and effort into I would argue. At best, you are a beginning programmer who knows a few libraries that are focused on one or more aspects of a system. In practice, you don't always get to work in jobs in all roles, but you still have to know about all of them to be an effective developer. I would never hire someone for my team beyond a junior-level that was not strong in all areas. There are of course specialists as well, but these are more for things like crypto/security, embedded programming, and so-on rather than your general application code. Simply put, if you can't learn front or back-end development to meet the requirements of your development tasks, you have no business doing them. As a corollary, it is important to know your strengths and hand-off to people who might be more artistic or more familiar with a language, but it does not absolve you of learning about the other parts of your system. So I also ask, what part of this protects a programmer who is inexperienced, clueless, or otherwise too busy to care about the back-end to not structure or combine otherwise solid parts (for the sake of argument) of this tool from creating a back-end that is a complete disaster because of the sum of its parts?
I think this app discounts the close relationship of a system as a whole between the front and back-end. A few things were mentioned already like syncing data offline, but I have additional concerns. Note for example that caching, data modeling, and asynchronous programming for example are all very closely related to both databases/working with data and building user interfaces. I cannot tell you how many times I have had to build little trick...
Washing clothes is not hard, but yet we still buy expensive washing machines to save us time. Please take a closer look- would love to hear your feedback after trying the platform out.
I understand where you're coming from, but I must respectfully disagree. However I'll say one more thing in defense of our users: modern front-end developers do data manipulation all the time. The data munging that's happening on the client is just as complicated and important as the coercion and marshaling on the backend. In many cases, the barrier preventing client-side developers from just doing the same thing is a different language, a lack of confidence, or organizational pressure and bullying.
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.
55 comments
[ 2.9 ms ] story [ 153 ms ] threadNow 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.
I would be even more excited if you could find some way to create and manage those effectively.
* Sync'ing data between the frontend and backend if your app has any sort of offline capabilities. Conflict resolution is hard if you want anything better than just a dumb overwrite of what's there.
* Data munging for anything that isn't coming from a well defined API is a horrible and difficult task.
* Scaling and replication on a global scale is still a challenge. It doesn't affect many apps though.
You can knock up a decent REST API in Laravel/Express/Django/whatever in a few hours, but getting the data that you push through it still represents some fun and challenging aspects of app development.
1. we don't support offline mode in our app. Though, quite a few databases have a version number in their documents (es, couch etc), so the user can be shown conflicts if the server responds with a version mismatch
2. Luckily, I haven't had to work with any overly terrible APIs. The documentation is usually bad, but fiddling around with the req params/body usually gets me what I want
3. We're selling to businesses, so our traffic isn't at that scale.
Just cron jobs and REST APIs? Regarding cron jobs, we generally try to avoid them because communicating with them, getting good information, maintaining, and so on sucks. While I've written tons of cron jobs and still do, it's probably 1% of what I've observed happening in the back-end and usually a sign of a duct-taped system. This excludes baked-in unix tools that are actually supposed to work that way of course, rather I am talking things directly involving apps I build. As for REST API, not everything needs to be or should be REST. It introduces all kinds of extra layers of auth, slowdown, caching issues, and so on. For some domains, REST is a bad idea. Of course we use it where it makes sense, but it's not just some magic thing that is and should be used everywhere and anywhere to be representative of the bulk of back-end. Most REST services are built very quickly, it's rather the logic behind them that takes a long time.
As for concrete things I've encountered that are actually complex and happen in traditionally the back-end, I'd say none of these are straight-forward:
1. Caching - As it goes, other than naming, this is one of the most difficult things in computer science and happens everywhere in a good application, front, back, let, right, data, service, whatever.
2. Machine Learning, Sentiment Analysis, Analytics, OLAP, etc. - People forget that a big part of building a system is getting information back out of it.
3. Orchestration - this is hugely complicated. So much so, Microsoft created a very complicated and misunderstood product for it (BizTalk). Doing orchestration is still something no one gets. It happens in millions of forms and related manifestations.
4. Deployment - Versioning, machine provisioning, cluster management, and so on are all very complicated. There are tons of these things that fall under what many people call Dev Ops now too as well. I have yet to see magic here in any app. I challenge you to deploy a running system that is accepting live data transactions, then seamlessly roll it back without data loss, down time, corruption, weird states, unforseen bugs, and so on. No one has done this in full which is why this area is becoming increasingly full of solutions and start-ups. Whether it's Google App Engine, Azure, Heroku, your in-house AWS scripts, Chef, anything, I am telling you no one really does this 100% right. Supporting a real app is just as important as the app itself, and often the two have to communicate and be written in ways to make this work.
5. Streaming - Building streaming related back-ends is anything but simple and plug-and-play. No, I am not talking about streaming Tweets.
6. Data Migrations/Updates/Changes/Flow - Very important part of dev, and usually one of the top 5 time sinks. Complete nightmare and again products and libraries that help, but no magic bullets to be found here other than doing the work and putting in the time. As for simple cases, almost everyone deals with getting data in X form, transforming it to Y, and having it change form again after getting a reply from Z service. A huge part of people's time is simply manipulating data structures, at any place in the system and a reason why I tend to favor Clojure for web apps that don't need to be speed demons. As for migrations, ask someone to do one, then double or quadruple their estimate, sit back, and watch.
7. Authentication/Authorization - The world runs on more than just OAuth and Social Auth. Try dealing with people that have secure systems or many other systems that you need to communicate with, especially ...
Anyway, I would argue there's no easy part and dividing things into monoliths at a conceptual-level is a mistake. Putting that aside, whatever part is comparatively (key-word) easier is highly dependent on the implementer. For instance if I build a system that just needs 1 input field, but then performs some sort of machine-learning or triggers some complex background dispatching, then that system is arguably much more complex on the "back-end." I think making big distinctions is a source of trouble to begin with and regardless I do about equal amounts of front and back-end work on my current start-up.
As for the special sauce, in many apps the special sauce is actually the back-end. I would agree everyone hates with dealing with 3rd party libs and so on, but the ways you deal with that information is important. I think the way Treeline is described in your website, this article, and video makes weird distinctions and conflations between what is front and back-end work and what are actual problems programmers actually have. I totally get the parts about plugging into another API and not having to write the fetch code, but honestly with a library or two or even implementing integrations with many libraries, the work is minimal. Adding the correct libraries is often an important choice.
To give you a concrete example, I do most of my current work in Clojure followed by Haskell, Java, and C. The choice of library authors doing things like using non-standard data structures that I then have to transform or directly consume, using/not using things like async channels, and so on from the ends of their APIs is a huge deal. It's not normally a problem to find a library that works with how you want to do things, but rather important that you pick the right one from the list of choices. If a Clojure library forces me to consume a core.async channel, I might not do it because I want to use something more general like a transducer to abstract that away.
Sometimes also the ways that I consume someone else's library are very unique to my app and provide a crucial difference aka special sauce. Consider for example that for years I had a client that had a huge advantage due to code my team created against some public APIs because we were able to stream, batch, and thread our interactions with this particular API in ways most people had not thought of or implemented. The fact that our integrations were based on self-calculated heuristics provided dramatic speed-ups over everyone else meant it looked like we could do things that would cause the client's competitors to think we had some special deal or wonder how it all worked. This is not unique to us, rather it is simply illustrative of the importance of optimizing your business activities in the back-end. Consider that most of wall-street high frequency trading as another example is based on this notion. While I am not claiming that everyone needs to do this, your generalization is the issue here.
It is funny because maybe our definitions of "back-end" are the issue. I tend to notice that the wheels on the front-end are invented time and again. How many different UI frameworks, patterns, controls, etc are there that get implemented from scratch? How many people end up composing their apps out of little more than paging, showing pictures, textboxes/checkboxes/pickers, form validation, css positioning, animation, and so on. I'd argue these are the actual repetitive bits that are tedious to write.
I am reminded of criticisms of forum software by the authors of discourse. They pointed out a lot of the special sauce things that...
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.
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.)
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".
[0] http://hull.io
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
Or as PG put it, "You get to make your own blocks!"
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.
Another big feature would be doing the work to plug persistence into other DB's to make the output DB agnostic to some extent. Migrations would be the next step, but too much of a chore. All you need are to define data models for XYZ ORM/DB adapter to make the machine-generated step hit the right starting point for hand-off. If the ideal use case is in prototyping, I don't think migrations is in the right vein.
Armchair-CTO, signing off.
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.
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.
I would also apply the above to front-ends - they are never just "easy." But front-ends you can mess up and fix them without too much catastrophe beyond perhaps annoyed/lost users/etc. When back-ends fail or are designed badly, we lose data, ability to gain insight into our business, can't satisfy company/client requirements, and so on. These are much more serious consequences than your app not being responsive or shiny, or looking like it came from a wannabe Craigslist fan. Both are important to success, but let's not pretend that our apps could be the next Google if we could only sweep away that pesky back-end. It seems on some level the founders agree here that back-ends going wrong are really a problem, but why does this start-up suddenly guarantee success here? Just the fact of using node.js + <insert db> does not make a back-end good. Using things the community generates also does not make something good. Back-ends are anything but one size fits all, or even one size fits more than a few people.
Producing a good back-end is actually very hard for anything beyond a prototype and an often misunderstood art form. I don't get this notion I see a lot that xyz programmer is a "front-end" developer and abc programmer is a "back-end" developer. You are not a developer at all if you can't learn anything you put the time and effort into I would argue. At best, you are a beginning programmer who knows a few libraries that are focused on one or more aspects of a system. In practice, you don't always get to work in jobs in all roles, but you still have to know about all of them to be an effective developer. I would never hire someone for my team beyond a junior-level that was not strong in all areas. There are of course specialists as well, but these are more for things like crypto/security, embedded programming, and so-on rather than your general application code. Simply put, if you can't learn front or back-end development to meet the requirements of your development tasks, you have no business doing them. As a corollary, it is important to know your strengths and hand-off to people who might be more artistic or more familiar with a language, but it does not absolve you of learning about the other parts of your system. So I also ask, what part of this protects a programmer who is inexperienced, clueless, or otherwise too busy to care about the back-end to not structure or combine otherwise solid parts (for the sake of argument) of this tool from creating a back-end that is a complete disaster because of the sum of its parts?
I think this app discounts the close relationship of a system as a whole between the front and back-end. A few things were mentioned already like syncing data offline, but I have additional concerns. Note for example that caching, data modeling, and asynchronous programming for example are all very closely related to both databases/working with data and building user interfaces. I cannot tell you how many times I have had to build little trick...
Can you please elaborate?
Let's see what they can do :)
Lol you didn't read his comment at all.