"We knew we wanted to build a single page application (SPA) in order to have more control over the user experience of our website, making it as smooth as possible. On top of this, it also helps speed our website up since there’s no longer a need for full page reloads. We only need to load the data that we don’t have yet, and then re-render the page."
I'm bothered by this perception that SPAs inherently provide a better user experience. They certainly can provide a different user experience, but "better" is entirely up to the developers. I'd argue its actually quite hard to create a better UX in an SPA than the simple page based UX metaphor everyone is used to that the browser provides. Netflix is an example of a great UX from an SPA, nba leaguepass is an example of a disaster SPA.
Also there is no inherent speed boost from an SPA. Anything that is slow on the server will still be slow, and its up to the developer to create a good UX for latency. In page driven applications, the browser provides a fairly standard UX for page loading that most people are used to. In SPA apps, the developer needs to roll this themselves. Widgets popping in all over the place at different times, moving things all over the page, is a common UX I see in SPAs that is not good.
I wish I would hear this expressed more often. Many, many web apps lend themselves well to a very simple page-based UI. The development community can just never seem to recognize or acknowledge how many of their decisions are based on whatever the latest fad happens to be.
> "Also there is no inherent speed boost from an SPA"
There is: superior caching & resource management. Even if your non-SPA perfectly caches resources (impossible with bundling), you are still wasting time on parsing/compiling/executing cached scripts on every page reload, which can take up to a few seconds on smartphones.
Svelte allows isomorphic rendering (client & server side). Svelte also has a feature called rehydrate, which will bind the component to html rendered on the server side; sortof like serializing/unserializing.
This enables me to use Svelte for both client-side & server side rendering, replacing other template systems & having the best of both worlds (page caching, dynamic behavior on the client, a scalable front-end architecture, composition, etc).
You can create a simple page based UX metaphor using SPA. In fact it is the most common model around. You emulate routes client side and rather than refreshing the page you just change the inner content. Every demo, framework example and web site template I've seen uses has this as a reference.
And of course this is faster than server side model since you are only loading what is changed and not the entire page again. Also SPAs allow you to selectively bring in new Javascript components/widgets.
Also there is a common pattern for conveying the page loading to the user. It's the thin coloured progress bar that appears under the tabs. And there are dozens of plugins for implementing it.
It's increasingly harder to find non-legacy single page apps that aren't using React or Angular (Vue and Ember are distantly trailing behind). Corollary: it's increasingly harder to find jobs for anything other than React or Angular.
After technology du jour becomes popular, people will use it not because it's good or even necessary, but because it will ensure their employment. And then the rationalizations sink in afterwards.
The worst part about this is that it makes people (at work or in side projects) use these and other frameworks for every project ever for the resume padding. Doesn't matter if it's a CRUD app that just needs a form - it has to be a complex web app with a GraphQL backend and 50mb of React frontend.
My personal problem is that people start to present themselves as "React" or "Angular" developers, which is kind of scary for me personally.
It is also hard to explain that you can pick up their framework (e.g. switch to Vue.js from React), many companies just say "no" unless you can provide strong experience. Some companies have better policies and they insist only on core knowledge and principles, but, unfortunately, I personally find them to be in a minority.
Many, many code horrors exist today due to a deep and abiding fear developers have of appearing insufficiently smart.
Most of the web apps that are being built today have no need for a complex front end and, if they do, it's only in a few places. But, as you quote, programming is pop culture, so every new Form => Datastore app is going to be built using a toolchain more complicated than quake was built with.
Wouldn't that also be the case if, for example, React/Angular were demonstrably superior technologies to the alternatives? groupthink doesn't have to be the only explanation.
I'm building my new front around two cutting edge technologies, jquery and bootstrap. My UI should be fairly simple, why complicate development and bloat the download?
> people will use it not because it's good or even necessary, but because it will ensure their employment
Utter nonsense.
Developers use these frameworks (a) because they like it, (b) because there is a wealth of knowledge on the internet about how to fix every little problem, (c) because it allows them to be productive with their peers and (d) because often they learn something new. People get bored doing the same thing over and over again for 30 years like you seem to be advocating for.
I'm not even sure it's just to ensure employment; that's a very simplistic explanation.
Languages and frameworks are how programmers communicate with each other. The same argument could be made for the English language. Developers will naturally congregate around common language because there is value in that. It's wrong to dismiss that value proposition as mere pop culture.
Personal anedocte: I decided to become a developer and studied first Javascript itself, then React; exactly for the reason of employability. A month ago I started at my first dev job, at a great place.... using Ember! :) I never had touched Ember before, and nothing on React around here.
This seems like a great writeup with some good information in it.
But to be picky, the title needs work. It isn't as describe. In fact it contradicts itself.
The title is:
> Front-end Walkthrough: Building a Single Page Application from Scratch
Half way down the article:
> When it comes to building a SPA, you can either do things from scratch or use a library to help you out. Building from scratch is a lot of work and adds a lot of new decisions to be made, so we decided to go with a framework.
I would be very interested to see an article in 2017 that is actually from scratch. Bonus points for not using a ES6 transpiler. Like "Linux from Scratch" (the book)... useless from a practical standpoint but awesome from a learning standpoint.
Edit: as a side note, when I started making web apps, jQuery was still in beta so I didn't even use it. A lot has changed, obviously, for one SPA didn't really exist then.
I want to point out that it works perfectly fine making a JavaScript web app in just vanilla JavaScript using NodeJS as server and the browser as client. You do not need any frameworks!! Vanilla JavaScript works for both small projects and big projects. And it performs well! (at least compared to the popular frameworks) and it's very nice to debug! There is no complication step! And your code will be supported for ever unlike the framework's that will make your code obsolete within a year or so.
"And your code will be supported for ever unlike the framework's that will make your code obsolete within a year or so."
This is a confusing assertion. How does using a framework make your software unsupported in ways that not using a framework would not? i.e. if I build an application, whether I use a framework or not, and then I stop touching it, forever, why is the non-framework code more resilient to not breaking in the future?
The framework will keep evolving, but you're under no obligation to upgrade, if you don't need to keep developing. It seems silly to complain about the code you didn't have to write.
There are trade offs when using existing software to do things you want to do, sure. But, you get the core web app functionality you needed to implement, anyway, and it's been tested by a lot more developers than your code likely ever will be. In fact, I'd argue compatibility with a framework will be better than implementing it yourself, assuming you cover the same amount of functionality in each app; again, because of the heavier testing a widely used framework gets.
> I want to point out that it works perfectly fine making a JavaScript web app in just vanilla JavaScript using NodeJS as server and the browser as client. You do not need any frameworks!!
You just end up inventing your own framework this way. You'll come across problems, come up with some solution you think is clever, come up with conventions to follow etc. Surprise! You've just manually rediscovered all the problems frameworks were created to solved and reinvented the wheel.
I'll use vanilla JavaScript or jQuery if the UI required is really basic but anything beyond that, you're going to save time using a well thought out framework rather than thinking you're smarter than whole communities who have spent years working on these solutions. Coders don't invent frameworks for the sake of it, they exist for a reason.
yet another web framework medium article with a misleading angular vs react comparison.
it isn't angular 2 anymore. it's just angular. it's been out for over a year and if people were having problems running it in production, we would hear about it. there are many sites running angular 2-4 in production, google it and see for yourself. just because google didn't rewrite gmail in angular doesn't mean you shouldn't use it.
I wonder if there is some highly ranked google search result that spreads this misinformation, months after some of these points were valid.
Recommendation for poki, make it easier to reach your website from your blog.
When I go to blog.poki.com, if I like what I read I typically delete "blog." to checkout what "poki.com" is about -- which should be the purpose of blogging. In this case it doesn't work, and I had to manually type "www.".
Rather than relying on URL rewriting by the reader (and, thus, specific URL relationships), it would be better just to put a prominent link to the (www.)poki.com website from the blog.
Relying on manual URL rewriting to navigate to a related page is missing the entire point of the web.
Most of the issues cited with Angular and React aren't really issues in EmberJS right now. I always find it interesting that so many people jump right into frameworks that have design philosophies against maintainability.
The problem with Ember is that finding developers is a lot harder so nobody will use it. I'm not saying it's bad, but if I would start a company now and had to do a SPA (hopefully not) it would definitely be either React or Angular just because finding developers would be easier.
I am doing SPA with vuejs and django backend, its a huge step in the right direction as far as (my) web development goes. Initially I was sceptical of webpack, now I see what an asset it is in compiling static content and many other handy features. I prefer vuejs to react or angular but I haven't really given them much time, maybe one day
This is a debate that can be done to death (which is good, that's how these frameworks improve), but as someone that's used backbone/marionette, angular, and react react/redux, I can say the day I found the Vue docs was like a reawakening. I don't mean to get poetic, but I genuinely had a sense of "holy shit, this is what docs should look like!" I only got more and more excited as I read through and learned more about it.
Vue is fucking awesome. I'm just now learning it and I can't wait to build something more serious than a todo app with it.
Can you point out some good resources that you used to integrate Django with vue? I have a full stack Django website and have often thought about using some js library and speeding things up on the front end (and reduce bandwith usage) but my (admittedly lazy) experiment with react/angular haven't gone anywhere much.
Any tips on how to start with the integration? Do you use node to serve the front end or is it served by django?
[+] [-] hitgeek|8 years ago|reply
I'm bothered by this perception that SPAs inherently provide a better user experience. They certainly can provide a different user experience, but "better" is entirely up to the developers. I'd argue its actually quite hard to create a better UX in an SPA than the simple page based UX metaphor everyone is used to that the browser provides. Netflix is an example of a great UX from an SPA, nba leaguepass is an example of a disaster SPA.
Also there is no inherent speed boost from an SPA. Anything that is slow on the server will still be slow, and its up to the developer to create a good UX for latency. In page driven applications, the browser provides a fairly standard UX for page loading that most people are used to. In SPA apps, the developer needs to roll this themselves. Widgets popping in all over the place at different times, moving things all over the page, is a common UX I see in SPAs that is not good.
[+] [-] projectileboy|8 years ago|reply
[+] [-] ko27|8 years ago|reply
There is: superior caching & resource management. Even if your non-SPA perfectly caches resources (impossible with bundling), you are still wasting time on parsing/compiling/executing cached scripts on every page reload, which can take up to a few seconds on smartphones.
[+] [-] briantakita|8 years ago|reply
This enables me to use Svelte for both client-side & server side rendering, replacing other template systems & having the best of both worlds (page caching, dynamic behavior on the client, a scalable front-end architecture, composition, etc).
https://svelte.technology/
Here's a quick post about my setup for static sites.
http://www.briantakita.com/posts/monorepo-static-sites-using...
Here's a post on converting from riotjs to svelte on a client project.
http://www.briantakita.com/posts/sveltejs-from-riotjs/
[+] [-] ashark|8 years ago|reply
[+] [-] threeseed|8 years ago|reply
You can create a simple page based UX metaphor using SPA. In fact it is the most common model around. You emulate routes client side and rather than refreshing the page you just change the inner content. Every demo, framework example and web site template I've seen uses has this as a reference.
And of course this is faster than server side model since you are only loading what is changed and not the entire page again. Also SPAs allow you to selectively bring in new Javascript components/widgets.
Also there is a common pattern for conveying the page loading to the user. It's the thin coloured progress bar that appears under the tabs. And there are dozens of plugins for implementing it.
[+] [-] daliwali|8 years ago|reply
It's increasingly harder to find non-legacy single page apps that aren't using React or Angular (Vue and Ember are distantly trailing behind). Corollary: it's increasingly harder to find jobs for anything other than React or Angular.
After technology du jour becomes popular, people will use it not because it's good or even necessary, but because it will ensure their employment. And then the rationalizations sink in afterwards.
[+] [-] sotojuan|8 years ago|reply
[+] [-] romanovcode|8 years ago|reply
> Why we switched from Mongo to Postgres
Wow, no shit. A database that was made 21 years ago and is still maintained is actually better - who would've guessed?
[+] [-] arkitaip|8 years ago|reply
[+] [-] bloomca|8 years ago|reply
It is also hard to explain that you can pick up their framework (e.g. switch to Vue.js from React), many companies just say "no" unless you can provide strong experience. Some companies have better policies and they insist only on core knowledge and principles, but, unfortunately, I personally find them to be in a minority.
[+] [-] carsongross|8 years ago|reply
Most of the web apps that are being built today have no need for a complex front end and, if they do, it's only in a few places. But, as you quote, programming is pop culture, so every new Form => Datastore app is going to be built using a toolchain more complicated than quake was built with.
[+] [-] twinkletwinkle|8 years ago|reply
Wouldn't that also be the case if, for example, React/Angular were demonstrably superior technologies to the alternatives? groupthink doesn't have to be the only explanation.
[+] [-] valuearb|8 years ago|reply
[+] [-] threeseed|8 years ago|reply
Utter nonsense.
Developers use these frameworks (a) because they like it, (b) because there is a wealth of knowledge on the internet about how to fix every little problem, (c) because it allows them to be productive with their peers and (d) because often they learn something new. People get bored doing the same thing over and over again for 30 years like you seem to be advocating for.
[+] [-] wvenable|8 years ago|reply
Languages and frameworks are how programmers communicate with each other. The same argument could be made for the English language. Developers will naturally congregate around common language because there is value in that. It's wrong to dismiss that value proposition as mere pop culture.
[+] [-] soneca|8 years ago|reply
[+] [-] meesterdude|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] throwaway2016a|8 years ago|reply
But to be picky, the title needs work. It isn't as describe. In fact it contradicts itself.
The title is:
> Front-end Walkthrough: Building a Single Page Application from Scratch
Half way down the article:
> When it comes to building a SPA, you can either do things from scratch or use a library to help you out. Building from scratch is a lot of work and adds a lot of new decisions to be made, so we decided to go with a framework.
I would be very interested to see an article in 2017 that is actually from scratch. Bonus points for not using a ES6 transpiler. Like "Linux from Scratch" (the book)... useless from a practical standpoint but awesome from a learning standpoint.
Edit: as a side note, when I started making web apps, jQuery was still in beta so I didn't even use it. A lot has changed, obviously, for one SPA didn't really exist then.
[+] [-] bloomca|8 years ago|reply
The repo is here https://github.com/Bloomca/vanilla-web-app, if you are interested.
[+] [-] zokier|8 years ago|reply
> Front-end Walkthrough: Designing a Single Page Application Architecture
> We documented our journey towards a shiny new stack.
[+] [-] z3t4|8 years ago|reply
[+] [-] SwellJoe|8 years ago|reply
This is a confusing assertion. How does using a framework make your software unsupported in ways that not using a framework would not? i.e. if I build an application, whether I use a framework or not, and then I stop touching it, forever, why is the non-framework code more resilient to not breaking in the future?
The framework will keep evolving, but you're under no obligation to upgrade, if you don't need to keep developing. It seems silly to complain about the code you didn't have to write.
There are trade offs when using existing software to do things you want to do, sure. But, you get the core web app functionality you needed to implement, anyway, and it's been tested by a lot more developers than your code likely ever will be. In fact, I'd argue compatibility with a framework will be better than implementing it yourself, assuming you cover the same amount of functionality in each app; again, because of the heavier testing a widely used framework gets.
[+] [-] dopamean|8 years ago|reply
[+] [-] seanwilson|8 years ago|reply
You just end up inventing your own framework this way. You'll come across problems, come up with some solution you think is clever, come up with conventions to follow etc. Surprise! You've just manually rediscovered all the problems frameworks were created to solved and reinvented the wheel.
I'll use vanilla JavaScript or jQuery if the UI required is really basic but anything beyond that, you're going to save time using a well thought out framework rather than thinking you're smarter than whole communities who have spent years working on these solutions. Coders don't invent frameworks for the sake of it, they exist for a reason.
[+] [-] water42|8 years ago|reply
it isn't angular 2 anymore. it's just angular. it's been out for over a year and if people were having problems running it in production, we would hear about it. there are many sites running angular 2-4 in production, google it and see for yourself. just because google didn't rewrite gmail in angular doesn't mean you shouldn't use it.
I wonder if there is some highly ranked google search result that spreads this misinformation, months after some of these points were valid.
[+] [-] romanovcode|8 years ago|reply
Not fan of angular or any other framework in particular but this gets the job done so far. If only they finish angular universal faster..
[+] [-] Xoros|8 years ago|reply
[+] [-] mattgreenrocks|8 years ago|reply
[+] [-] ecesena|8 years ago|reply
When I go to blog.poki.com, if I like what I read I typically delete "blog." to checkout what "poki.com" is about -- which should be the purpose of blogging. In this case it doesn't work, and I had to manually type "www.".
[+] [-] dragonwriter|8 years ago|reply
Relying on manual URL rewriting to navigate to a related page is missing the entire point of the web.
[+] [-] CryoLogic|8 years ago|reply
[+] [-] romanovcode|8 years ago|reply
[+] [-] etblg|8 years ago|reply
(I work with Ember.js daily and am happy with it, just curious to see your thoughts)
[+] [-] peter_retief|8 years ago|reply
[+] [-] komali2|8 years ago|reply
Vue is fucking awesome. I'm just now learning it and I can't wait to build something more serious than a todo app with it.
[+] [-] sudshekhar|8 years ago|reply
Any tips on how to start with the integration? Do you use node to serve the front end or is it served by django?
[+] [-] robodale|8 years ago|reply