11 ms·

A lot of people seem to think that Single Page App frameworks like Angular/Ember are suitable for use on the public facing client side. I've always believed tha

by dchuk 13y ago

A lot of people seem to think that Single Page App frameworks like Angular/Ember are suitable for use on the public facing client side. I've always believed that SPAs are meant to be behind a login, where you don't have to also deal with spiders and other sub-optimal browsing devices, and you have a little bit more wriggle room when it comes to routing and web history. Just look at Blogger...their client-side rendering is annoying as all get out. It's just a blog post, render it server side and give me the content, then sprinkle on some gracefully degrading JS on top to spice it up. I say this as a huge proponent of Angular who uses it for all his web app projects who also wouldn't ever use it on a public facing application.

camus2 13y ago
i agree 100%. Most websites shouldnt be SPAs. One can still use Angular to code widgets in a regular page based site,without using a js router. It's just that devs are getting lazy ,they throw a restfull server app quickly then dont want to deal with any view layer on the server and do everything in client-side js. For some projects it make little sense.
- fixermark 13y ago
  I think the key word is "App." There is a difference in nature between a web app and a web page. Both can be built using the same underlying technologies, but the goals are very different. Knowing which one is building can greatly inform choice of framework.
jaunkst 13y ago
Exactly, tried to hit that in my post
lifeisstillgood 13y ago
Agreed - there is a wealth of applications that are not in the massive scaled consumer market - and making those clean, easy to maintain and deliver is an enormous win. That said, there is a wealth of consumer apps that don't have massive market shares either so the market for learning these lessons is pretty rarefied
EC1 13y ago
What would you use for a public facing application?
- dchuk 13y ago
  Any sort of standard server side rendering, or possibly a front end framework that can be rendered server side as well (I think React can do that, same as Backbone). Basically, SPA frameworks are useful when you are working with lots and lots of data moving back and forth. A good example is something like Intercom.io's interface. They have tons of tables and modals and data flying around. This isn't conducive to the standard browser request -> server render -> load whole new page on the client. It's just too slow. When you're interacting purely with data in a master interface, SPA frameworks are the way to go. And it isn't even a matter of literal page loading and rendering speed, it's the fact that refreshing the view with a whole new page on each link click is a context change that adds up when you're managing a lot of data or performing a lot of small tasks in an application. But something like Blogger, where you're reading just some content, maybe some comments...there's no real benefit from loading it in a SPA environment. Render it server side, cache it, and fire it to my browser as fast as possible.
  - elliottkember 13y ago
    > Render it server side, cache it, and fire it to my browser as fast as possible. Shameless plug, but we've been trying to do something similar with Forge (getforge.com). We built a Javascript library called TurboJS that precompiles a static HTML build into a JS manifest and loads it all. It's SEO-friendly and super-fast. Our other site, http://hammerformac.com/ http://hammerformac.com/ uses it, for example.
    - btown 13y ago
      Precompiling static HTML is a strict sub-problem of the problem most people in this comment thread are referring to, which is development incentives and SEO characteristics for web pages that have non-trivial amounts of dynamic content.
- 13y ago
anonova 13y ago
Discourse is essentially a SPA (see http://try.discourse.org/ http://try.discourse.org/) and designed to be public-facing. It does a good job at providing a very bare, lightweight interface for people with JavaScript disabled and, I'm assuming, for web crawlers.
- johnx123-up 13y ago
  FWIW.. it looks overkill for me
  - hiphopyo 13y ago
    I'd much rather use Forem.
  - teh_klev 13y ago
    ...because?
- pa5tabear 13y ago
  Do they use open source libraries? And otherwise how do they differ from something like Angular?
  - Argorak 13y ago
    Discourse is open source: https://github.com/discourse/discourse https://github.com/discourse/discourse It uses ember.js with a Rails backend.
encoderer 13y ago
Totally agree, but you still have the analytics/tracking problems. Unless you're not tracking clicks/activities/views on your various features. But if that's the case, you have bigger problems :)
- tatalegma 13y ago
  Can anyone elaborate on the problems? Are there problems with analytics while using Angular?
darrellsilver 13y ago
The Blogger example doesn't seem fair: Any app can overload the user with too many animations or other distractions. At Thinkful (http://www.thinkful.com/ http://www.thinkful.com/) we're building our student / education app in Angular, and are moving all browser-side code to Angular as well – both public and private. In a lot of our splash or SEO-enabled content we're not making use of all of angular's features, but the upside of using it is that we have a single, unified codebase in which we can share libraries, team knowledge and design patterns. Simply put: Using Angular everywhere allows us to keep DRY. Testing the front-end using purely Angular is yet another core asset at Thinkful. One framework for writing code and testing is much better than a hybrid of server-side rendering and Angular. Our biggest challenge was SEO, but this was reasonably easily solved with using BromBone (http://www.brombone.com/ http://www.brombone.com/). There are reasons to stick with non-angular or JS frameworks, so it's not always a slam-dunk. For example, if Thinkful had millions of SEO pages that we needed to load as fast as humanly possible Angular would be a bit much... But that's not what we're optimizing for: We're building a phenomenal user-experience that we can support long-term, is well tested, can have a lot of developers use, and can have non-developers do their job inside our codebase (everyone at Thinkful codes). For all this and more Angular has proven a great choice for both logged-in AND public sites.
grey-area 13y ago
I agree that things like blogger are a great example of what not to do, but I'd go further and say that treating something as a single page web app running on the client side throws away most of the advantages of the web: URLs which can be stored and shared and are idempotent Mostly stateless operation for anonymous use (fast to serve/load/cache) Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways What you call suboptimal browsing devices are what makes the web special and distinct from native apps. These are not trivial advantages, and most websites would benefit from these strengths of the web, even if they are an app. As an example of where something like a single page app can shine on a public site, I've seen chat software which used it which worked really well (using socket.io I think), but only because people didn't care about sharing individual messages and the chat was ephemeral.
- davedx 13y ago
  > URLs which can be stored and shared and are idempotent If you use a decent router, you get shareable idempotent URLs: https://solvers.io/projects/7GTeCKo7rGx5FsGkB https://solvers.io/projects/7GTeCKo7rGx5FsGkB > Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways As in the article, you can use phantomjs to serve up static HTML to crawlers. They are correct in that it does slow you down and add complexity. The main problem I think is that SPA tech is still immature and getting all the moving parts to build a public facing SPA working together is a time sink.
  - grey-area 13y ago
    It's not really a single page application if you are serving separate pages is it? BTW, the page you linked to says 'Uh-oh! Couldn't find that page.' before loading and displaying the content... ouch. One of the things I love about the web is that it uses incredibly simple building blocks like simple html pages at defined stateless URLs, dumb servers and dumber clients, and builds complex systems through their interaction. I'd be very wary of solutions that drop those advantages. There are certainly technical solutions possibly to almost any problem with angular or client-side apps in general, but I'm not sure that rendering everything client-side really gives you enough advantages to warrant it for many websites. What do you see as the main advantages to this approach and do you see it spreading everywhere eventually? Every website is different and what suits (say) a chat application will not suit a document-orientated website at all. There's certainly room to explore both approaches or even mix them at times.
novaleaf 13y ago
fyi, services like PhantomJsCloud (mine) exist that let you avoid rendering SPA/Ajax yourself. Here's a link with all the nginx config you need to make it work: https://phantomjscloud.com/site/docs.html#advanced_seo https://phantomjscloud.com/site/docs.html#advanced_seo
blueskin_ 13y ago
They don't belong there either. Some people use screen readers, text-mode browsers, IE due to stupid work/school policies, etc. Some people like automating their workflow, which can involve scripted browser interactions. Some people actually care about security and privacy, and so run NoScript, etc.
- marknutter 13y ago
  And some people still use IE6, but that doesn't mean you should continue to support IE6.
  - blueskin_ 13y ago
    So based on that logic, you can abandon all standards of usability and interoperability?
    - cheriot 13y ago
      Screen readers and browser automation can run javascript. Sure, it may be more pure and perfect for everyone write websites that don't require javascript, but the economics of building websites doesn't support it.

by dchuk 13y ago

camus2 13y ago

i agree 100%. Most websites shouldnt be SPAs. One can still use Angular to code widgets in a regular page based site,without using a js router. It's just that devs are getting lazy ,they throw a restfull server app quickly then dont want to deal with any view layer on the server and do everything in client-side js. For some projects it make little sense.

fixermark 13y ago
I think the key word is "App." There is a difference in nature between a web app and a web page. Both can be built using the same underlying technologies, but the goals are very different. Knowing which one is building can greatly inform choice of framework.

jaunkst 13y ago

Exactly, tried to hit that in my post

lifeisstillgood 13y ago

Agreed - there is a wealth of applications that are not in the massive scaled consumer market - and making those clean, easy to maintain and deliver is an enormous win. That said, there is a wealth of consumer apps that don't have massive market shares either so the market for learning these lessons is pretty rarefied

EC1 13y ago

What would you use for a public facing application?

dchuk 13y ago
Any sort of standard server side rendering, or possibly a front end framework that can be rendered server side as well (I think React can do that, same as Backbone). Basically, SPA frameworks are useful when you are working with lots and lots of data moving back and forth. A good example is something like Intercom.io's interface. They have tons of tables and modals and data flying around. This isn't conducive to the standard browser request -> server render -> load whole new page on the client. It's just too slow. When you're interacting purely with data in a master interface, SPA frameworks are the way to go. And it isn't even a matter of literal page loading and rendering speed, it's the fact that refreshing the view with a whole new page on each link click is a context change that adds up when you're managing a lot of data or performing a lot of small tasks in an application. But something like Blogger, where you're reading just some content, maybe some comments...there's no real benefit from loading it in a SPA environment. Render it server side, cache it, and fire it to my browser as fast as possible.
- elliottkember 13y ago
  > Render it server side, cache it, and fire it to my browser as fast as possible. Shameless plug, but we've been trying to do something similar with Forge (getforge.com). We built a Javascript library called TurboJS that precompiles a static HTML build into a JS manifest and loads it all. It's SEO-friendly and super-fast. Our other site, http://hammerformac.com/ http://hammerformac.com/ uses it, for example.
  - btown 13y ago
    Precompiling static HTML is a strict sub-problem of the problem most people in this comment thread are referring to, which is development incentives and SEO characteristics for web pages that have non-trivial amounts of dynamic content.
13y ago

anonova 13y ago

Discourse is essentially a SPA (see http://try.discourse.org/ http://try.discourse.org/) and designed to be public-facing. It does a good job at providing a very bare, lightweight interface for people with JavaScript disabled and, I'm assuming, for web crawlers.

johnx123-up 13y ago
FWIW.. it looks overkill for me
- hiphopyo 13y ago
  I'd much rather use Forem.
- teh_klev 13y ago
  ...because?
pa5tabear 13y ago
Do they use open source libraries? And otherwise how do they differ from something like Angular?
- Argorak 13y ago
  Discourse is open source: https://github.com/discourse/discourse https://github.com/discourse/discourse It uses ember.js with a Rails backend.

encoderer 13y ago

Totally agree, but you still have the analytics/tracking problems. Unless you're not tracking clicks/activities/views on your various features. But if that's the case, you have bigger problems :)

tatalegma 13y ago
Can anyone elaborate on the problems? Are there problems with analytics while using Angular?

darrellsilver 13y ago

The Blogger example doesn't seem fair: Any app can overload the user with too many animations or other distractions. At Thinkful (http://www.thinkful.com/ http://www.thinkful.com/) we're building our student / education app in Angular, and are moving all browser-side code to Angular as well – both public and private. In a lot of our splash or SEO-enabled content we're not making use of all of angular's features, but the upside of using it is that we have a single, unified codebase in which we can share libraries, team knowledge and design patterns. Simply put: Using Angular everywhere allows us to keep DRY. Testing the front-end using purely Angular is yet another core asset at Thinkful. One framework for writing code and testing is much better than a hybrid of server-side rendering and Angular. Our biggest challenge was SEO, but this was reasonably easily solved with using BromBone (http://www.brombone.com/ http://www.brombone.com/). There are reasons to stick with non-angular or JS frameworks, so it's not always a slam-dunk. For example, if Thinkful had millions of SEO pages that we needed to load as fast as humanly possible Angular would be a bit much... But that's not what we're optimizing for: We're building a phenomenal user-experience that we can support long-term, is well tested, can have a lot of developers use, and can have non-developers do their job inside our codebase (everyone at Thinkful codes). For all this and more Angular has proven a great choice for both logged-in AND public sites.

grey-area 13y ago

I agree that things like blogger are a great example of what not to do, but I'd go further and say that treating something as a single page web app running on the client side throws away most of the advantages of the web: URLs which can be stored and shared and are idempotent Mostly stateless operation for anonymous use (fast to serve/load/cache) Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways What you call suboptimal browsing devices are what makes the web special and distinct from native apps. These are not trivial advantages, and most websites would benefit from these strengths of the web, even if they are an app. As an example of where something like a single page app can shine on a public site, I've seen chat software which used it which worked really well (using socket.io I think), but only because people didn't care about sharing individual messages and the chat was ephemeral.

davedx 13y ago
> URLs which can be stored and shared and are idempotent If you use a decent router, you get shareable idempotent URLs: https://solvers.io/projects/7GTeCKo7rGx5FsGkB https://solvers.io/projects/7GTeCKo7rGx5FsGkB > Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways As in the article, you can use phantomjs to serve up static HTML to crawlers. They are correct in that it does slow you down and add complexity. The main problem I think is that SPA tech is still immature and getting all the moving parts to build a public facing SPA working together is a time sink.
- grey-area 13y ago
  It's not really a single page application if you are serving separate pages is it? BTW, the page you linked to says 'Uh-oh! Couldn't find that page.' before loading and displaying the content... ouch. One of the things I love about the web is that it uses incredibly simple building blocks like simple html pages at defined stateless URLs, dumb servers and dumber clients, and builds complex systems through their interaction. I'd be very wary of solutions that drop those advantages. There are certainly technical solutions possibly to almost any problem with angular or client-side apps in general, but I'm not sure that rendering everything client-side really gives you enough advantages to warrant it for many websites. What do you see as the main advantages to this approach and do you see it spreading everywhere eventually? Every website is different and what suits (say) a chat application will not suit a document-orientated website at all. There's certainly room to explore both approaches or even mix them at times.

novaleaf 13y ago

fyi, services like PhantomJsCloud (mine) exist that let you avoid rendering SPA/Ajax yourself. Here's a link with all the nginx config you need to make it work: https://phantomjscloud.com/site/docs.html#advanced_seo https://phantomjscloud.com/site/docs.html#advanced_seo

blueskin_ 13y ago

They don't belong there either. Some people use screen readers, text-mode browsers, IE due to stupid work/school policies, etc. Some people like automating their workflow, which can involve scripted browser interactions. Some people actually care about security and privacy, and so run NoScript, etc.

marknutter 13y ago
And some people still use IE6, but that doesn't mean you should continue to support IE6.
- blueskin_ 13y ago
  So based on that logic, you can abandon all standards of usability and interoperability?
  - cheriot 13y ago
    Screen readers and browser automation can run javascript. Sure, it may be more pure and perfect for everyone write websites that don't require javascript, but the economics of building websites doesn't support it.