Yes, completely possible. As I say, what I put up there is extremely rough, but if you can understand the code you can build on it.
You need some way of persisting data/getting persisted data, it doesn’t matter if it’s an SPA or not.
You can go back -> front end, build the way the data is built and handled first, or go front -> back end, mock the data at first and just build UI then replace the mock with real stuff later on. Or a combination of the two.
Say go front -> back, building on what I mocked up:
Add bit by bit. The modal for the cart could be styled to cover whole page. The close could be styled as a back button instead of an “x”. Hopefully you can see the path to how it morphs to a SPA. Then you can make the back/forwards button actually work:
You can store data for the current page in local storage like @sorinr says, which means you can push stuff in to something that’s like a DB (this will be v useful for building on the cart logic)
So say you implement the above. The code is going to have gotten untidy, and there will be a lot of state to manage. For example, what happens if there are more than just a few products? You’d kinda want them paginated, maybe have categories, be filterable. You can prototype all of that, and add it to the code, but it will be getting very difficult to change anything without breaking other stuff at this point.
This is the point at which you reach for an SPA framework: someone has already been through all of the issues you’re about to face, there’s no point rehashing them. React/Vue/Angular/etc will all add a huge layer of complexity up front. But generally they make it much easier to develop the app once you get past that.
Whether or not you use a framework, by that point, the app is functional within a page. If you reload the page, it may go back to square one, (or if you store stuff locally, you can keep the state), but it still can’t actually do anything real.
You can even have user and payment logic without ever touching a backend: you can for example just not have users, and something like Stripe can give you a payment system.
For a working shop though, you’d imagine that you would want some storage system, some way to track stock. However you do it, it has to use some kind of back end - whether that is something that has already been built that you plug into (Shopify for example), or whether you build it yourself.
That’s where I’d say look at a web framework (or even a language where you can do most stuff without a framework, i.e. almost everything necessary is already built into the language’s standard library - Go for example). Express, Rails, Flask, Laravel etc etc. Just something that sits in front of a database and makes it easy for you to route requests to add stock, purchase stock etc.
You kinda build up a stack:
- a database (a relational DB fits perfectly here, like MySQL or PostgreSQL)
- a web framework (backend), normally going to be a package of server + some MVC thing where you have Models representing the DB interactions, Views which can be HTML templates or JSON, and controllers which match route to actions on the model and render the views in response to those (like
http://mysite/products/add
will POST some data and add a product to your database)
- Maybe a front-end framework, maybe not, but basically the JS on the pages is going to be used to make AJAX requests against the routes defined in the backend framework. For product pages ect, probably fine to just have HTML pages, but adding products to a cart, you wouldn’t want to switch pages every time a user added a product, you’d just submit the user action using AJAX so the page didn’t reload.
One thing you can do as a kind of bridge is to use
Which gives you a full REST server to develop on - you represent a database with a JSON file, and you can write to and read from that file, and it automatically builds HTTP routes from it. It’s a good thing for an inbetween stage where you have a front and and you want it to talk to a back end, but you haven’t built any backend.
Note that this assumes an SPA kinda structure, where you’re requesting things via AJAX on the front end. Just having HTML pages generated from routes in backewnd framework is much easier in many ways - you don’t have to worry about JS so much.
hopefully that gives you some ideas, sorry about the braindump wall of text!