Is a Single-Page Application what you really need?

by Santiago L. Valdarrama and originally posted on his blog svpino.com

I’ve been developing Single-Page Applications for a while. I started using plain JavaScript, then jQuery, then a bunch of other crazy libraries, to then finally settle with AngularJS. I’ve been a fan since day one, and I believe users can benefit a lot from them.

By now I think I’ve learned what happens when a SPA is used instead of what should have been a regular web site. Nothing surprising here; there’s no silver bullet in any aspect of software development, specially when we are talking about the whole architecture of a web site or application.

My intention is not to make this post a rant about all the drawbacks of Single-Page Applications. Instead, I want to share their current status from my personal perspective and point out those situations where they can hurt more than help.

What’s a Single-Page Application?

If you don’t know what I’m talking about, here is Wikipedia’s definition of Single-Page Applications:

A single-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application.

That’s clear; is a way to bring a more fluid, desktop-alike experience to the web, but the best interesting part about SPAs comes right next:

In a SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions. The page does not reload at any point in the process, nor does control transfer to another page, (…).

If you don’t learn anything else from this post, at least keep in mind how a SPA works and why is useful. Thanks to this architecture, we can develop a better user experience through a more fluid interface by hiding all the complexity inherent to the web (requests, responses, etc.)

How do Single-Page Applications work?

The simplest definition of a web site is basically a set of pages with links between each other. Every time a user clicks on a link, the browser sends a request to the server to retrieve the new page and show it to the user.

In a regular web site, there are usually sections that are repeated across multiple pages: the header, the footer, maybe a side bar with links. The content area is usually the only one changing from page to page. One type of Single-Page Application leverages this fact, and instead of keeping separate physical pages around, embeds the content of multiple pages into one single page, keeping only the right content visible at a time. Whenever a user clicks a link, instead of having to request a full new page from the server, the SPA hides the current content and displays the new content in place.

Another type of Single-Page Application is all AJAX-based. In this case, only a bare minimum of HTML is served to the browser, and whenever the user engages, all the new content is retrieved using AJAX calls. Note that only the content that changes will be requested, keeping the user all the time in the same page with no reloads.

As you can imagine, the experience when using a SPA is faster and more fluid. If the content to display wasn’t downloaded from the beginning, and instead is being requested using AJAX, the experience still feels snappier to the user since only the portion that changes is retrieved behind the scenes. A Single-Page Application does most of the heavy work up-front by downloading everything that’s needed, swapping the content later on in place, or requesting just small portions of it.

Linking becomes an issue

Linking is the main problem with this approach: since a Single-Page Application is not actually keeping multiple physical pages but instead swapping and retrieving content from inside a unique page, there aren’t “real links” going out to “real pages”, but instead the linking schema is used in the browser to decide which particular section needs to be displayed or retrieved from the server.

Have you seen a hash symbol (#) used as part of a URL? It’s called a fragment identifier. This is what Single-Page Applications use to identify what content section to display or retrieve when a link is clicked. An example link in a SPA might look like this: http://www.example.com/#contact-us. Everything after the fragment identifier (contact-us in this case) refers to a subordinate resource to the default page (index.html). Using JavaScript, a SPA uses this information to select the proper section to display.

Note that fragments identifiers are never sent to the server. A request tohttp://www.example.com/page.html#section2 will be sent ashttp://www.example.com/page.html only, leaving the fragment identifier off the request. The fragment identifier needs to be processed then by JavaScript in the client side.

SEO implications

You’d agree with me if I say that Search Engine Optimization is one of the most important topics when building a web site. It doesn’t matter how good is your site if you aren’t discovered by your potential users. Unfortunately, creating a Single-Page Application has huge implications for SEO.

Since your pages are built in the browser, the search engine crawler will see a different version of the page than your users; when the crawler requests a page from your server, you’d either be serving the whole package containing all the content, or just a shell with AJAX hooks to execute and retrieve the proper content after the page is displayed. This, of course, causes the crawler to see either the wrong information, or not information at all, which will not help you to score well in their ranking algorithms.

Also, when the crawler sees a link, it will only request the base URL from the server leaving the fragment identifier off the request. This means that bothhttp://www.example.com/#contact-us andhttp://www.example.com/#about will end up returning the sameindex.html page from the server. If all the different sections are included as part of the the response, both URLs will look exactly the same to the crawler. If the content is accessed using AJAX instead, the crawler won’t see anything useful to index.

This is a big hurdle for web site developers. There’s a solution to this problem commonly referred as the hashbang approach, but it means adding server side code to return a static HTML snapshot of the page to the crawler and the regular code to the browser. Setting this up correctly makes the whole SPA approach very complicated and inconvenient.

Performance implications

Once the user starts interacting with a Single-Page Application, the whole experience will feel better than a regular web site, but depending on what approach is used to deliver the content to the browser, we might create a performance problem.

When using AJAX calls to retrieve different sections of the site, performance is less of an issue than when the whole content is embedded into one single HTML file and delivered all at once during the first request. Instead of downloading only what the user needs, we are forcing them to wait for the whole site before even knowing if they are going to visit past our home page.

Depending on what type of web site you are building, using this approach may be prohibitive for your users; they just don’t have the patience to sit tight while you display a blank page waiting for all the content to come through. This problem is amplified for mobile devices which usually suffer from very slow connections.

JavaScript support

I know. I shouldn’t be talking about this in 2014, but the fact is that JavaScript support is still an issue all across the globe. It’s not only a matter of what browser are our users using, but whether or not they have JavaScript enabled on the first place.

I can name (but won’t) a couple of high-profile companies with entire departments using IE8 with no JavaScript. If you want to count those users as yours, you need to stay away from web sites that heavily rely on JavaScript to present the content. It’s okay if they get a stripped-down version of your page with limited functionality, but it’s unacceptable if they can’t access it at all.

Conclusions

Does this mean Single-Page Applications are not useful? Not at all! I love them and they solve a real problem, but we need to make sure we use them only when they make sense.

I’ve found out that the sweet spot for a SPA are web applications instead of regular web sites. Web apps are not usually searchable (most of them are hidden after some sort of authentication wall anyway), so SEO is not an issue. Your users are already committed to the app. They want to use it, so they are willing to navigate any hurdles to get the benefits you are offering them by using a SPA.

A regular discoverable and public web site on the other hand is a different story. You need to weight all the pros and cons before making the decision of going with a SPA. It’s never a clear cut, so make sure you explore the implications before committing for the long term.

9 Reasons You Should Know a Little HTML and CSS

By ADDA BIRNIR for The Muse and posted on MASHABLE.

keep-calm-and-learn-to-code-2

You’ve heard over and over that everyone should learn to code. Alright already! But as a writer, marketer, finance guru or nonprofit worker, why in the world should you get into coding?

Well, I‘m here to tell you that even a little knowledge of HTML and CSS can make a big difference in your career. And learning tech isn‘t just for the production assistants and print designers of the world — whether you‘re a small business owner, a sales manager, an event coordinator or even a magician, you can benefit from some HTML and CSS chops.

Sound too good to be true? It‘s not, and I‘ll give you nine examples to prove it.

But, first, let‘s review what exactly HTML and CSS are. The short and sweet version is: HTML and CSS are the foundations of the web. HTML — HyperText Markup Language — is the language used to tell your web browser what each part of a website is. So, using HTML, you can define headers, paragraphs, links, images, and more, so your browser knows how to structure the web page you‘re looking at.

CSS — Cascading Style Sheets — is the language that gives those web pages their look and formatting. In other words, CSS is what you use to make sites look nice with fancy fonts, rich colors, gorgeous backgrounds, and even slick animations and 3D effects.

Easy, right? But you‘re probably still wondering: How am I supposed to use these coding languages in my job? Well, here are just a few of the amazing things you can achieve with just a few lines of these easy-to-learn languages. Trust me — your boss or potential employer will be impressed, your colleagues will be happy and you may be well on your way to a more fulfilling and lucrative career.

Here are nine things you will be able to do with your HTML and CSS skills:

1. Design an awesome email for your customers

Email is turning out to be one of the best online marketing tools out there. And you can make an email that your customers will actually look forward to getting by organizing and styling it using the HTML and CSS editors available with most email marketing services.

2. Create a stunning corporate newsletter

Now that you‘ve impressed with those gorgeous emails, take it to the next level with a newsletter template. HTML and CSS will be your secret weapons once again as you lay out and customize the template to fit right in with your corporate brand and style.

3. Tweak your company‘s WordPress site

A surprisingly high percentage of corporate websites are built on WordPress. And this is good news for you when you know some HTML and CSS, because you can use them to add content and make changes to your company‘s site. That means no more waiting around for your overworked web team to update the office calendar!

4. Teach your colleague (or boss!) some code

Speaking of overworked co-workers, how about sharing the HTML and CSS love with your colleagues (or even your supervisor)? Then everyone on your team will be able to update and improve the website, emails and newsletters. Ahh, the joy of delegation!

5. Make your technical team adore you

The developers in your working life will thank you if you understand even a hint of HTML and CSS. You‘ll know how to tell them what needs to be changed on the company site (instead of referring to everything as a “whatchamacallit“ or “thingamajig“ as well as be more aware of the limits and possibilities they face every day.

6. Show off your skills with a perfectly-tuned Tumblr blog

Want to leave that adoring team behind and turn your passion into your profession? It‘s easy enough to set up a Tumblr blog to show off that side hustle you‘ve been working on. If you want to send a dazzling display of your freelance photography or graphic design work to that agency that‘s hiring, you can! Just a bit of HTML and CSS can take a Tumblr template from so-so to stunning.

7. Build a professional resume site — from scratch!

Go beyond just a Tumblr blog and really show some initiative by coding your own online presence from start to finish. It might sound daunting, but it‘s actually surprisingly easy to create a simple but great-looking site with basic HTML and CSS. And, boy, will you knock the socks off potential employers when you tell them you did it all on your own!

8. Take your design skills to the next level

So you‘re already a Photoshop wizard, and you can even create some impressive website mockups. Well, get some HTML and CSS under your belt, and you‘ll be able to turn those mockups into actual sites. You can become the “unicorn“ (a designer who can code) every company is looking for right now.

9. Start learning more — and earning more!

Like I said at the start, HTML and CSS are the foundation of the web. So, they‘re also the foundation for taking your tech skills to the next level. Having a handle on the fundamentals will make learning another programming language (like JavaScript, Ruby or PHP) a whole lot easier. And the more you know, the more job opportunities will open up for you.

Developers – This is where the money is

By Jillian Kumagai and first published on MASHABLE.

Seattle is home to Microsoft, and Silicon Valley is home to Apple — that much is obvious. But if you want to see where the rest of America’s developers live, you’ll need to take a bit of a road trip.

While California boasts the highest number of developers of any U.S. state (followed by Texas, New York and Washington), the Northeast takes the top regional spot when it comes to average salary, with $89,318. Washington, however, reigns supreme as the individual state with the highest salary: an average of $109,244.

There’s only one landlocked state that made the top 10 list according to salary — Colorado, where the average developer earns $94,424.

In the following infographic, the folks at Lucidworks redrew the U.S. map according to developer population. To find out more about those who code from sea to shining sea, take a look below.

LW_DevMap_D2b_1920px

The 10 Tech Terms You’re Mixing Up

This article appeared on MASHABLE and is written by  originally for The Muse.

Tech_terms

Do you ever find yourself trying to hide your confusion at work meetings while the tech team is tossing around terms like UI and UX? Or maybe you’re all about downloading the latest apps, but you’re not totally sure what “app” actually means.

Well, it’s time to stop faking it and start learning some of today’s most important tech vocabulary. We’re here to define 10 tech terms that you hear on the daily, and we’re using plain English (as in, even your Gramps would understand). No more excuses—here’s your chance to get in on the conversation, and earn a little tech street cred, too.

The Internet vs. the Web

Wait, there’s a difference? Oh, yes! (And no trying to avoid this one by referring to them both as “the interwebs.”)

The internet is actually millions of computers interconnected in a global network. (Get it? Interconnected + Network = Internet.) All of these computers can talk to each other to send and receive data around the world as fast as you can favorite a tweet.

The web, on the other hand, is the system where some (but not all) of that data is kept in the form of special documents. These documents are linked together and more commonly known to you and me as web pages.

To put it simply, the internet is the equipment and connections, and the web is the information. Fun fact: While “world wide web” was the hottest term for the web a few years ago, Millennials prefer to call it “the cloud.”

HTML vs. CSS

Speaking of the internet, here’s a bit more about how the websites on it are made. HTML — or HyperText Markup Language — is the language used to write web pages. HTML is made up of “elements” (paragraphs, headers, lists, links, and the like), which give each web page structure and contain the content of the page itself (text, images, videos, and so on).

CSS — or Cascading Style Sheets — tell web browsers how to format and style an HTML document. In other words, CSS is what makes HTML look good. Using CSS, you can give a web page its own font, text styles, colors and, with the newest CSS version (CSS3), even multiple backgrounds, 3D transformations, and awesome animations.

To put it simply, HTML holds the content in place, and CSS makes it look pretty.

Front End vs. Back End

Now you know how websites are made, let’s talk about how they work. The front end of a website is the part that you can see. This includes HTML and CSS (see how handy it is to know those terms!) and all the other things you look at in your browser. Think Facebook posts that update or Google search terms that autocomplete—these are all thanks to the powers of the front-end programming language JavaScript.

The back end of a website is the part of a website that makes it work. It includes applications that tell websites what to do, servers where websites get data from, and databases where information websites use is stored.

On Twitter, for instance, the look of your feed is the front end, and all the data is stored in the back end.

App vs. Software

Speaking of telling computers what to do, you’ve probably heard the term “application” before. In a nutshell, an application, or app, is a program or set of instructions that you can use to do certain things on your iPhone or Android.

The general term for any instructions for your computer, tablet, or phone is software. So, apps are just one type of software. But, system software—like operating systems (Think iOS7 or Windows 8), drivers (controls for your printer or speakers, for example), or utilities (like anti-virus or backup)—are a different type of software that run your computer as a whole and make it possible for you to use all those apps you’re addicted to.

That means: All apps are software but not all software is an app.

UX vs. UI

Even pros can get mixed up about these two abbreviations, but let’s make sure you don’t. UI — or User Interface — is how a product or website is laid out and how you interact with it: Where the buttons are, how big the fonts are, and how menus are organized are all elements of UI.

But UX — or User Experience — is how you feel about using a product or a website. So, your love for the way the new Apple Watch looks or your excitement that there’s finally a tablet-sized iPhone to watch those Corgi videos you’re obsessed with are reflections of UX.

So the new look of the Facebook news feed involves a change to UI, and the way you navigate that new page is the UX.

Now that you’re clear on some of the the most used-and-abused tech terms, get out there and prove to your co-workers (and maybe even your Instagram followers) that you know what’s what in tech today.

[ Here’s a recent article posted on my blog about the differences between UI and What’s the difference between UI and UX design? ]