10 ms·

Front-End Walkthrough: Building a Single Page Application from Scratch

129 points by rizz0 9y ago

throwaway2016a 9y ago
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.
- bloomca 9y ago
  I wrote an article some time ago, with basic outlining, what is a single page application (without any framework) – http://blog.bloomca.me/2016/10/15/writing-web-application-in-plain-js.html http://blog.bloomca.me/2016/10/15/writing-web-application-in... The repo is here https://github.com/Bloomca/vanilla-web-app https://github.com/Bloomca/vanilla-web-app, if you are interested.
- zokier 9y ago
  The title was editorliazed by the poster, the orginal articles title does not contain "from scratch": > Front-end Walkthrough: Designing a Single Page Application Architecture > We documented our journey towards a shiny new stack.
  - throwaway2016a 9y ago
    > The title was editorliazed by the poster, the orginal articles title does not contain "from scratch": I actually copied and pasted my quote from the article title not the HN title. They were the same but they changed the article title (maybe after seeing my comment?). Which is completely OK, it's a good change.
daliwali 9y ago
Alan Kay was right, programming is pop culture. 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.
- meesterdude 9y ago
  sad but true, this echos much of my own observations in the industry.
- bloomca 9y ago
  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.
  - atom-morgan 9y ago
    TBF I think it's driven more by recruiters demanding it than programmers wanting to brand themselves that way.
    - pfranz 9y ago
      Yep. When I'm working on my resume it's a balance of trying to use the right relevant buzzwords to get past HR and enough content to get a callback from the person hiring. In my experience on the other side, HR doesn't often know that Rails implies Ruby or React implies JavaScript. Wrong buzzwords === wrong experience and not a fit for the job.
- sotojuan 9y ago
water42 9y ago
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.
- Xoros 9y ago
  I guess what the author meant is that when they started their project, Angular 2 was still not production stuff.
- mattgreenrocks 9y ago
  The pop culture cuts both ways it seems.
  - water42 9y ago
    Every framework is going to have flaws, but if you perform a comparison I think there's a responsibility to accurately represent the frameworks being compared.
- romanovcode 9y ago
  I run latest angular, works pretty good. We even got some support from google angular team itself - it's amazing. 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..
hitgeek 9y ago
"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.
- projectileboy 9y ago
  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.
- ko27 9y ago
  > "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.
  - felipeccastro 9y ago
    Don't know why this was downvoted, it is relevant. That's the main reason why hacks like PJAX/turbolinks were invented in the first place, not having to reparse the same JS and CSS for every page change has a noticeable impact in perceived performance.
CryoLogic 9y ago
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.
- etblg 9y ago
  Could you elaborate in more detail? (I work with Ember.js daily and am happy with it, just curious to see your thoughts)
- romanovcode 9y ago
  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.
peter_retief 9y ago
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
- komali2 9y ago
  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.
  - peter_retief 9y ago
    I haven't yet met a developer that doesn't like vue
    - reaperducer 9y ago
      I have. I once worked at a shop that tried to rebuild all of its web sites as SPA's with Vue. Four devs, two with deep JS experience, and it was a complete disaster. Vue isn't ready for enterprise, and the documentation is a joke. I don't work there anymore, but looking at the sites now, I can see the old ones are still online — TEN months later, no sign of Vue.
      - komali2 9y ago
        Woah, so looks like we disagree completely. Why don't you like the docs? I love how it has a great introduction guide[1] that really dives deep into the hows and whys, but also has a full API guide when you just gotta know one specific thing [2]. [1](https://vuejs.org https://vuejs.org) [2](https://vuejs.org/v2/api/ https://vuejs.org/v2/api/)
z3t4 9y ago
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.
- SwellJoe 9y ago
  "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.
  - metafunctor 9y ago
    Being able to upgrade the frameworks and platforms you choose to use is a legitimate concern. When did you ever build a relevant application and stop touching it, forever? Any worthwhile software I've ever built has been maintained with continuous effort. On the web especially, "don't keep developing" is just a death sentence.
    - SwellJoe 9y ago
      I'm not suggesting stopping development, I'm saying that the code you got for free (without any dev time) is not a loss, even if you have to do a little extra work to handle upgrades down the road. It's completely nonsensical to say obsolescence is a reason to not use a framework. There's like this weird disconnect in this conversation where we're talking about code that has very low cost to adopt (the framework, where the cost is a day or three or whatever learning how to use it) vs. code that probably has a much higher cost to initially develop from scratch (definitely more than a day or three or whatever, assuming similar functionality; probably weeks, once bug-fixing and cross-browser compatibility is solved). I mean it seems like basic math, to me. It takes X time (+ ~1 day) to deploy with a framework, while it takes X + Y time to implement the app and the framework your app uses (where Y is however long it takes to implement the functionality the framework would have given you). I mean, you're using a framework no matter what; either you use an off-the-shelf one that cost a couple days to learn, or you're building it and maintaining it yourself. How can the framework lose in this math unless it just isn't very good at the tasks it sets out to solve? You may have to do something about the framework in the future, to keep moving forward, but you must do something about your own framework to keep moving forward. If the third party framework you choose is abandoned or forces a migration (ala Angular), you're still not further behind than the framework you built yourself...because you can still develop the third-party framework yourself. It's not a black box. You're signing on to do all of the development work going forward if you choose to build your own framework. You only might need to deal with major changes or long-term maintenance costs, in the off-the-shelf framework. Unless you're only building a tiny app, there's no way this works out in your favor in terms of time-to-launch or in terms of ongoing maintenance. The small frameworks under discussion are single-digit thousands of lines of code; optimistically, that's weeks of work to replicate. And, it's hard to say you're not going to need to implement most of the functionality of a view layer library like Vue or React, if you're building an SPA. I mean, we're not talking about kitchen sink application frameworks here, where the cost of adoption might be high because the learning curve is high (and even then sometimes the math still works out in their favor if your app very closely matches the strengths of the framework...e.g. RoR did this for the backend; it is huge and learning it takes weeks, but a skilled RoR developer can be incredibly productive). This is a pick-and-choose kinda thing. You've got a few legos you can throw into a project to solve the obvious "everyone has to solve it" problems. And, then you build the real app, which does the unique stuff. You get more time for the unique stuff. I dunno, it just seems backward to ignore everything good out there in the ecosystem because you're afraid you might have to change your code in the future to keep using the latest version of the library or framework, or whatever.
ecesena 9y ago
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.".
- dragonwriter 9y ago
  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.
  - ecesena 9y ago
    I guess both will be useful - not having http(s)://poki.com configured seems also missing the point of the web :)

129 points by rizz0 9y ago

throwaway2016a 9y ago

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.

bloomca 9y ago
I wrote an article some time ago, with basic outlining, what is a single page application (without any framework) – http://blog.bloomca.me/2016/10/15/writing-web-application-in-plain-js.html http://blog.bloomca.me/2016/10/15/writing-web-application-in... The repo is here https://github.com/Bloomca/vanilla-web-app https://github.com/Bloomca/vanilla-web-app, if you are interested.
zokier 9y ago
The title was editorliazed by the poster, the orginal articles title does not contain "from scratch": > Front-end Walkthrough: Designing a Single Page Application Architecture > We documented our journey towards a shiny new stack.
- throwaway2016a 9y ago
  > The title was editorliazed by the poster, the orginal articles title does not contain "from scratch": I actually copied and pasted my quote from the article title not the HN title. They were the same but they changed the article title (maybe after seeing my comment?). Which is completely OK, it's a good change.

daliwali 9y ago

Alan Kay was right, programming is pop culture. 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.

meesterdude 9y ago
sad but true, this echos much of my own observations in the industry.
bloomca 9y ago
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.
- atom-morgan 9y ago
  TBF I think it's driven more by recruiters demanding it than programmers wanting to brand themselves that way.
  - pfranz 9y ago
    Yep. When I'm working on my resume it's a balance of trying to use the right relevant buzzwords to get past HR and enough content to get a callback from the person hiring. In my experience on the other side, HR doesn't often know that Rails implies Ruby or React implies JavaScript. Wrong buzzwords === wrong experience and not a fit for the job.
sotojuan 9y ago

water42 9y ago

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.

Xoros 9y ago
I guess what the author meant is that when they started their project, Angular 2 was still not production stuff.
mattgreenrocks 9y ago
The pop culture cuts both ways it seems.
- water42 9y ago
  Every framework is going to have flaws, but if you perform a comparison I think there's a responsibility to accurately represent the frameworks being compared.
romanovcode 9y ago
I run latest angular, works pretty good. We even got some support from google angular team itself - it's amazing. 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..

hitgeek 9y ago

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

projectileboy 9y ago
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.
ko27 9y ago
> "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.
- felipeccastro 9y ago
  Don't know why this was downvoted, it is relevant. That's the main reason why hacks like PJAX/turbolinks were invented in the first place, not having to reparse the same JS and CSS for every page change has a noticeable impact in perceived performance.

CryoLogic 9y ago

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.

etblg 9y ago
Could you elaborate in more detail? (I work with Ember.js daily and am happy with it, just curious to see your thoughts)
romanovcode 9y ago
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.

peter_retief 9y ago

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

komali2 9y ago
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.
- peter_retief 9y ago
  I haven't yet met a developer that doesn't like vue
  - reaperducer 9y ago
    I have. I once worked at a shop that tried to rebuild all of its web sites as SPA's with Vue. Four devs, two with deep JS experience, and it was a complete disaster. Vue isn't ready for enterprise, and the documentation is a joke. I don't work there anymore, but looking at the sites now, I can see the old ones are still online — TEN months later, no sign of Vue.
    - komali2 9y ago
      Woah, so looks like we disagree completely. Why don't you like the docs? I love how it has a great introduction guide[1] that really dives deep into the hows and whys, but also has a full API guide when you just gotta know one specific thing [2]. [1](https://vuejs.org https://vuejs.org) [2](https://vuejs.org/v2/api/ https://vuejs.org/v2/api/)

z3t4 9y ago

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.

SwellJoe 9y ago
"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.
- metafunctor 9y ago
  Being able to upgrade the frameworks and platforms you choose to use is a legitimate concern. When did you ever build a relevant application and stop touching it, forever? Any worthwhile software I've ever built has been maintained with continuous effort. On the web especially, "don't keep developing" is just a death sentence.
  - SwellJoe 9y ago
    I'm not suggesting stopping development, I'm saying that the code you got for free (without any dev time) is not a loss, even if you have to do a little extra work to handle upgrades down the road. It's completely nonsensical to say obsolescence is a reason to not use a framework. There's like this weird disconnect in this conversation where we're talking about code that has very low cost to adopt (the framework, where the cost is a day or three or whatever learning how to use it) vs. code that probably has a much higher cost to initially develop from scratch (definitely more than a day or three or whatever, assuming similar functionality; probably weeks, once bug-fixing and cross-browser compatibility is solved). I mean it seems like basic math, to me. It takes X time (+ ~1 day) to deploy with a framework, while it takes X + Y time to implement the app and the framework your app uses (where Y is however long it takes to implement the functionality the framework would have given you). I mean, you're using a framework no matter what; either you use an off-the-shelf one that cost a couple days to learn, or you're building it and maintaining it yourself. How can the framework lose in this math unless it just isn't very good at the tasks it sets out to solve? You may have to do something about the framework in the future, to keep moving forward, but you must do something about your own framework to keep moving forward. If the third party framework you choose is abandoned or forces a migration (ala Angular), you're still not further behind than the framework you built yourself...because you can still develop the third-party framework yourself. It's not a black box. You're signing on to do all of the development work going forward if you choose to build your own framework. You only might need to deal with major changes or long-term maintenance costs, in the off-the-shelf framework. Unless you're only building a tiny app, there's no way this works out in your favor in terms of time-to-launch or in terms of ongoing maintenance. The small frameworks under discussion are single-digit thousands of lines of code; optimistically, that's weeks of work to replicate. And, it's hard to say you're not going to need to implement most of the functionality of a view layer library like Vue or React, if you're building an SPA. I mean, we're not talking about kitchen sink application frameworks here, where the cost of adoption might be high because the learning curve is high (and even then sometimes the math still works out in their favor if your app very closely matches the strengths of the framework...e.g. RoR did this for the backend; it is huge and learning it takes weeks, but a skilled RoR developer can be incredibly productive). This is a pick-and-choose kinda thing. You've got a few legos you can throw into a project to solve the obvious "everyone has to solve it" problems. And, then you build the real app, which does the unique stuff. You get more time for the unique stuff. I dunno, it just seems backward to ignore everything good out there in the ecosystem because you're afraid you might have to change your code in the future to keep using the latest version of the library or framework, or whatever.

ecesena 9y ago

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

dragonwriter 9y ago
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.
- ecesena 9y ago
  I guess both will be useful - not having http(s)://poki.com configured seems also missing the point of the web :)