NoBackend: Front-End First Web Development | Hacker News Reader

NoBackend: Front-End First Web Development

infoq.com

37 pointsaespinoza31 comments

Open articleView on HN

http://nobackend.org

http://nobackend.org/dreamcode Interesting gists of ideal code:

- user accounts / authentication https://gist.github.com/gr2m/5463426

- data persistence https://gist.github.com/gr2m/5463475

- data sharing https://gist.github.com/gr2m/5463525

- emails https://gist.github.com/gr2m/5463552

- file conversion https://gist.github.com/gr2m/5463605

- payments https://gist.github.com/gr2m/5463675

http://nobackend.org/examples

- http://css-tricks.com/editable-invoice-v2/

- http://gr2m.github.io/EditableInvoice/

http://nobackend.org/solutions < known live projects

> 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.

> 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.

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.

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.

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.

"Build the backend once" is a silly notion; software is never static; neither the front-end OR the backend.

I can appreciate the front-end-first philosophy, and can see it working well in an environment where you what to build something to "show off" (kind of like WordPress templates that you can "demo"). It might even work fine for something like AirBnB in which the bulk of the application is just a CRUD mesh.

I cannot see it working well for any startup that relies on technology that requires a careful and thorough iteration of its foundation (backend). Once the backend is built with a solid RESTful interface, it's trivial to write the front-end and you can A/B test the shit out of it, do white-labeling, try different workflows and UX experiments all while only making tweaks or small additions to your backend (of course excluding major deep-feature development).

Is this about you not getting the credit you deserve, or is it about building the best application possible?

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.

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.

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.

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/) 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/) 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.

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-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.

These #nobackend folks are late to the game! Rdbhost has provided for no-server-coding web apps since 2010.

See http://www.rdbhost.com

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 :)

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.

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.

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 ?

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

What you do is you create your Backend App in iKnode like this one: 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...

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

- Objective-C with Unit Tests: https://github.com/Structum/iKnodeSdk/tree/master/Objective-...

That's exactly the thought process behind my latest application. I was sick of writing/polishing the same authentication / payment processing functionality, so I made it into a service (that utilises itself no less).

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

Checking it now. I work for a Backend Service platform called iKnode. So I already have a backend for my apps.

Great, would love any feedback. We're mainly targeting enterprises. I'll check out iKnode.

Definitely. I would value some feedback from you as well.

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

> "... 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.

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.

that's called marketing , is it evil ?well... we all use it to sell whatever we need to sell.

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/. There might be some valuable & relevant lessons to glean.

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.

What do you prefer in terms of microframeworks?

Reply on news.ycombinator.com