5 ms·

NoBackend: Front-End First Web Development

37 points by aespinoza 13y ago

intellection 13y ago
http://nobackend.org http://nobackend.org http://nobackend.org/dreamcode http://nobackend.org/dreamcode Interesting gists of ideal code: - user accounts / authentication https://gist.github.com/gr2m/5463426 https://gist.github.com/gr2m/5463426 - data persistence https://gist.github.com/gr2m/5463475 https://gist.github.com/gr2m/5463475 - data sharing https://gist.github.com/gr2m/5463525 https://gist.github.com/gr2m/5463525 - emails https://gist.github.com/gr2m/5463552 https://gist.github.com/gr2m/5463552 - file conversion https://gist.github.com/gr2m/5463605 https://gist.github.com/gr2m/5463605 - payments https://gist.github.com/gr2m/5463675 https://gist.github.com/gr2m/5463675 http://nobackend.org/examples http://nobackend.org/examples - http://css-tricks.com/editable-invoice-v2/ http://css-tricks.com/editable-invoice-v2/ - http://gr2m.github.io/EditableInvoice/ http://gr2m.github.io/EditableInvoice/ http://nobackend.org/solutions http://nobackend.org/solutions < known live projects
onemorepassword 13y ago
> It's a different approach that especially fits applications that hold most of its logic in the frontend, where the user experience is the most important feature. This is the part I have a bit of an issue with when it comes to all the hype about front-end development. I've been involved in web development since 1994, and software development since the 80's. I've so very, very rarely encountered applications to which this applies. When I mention this, people come up with examples like GMail or Twitter, obviously not understanding the the front-end part, however impressive in the case of GMail, is just that: a front-end, a client for an application so much more complex. I sometimes feel front-end experts have no idea about what happens on the back-end. All those API-calls are not being handle by some magic genie. Or maybe I'm wrong and I've missed something essential.
- ryanSrich 13y ago
  > All those API-calls are not being handle by some magic genie But they're there. You implement what they do on the front-end. Think of any application you interact with on a daily basis. The tasks are very front-end oriented. I can only think of a handful of applications I use that have a robust backend for an apparent logical reason (image recognition and pdf parsing). Most of what we do on the web can and will be handled on the front-end.
- asolove 13y ago
  I think that your point of view is actually a really good reason for front-end-first development. As a front-end developer, I accept that the back-end portion of modeling, storing, and scaling the data is a much harder (or at least much different and very hard to me) task that generally requires much more investment before you get much useful feedback. So when working on a new product, it's worthwhile to build as much of a facade interface as you can to quickly and cheaply explore how it feels to use the product. Then you can iterate rapidly with something concrete in front of your stakeholders, and when they're happy, you can just build the back-end once, from a solid foundation of domain knowledge. It also works out well socially. Some people (who tend to congregate in front-end) work well with vague ideas about a user experience and instructions to explore the product on their own. Others (who congregate in back-end these days) want firmer ideas about the product and usage so that they can exercise their creativity in solving the technical problem well. Front-end-first is a great way to let everyone do the part of the job that they like.
  - onemorepassword 13y ago
    The word you're looking for is "prototyping". I'm not being sarcastic (well, okay, a little), I pretty much agree with most of what you wrote (of course depending on the project at hand), except the notion that this is something new. Also, just working on the front-end/user experience doesn't give you, and certainly not the back-end developers, a "solid foundation of domain knowledge". That only happens if they are deeply involved in the same process, and front-end-first suggests exactly the opposite. A front-end, no matter how wonderful and detailed, is still way to vague to serve as specs unless the application is very simple.
    - sanderjd 13y ago
      What separates this idea from prototyping in my view is that they are suggesting keeping the "prototyped" UI as the real deal and then building a back-end to support it, rather than re-building the front-end along with the back-end. The back-end is developed using all of the well-documented places where the front-end needs support as a spec.
  - 13y ago
- saraid216 13y ago
  Is this about you not getting the credit you deserve, or is it about building the best application possible?
legedemon 13y ago
I have some validation finally. I have called this approach frontend-first and have evangelized it internally in my teams. But NoBackend is, catchy. Basically, I rally my team to build up as much functionality as they possibly can w/o writing any server side code and demo it to the stakeholders and have their final confirmation before starting to write anything on the server. The demo at this point pretty much resembles the live application! There are some more innovating ideas listed on the site. This sure looks promising.
ww520 13y ago
I'm curious. How are user accounts managed? How does authentication work? How are the user data stored and shared on different browser sessions?
- lojack 13y ago
  > "... falling back to using server-side components only to implement the features the browser does not yet support." Depending on the problem, that could be a prime candidate for falling back to the backend.
wwweston 13y ago
So, I've been working a bit on a simple RSS reader in a spare hour or two over the last few days, just to experiment with some ideas, and one of the things I decided to do at some point was create a small backend service that just generated a gibberish feed -- ordered dates with news item frequency I could set, proper RSS, but nonsense text and a pictures of/links to cats. This was after I already had a "real" backend (could grab/merge RSS feeds), but I still found it useful in focusing on some front-end features, and I wonder if I might even have been farther along from a prototyping standpoint if I'd made that approach from the start. If this is true for some problem domains, my guess is that it's possibly more true for those (such as feed gathering) where the backend tech issues are mostly simple or solved problems and most of the novel work to do is in the realm of UX.
- mcintyre1994 13y ago
  I think, to generalise a bit, you should probably work on your hardest problem needed to launch. If that's an awesome UX, you should probably make sure that's possible, and especially with front-end stuff validate that it's usable. If your backend has unsolved problems that are needed for launch, you probably want to make sure they're solvable before you spend ages implementing the frontend.
nick2021 13y ago
The author is taking an existing concept that is not new at all and describing it in a fancy way to make it sound like a great new thing. This reminds me of how UX designers talk about their job. Their job importance can be measured in X and they are always trying to make it sound important as X squared. Please front end guys, do not do this.
- camus 13y ago
  that's called marketing , is it evil ?well... we all use it to sell whatever we need to sell.
- brianfryer 13y ago
  They are proud of what they're doing. Please, let people share their ideas and implementations. It's okay to rehash "older" concepts and present them to new audiences (who may not have been exposed to them). If this isn't new to you, contribute to the conversation with additional examples or insight. An oldie (but goodie) was on the front page today: http://www.thingist.com/item/4372/ http://www.thingist.com/item/4372/. There might be some valuable & relevant lessons to glean.
zimbatm 13y ago
I was first introduced to the "wishful thinking" idea when watching the SICP lectures. It's introduced quite early on in lesson 1 or 2. It really changed how I approach new problems and now I use it all the time. http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/ http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussma... In a way "dreamcode" is basically the same: you determine what you want to build and infer the API dependencies that you will need. It makes sure that all the API that you're going to build are going to be used.
benbusse 13y ago
@aespinoza Check out dreamfactory.com, we just launched an open source backend service platform.
- aespinoza 13y ago
  Checking it now. I work for a Backend Service platform called iKnode. So I already have a backend for my apps.
  - benbusse 13y ago
    Great, would love any feedback. We're mainly targeting enterprises. I'll check out iKnode.
    - aespinoza 13y ago
      Definitely. I would value some feedback from you as well.
Tactic 13y ago
Form follows function. That said, I find it best to divide the tiers and document where they meet ahead of time. Then develop each tier independently to the spec. That makes it so much easier when it is time to maintain/iterate/swap out one of the parts. Front end first, back end first... it doesn't really matter. You shouldn't be designing one to the other. Function first :)
grimtrigger 13y ago
We're already seeing the rise of backend as a service through products like Disqus, Video/youtube, and google analytics. If you're looking for problems to solve, find something you hate doing as a developer and find a way to jam it into an iframe/javascript snippet.
- aespinoza 13y ago
  I wouldn't consider any platform that exposes an API a Backend as a Service. I do understand where you are coming from, but Backend as a Service providers are more like iKnode, Parse, Kinvey and Firebase.
  - camus 13y ago
    i found Baas really hard to test , especially when you need to upload some bits of business logic somewhere ... I tried a bit with couchdb and couchapp, but i never figured out how to unit tests attached documents. Parse works a bit the same way. How do you do testing on Baas ?
    - aespinoza 13y ago
      On iKnode you can test your backend with simple Javascript Unit Tests. We have a sample in our Javascript SDK: https://github.com/Structum/iKnodeSdk/tree/master/Javascript https://github.com/Structum/iKnodeSdk/tree/master/Javascript What you do is you create your Backend App in iKnode like this one: https://github.com/Structum/iKnodeSdk/blob/master/Javascript/UserService.cs.txt https://github.com/Structum/iKnodeSdk/blob/master/Javascript... Then you write your Unit Tests in Javascript like in here: https://github.com/Structum/iKnodeSdk/blob/master/Javascript/UnitTests/iKnodeSdkTest.js https://github.com/Structum/iKnodeSdk/blob/master/Javascript... You can also run any other Unit Test framework against iKnode, for example we have: - C# with Microsoft Unit Test:https://github.com/Structum/iKnodeSdk/tree/master/C%23 https://github.com/Structum/iKnodeSdk/tree/master/C%23 - Objective-C with Unit Tests: https://github.com/Structum/iKnodeSdk/tree/master/Objective-C https://github.com/Structum/iKnodeSdk/tree/master/Objective-...
- zizee 13y ago
aespinoza 13y ago
This is indeed an interesting approach. Backend as a Service usually fixes the problem for the developer. Which is to make it easy on the developer to create distributed systems. BaaS improves UX in a small way by just making things faster and more accessible. But the focus is still the developer. The no-backend approach removes the backend all toghether, by focusing on UX, basically on the end-user. This is an amazing idea. Not because of how revolutionary the technology is, but mostly because it is a very creative way of improving the user experience. Obviously not all websites would benefit from this approach, but there is a large application for it. For most application, a hybrid approach would bring the best results. Zumero (http://zumero.com/ http://zumero.com/) for example keeps the data on the user device for mobile applications. It makes sure the application stores everything in the device, so that apps don't require an external backend. In the case of Websites, ExtJs (http://www.sencha.com/products/extjs/ http://www.sencha.com/products/extjs/) has its store, which represents a local storage for web applications. It is not persistent, but there are ways to keep it in the user machine. Don't dismiss the idea because it seems radical, try to integrate it into your app and I am sure you will see the advantages.
camus 13y ago
i've always been front-end first. creating the html/js first then the server api out of it , then finally chosing the persistance layer. So nothing new here. that's called building up to bottom . You focus on a few user scenarios and you just make them happen. then you refactor your obviously nasty code , and thanks to tests , nothing breaks on the client. That's why i like microframeworks too instead of bloated stuffs. They can grow with your needs instead of having all these unusefully layers of code packaged together, and they are still good enough for team work.
- r00fus 13y ago
  What do you prefer in terms of microframeworks?
rdbhost 13y ago
These #nobackend folks are late to the game! Rdbhost has provided for no-server-coding web apps since 2010. See http://www.rdbhost.com http://www.rdbhost.com

37 points by aespinoza 13y ago

http://nobackend.org http://nobackend.org http://nobackend.org/dreamcode http://nobackend.org/dreamcode Interesting gists of ideal code: - user accounts / authentication https://gist.github.com/gr2m/5463426 https://gist.github.com/gr2m/5463426 - data persistence https://gist.github.com/gr2m/5463475 https://gist.github.com/gr2m/5463475 - data sharing https://gist.github.com/gr2m/5463525 https://gist.github.com/gr2m/5463525 - emails https://gist.github.com/gr2m/5463552 https://gist.github.com/gr2m/5463552 - file conversion https://gist.github.com/gr2m/5463605 https://gist.github.com/gr2m/5463605 - payments https://gist.github.com/gr2m/5463675 https://gist.github.com/gr2m/5463675 http://nobackend.org/examples http://nobackend.org/examples - http://css-tricks.com/editable-invoice-v2/ http://css-tricks.com/editable-invoice-v2/ - http://gr2m.github.io/EditableInvoice/ http://gr2m.github.io/EditableInvoice/ http://nobackend.org/solutions http://nobackend.org/solutions < known live projects

onemorepassword 13y ago

> It's a different approach that especially fits applications that hold most of its logic in the frontend, where the user experience is the most important feature. This is the part I have a bit of an issue with when it comes to all the hype about front-end development. I've been involved in web development since 1994, and software development since the 80's. I've so very, very rarely encountered applications to which this applies. When I mention this, people come up with examples like GMail or Twitter, obviously not understanding the the front-end part, however impressive in the case of GMail, is just that: a front-end, a client for an application so much more complex. I sometimes feel front-end experts have no idea about what happens on the back-end. All those API-calls are not being handle by some magic genie. Or maybe I'm wrong and I've missed something essential.

ryanSrich 13y ago
> All those API-calls are not being handle by some magic genie But they're there. You implement what they do on the front-end. Think of any application you interact with on a daily basis. The tasks are very front-end oriented. I can only think of a handful of applications I use that have a robust backend for an apparent logical reason (image recognition and pdf parsing). Most of what we do on the web can and will be handled on the front-end.
asolove 13y ago
I think that your point of view is actually a really good reason for front-end-first development. As a front-end developer, I accept that the back-end portion of modeling, storing, and scaling the data is a much harder (or at least much different and very hard to me) task that generally requires much more investment before you get much useful feedback. So when working on a new product, it's worthwhile to build as much of a facade interface as you can to quickly and cheaply explore how it feels to use the product. Then you can iterate rapidly with something concrete in front of your stakeholders, and when they're happy, you can just build the back-end once, from a solid foundation of domain knowledge. It also works out well socially. Some people (who tend to congregate in front-end) work well with vague ideas about a user experience and instructions to explore the product on their own. Others (who congregate in back-end these days) want firmer ideas about the product and usage so that they can exercise their creativity in solving the technical problem well. Front-end-first is a great way to let everyone do the part of the job that they like.
- onemorepassword 13y ago
  The word you're looking for is "prototyping". I'm not being sarcastic (well, okay, a little), I pretty much agree with most of what you wrote (of course depending on the project at hand), except the notion that this is something new. Also, just working on the front-end/user experience doesn't give you, and certainly not the back-end developers, a "solid foundation of domain knowledge". That only happens if they are deeply involved in the same process, and front-end-first suggests exactly the opposite. A front-end, no matter how wonderful and detailed, is still way to vague to serve as specs unless the application is very simple.
  - sanderjd 13y ago
    What separates this idea from prototyping in my view is that they are suggesting keeping the "prototyped" UI as the real deal and then building a back-end to support it, rather than re-building the front-end along with the back-end. The back-end is developed using all of the well-documented places where the front-end needs support as a spec.
- 13y ago
saraid216 13y ago
Is this about you not getting the credit you deserve, or is it about building the best application possible?

legedemon 13y ago

I have some validation finally. I have called this approach frontend-first and have evangelized it internally in my teams. But NoBackend is, catchy. Basically, I rally my team to build up as much functionality as they possibly can w/o writing any server side code and demo it to the stakeholders and have their final confirmation before starting to write anything on the server. The demo at this point pretty much resembles the live application! There are some more innovating ideas listed on the site. This sure looks promising.

ww520 13y ago

I'm curious. How are user accounts managed? How does authentication work? How are the user data stored and shared on different browser sessions?

lojack 13y ago
> "... falling back to using server-side components only to implement the features the browser does not yet support." Depending on the problem, that could be a prime candidate for falling back to the backend.

wwweston 13y ago

So, I've been working a bit on a simple RSS reader in a spare hour or two over the last few days, just to experiment with some ideas, and one of the things I decided to do at some point was create a small backend service that just generated a gibberish feed -- ordered dates with news item frequency I could set, proper RSS, but nonsense text and a pictures of/links to cats. This was after I already had a "real" backend (could grab/merge RSS feeds), but I still found it useful in focusing on some front-end features, and I wonder if I might even have been farther along from a prototyping standpoint if I'd made that approach from the start. If this is true for some problem domains, my guess is that it's possibly more true for those (such as feed gathering) where the backend tech issues are mostly simple or solved problems and most of the novel work to do is in the realm of UX.

mcintyre1994 13y ago
I think, to generalise a bit, you should probably work on your hardest problem needed to launch. If that's an awesome UX, you should probably make sure that's possible, and especially with front-end stuff validate that it's usable. If your backend has unsolved problems that are needed for launch, you probably want to make sure they're solvable before you spend ages implementing the frontend.

nick2021 13y ago

The author is taking an existing concept that is not new at all and describing it in a fancy way to make it sound like a great new thing. This reminds me of how UX designers talk about their job. Their job importance can be measured in X and they are always trying to make it sound important as X squared. Please front end guys, do not do this.

camus 13y ago
that's called marketing , is it evil ?well... we all use it to sell whatever we need to sell.
brianfryer 13y ago
They are proud of what they're doing. Please, let people share their ideas and implementations. It's okay to rehash "older" concepts and present them to new audiences (who may not have been exposed to them). If this isn't new to you, contribute to the conversation with additional examples or insight. An oldie (but goodie) was on the front page today: http://www.thingist.com/item/4372/ http://www.thingist.com/item/4372/. There might be some valuable & relevant lessons to glean.

zimbatm 13y ago

I was first introduced to the "wishful thinking" idea when watching the SICP lectures. It's introduced quite early on in lesson 1 or 2. It really changed how I approach new problems and now I use it all the time. http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/ http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussma... In a way "dreamcode" is basically the same: you determine what you want to build and infer the API dependencies that you will need. It makes sure that all the API that you're going to build are going to be used.

benbusse 13y ago

@aespinoza Check out dreamfactory.com, we just launched an open source backend service platform.

aespinoza 13y ago
Checking it now. I work for a Backend Service platform called iKnode. So I already have a backend for my apps.
- benbusse 13y ago
  Great, would love any feedback. We're mainly targeting enterprises. I'll check out iKnode.
  - aespinoza 13y ago
    Definitely. I would value some feedback from you as well.

Tactic 13y ago

Form follows function. That said, I find it best to divide the tiers and document where they meet ahead of time. Then develop each tier independently to the spec. That makes it so much easier when it is time to maintain/iterate/swap out one of the parts. Front end first, back end first... it doesn't really matter. You shouldn't be designing one to the other. Function first :)

grimtrigger 13y ago

We're already seeing the rise of backend as a service through products like Disqus, Video/youtube, and google analytics. If you're looking for problems to solve, find something you hate doing as a developer and find a way to jam it into an iframe/javascript snippet.

aespinoza 13y ago
I wouldn't consider any platform that exposes an API a Backend as a Service. I do understand where you are coming from, but Backend as a Service providers are more like iKnode, Parse, Kinvey and Firebase.
- camus 13y ago
  i found Baas really hard to test , especially when you need to upload some bits of business logic somewhere ... I tried a bit with couchdb and couchapp, but i never figured out how to unit tests attached documents. Parse works a bit the same way. How do you do testing on Baas ?
  - aespinoza 13y ago
    On iKnode you can test your backend with simple Javascript Unit Tests. We have a sample in our Javascript SDK: https://github.com/Structum/iKnodeSdk/tree/master/Javascript https://github.com/Structum/iKnodeSdk/tree/master/Javascript What you do is you create your Backend App in iKnode like this one: https://github.com/Structum/iKnodeSdk/blob/master/Javascript/UserService.cs.txt https://github.com/Structum/iKnodeSdk/blob/master/Javascript... Then you write your Unit Tests in Javascript like in here: https://github.com/Structum/iKnodeSdk/blob/master/Javascript/UnitTests/iKnodeSdkTest.js https://github.com/Structum/iKnodeSdk/blob/master/Javascript... You can also run any other Unit Test framework against iKnode, for example we have: - C# with Microsoft Unit Test:https://github.com/Structum/iKnodeSdk/tree/master/C%23 https://github.com/Structum/iKnodeSdk/tree/master/C%23 - Objective-C with Unit Tests: https://github.com/Structum/iKnodeSdk/tree/master/Objective-C https://github.com/Structum/iKnodeSdk/tree/master/Objective-...
zizee 13y ago

aespinoza 13y ago

This is indeed an interesting approach. Backend as a Service usually fixes the problem for the developer. Which is to make it easy on the developer to create distributed systems. BaaS improves UX in a small way by just making things faster and more accessible. But the focus is still the developer. The no-backend approach removes the backend all toghether, by focusing on UX, basically on the end-user. This is an amazing idea. Not because of how revolutionary the technology is, but mostly because it is a very creative way of improving the user experience. Obviously not all websites would benefit from this approach, but there is a large application for it. For most application, a hybrid approach would bring the best results. Zumero (http://zumero.com/ http://zumero.com/) for example keeps the data on the user device for mobile applications. It makes sure the application stores everything in the device, so that apps don't require an external backend. In the case of Websites, ExtJs (http://www.sencha.com/products/extjs/ http://www.sencha.com/products/extjs/) has its store, which represents a local storage for web applications. It is not persistent, but there are ways to keep it in the user machine. Don't dismiss the idea because it seems radical, try to integrate it into your app and I am sure you will see the advantages.

camus 13y ago

i've always been front-end first. creating the html/js first then the server api out of it , then finally chosing the persistance layer. So nothing new here. that's called building up to bottom . You focus on a few user scenarios and you just make them happen. then you refactor your obviously nasty code , and thanks to tests , nothing breaks on the client. That's why i like microframeworks too instead of bloated stuffs. They can grow with your needs instead of having all these unusefully layers of code packaged together, and they are still good enough for team work.

r00fus 13y ago
What do you prefer in terms of microframeworks?

rdbhost 13y ago

These #nobackend folks are late to the game! Rdbhost has provided for no-server-coding web apps since 2010. See http://www.rdbhost.com http://www.rdbhost.com