Some time ago, I blogged about the different phases of mental transition when working with JavaScript frontends. Here's the shorten version:
1. No-JavaScript phase
2. JQuery explosion
3. Page and Widget objects
4. Single Page Application
Once you're in phase 4 and you create apps this way, you realize that you don't need the backend in order to create the Single Page App. Even more, you shouldn't start with a backend.
Frontend first
This is the additional phase. Frontend first. In most of the typical situations, it's much better to start with a Single Page Application and use LocalStorage or some kind of a InMemoryServerSideAdapter for the first phases of the development.
Only after you know how the frontend works and what kind of server interaction it requires, it actually makes sense to start working on the backend.
We've tried this approach in several Single Page Apps and it worked great for us. It now seems like the most natural way of working.
to learn more about Single Page Applications.
4 comments:
This reminds me of Uncle Bob talking about a Hexagonal/Onion/Ports'n'Adaptors application, in which they recurringly postponed creating a persistence layer. They originally thought it would need a database, but to begin with just mocked out persistence. Then someone created a test implementation of the persistence API, using flat files, just for testing. Then they started demoing the app, and then shipping the app, and eventually realised they didn't need a database at all.
Is what you're talking about similar to this at all?
Yes, that's exactly this.
From the perspective of an SPA, the backend is actually mostly some kind of a smart persistence (depending on the application).
We were delaying the backend work for a while and it seems that maybe we don't need to do a proper backend, but can rely on firebase, or a similar tool. Which is very convenient :)
I totally agree.
We follow a similar approach with most of the applications we build for our clients, even when they aren't single-page apps.
After wireframing the key screens, we build a clickable prototype using Twitter Bootstrap that allows all stakeholders to play around and use the application at a level that's very close to what the user will see in the actual app.
This eliminates a lot of guess work out of the development process, and allows us to find issues with the user interface much sooner, before writing a single line of back-end code or opening Photoshop.
Anton,
Sounds great!
I think I sometimes worried, if this approach isn't too waterfallish. What's your opinion on that?
Post a Comment