Bringing Everyone to the PRty
A long-held misconception in development teams is that there is someone on “the other side of the tracks”.
It’s kind of like color war.
Developers and non-developers.
Coders and non-coders.
Those who understand code and those who dress it up and sell it.
Sure, everyone gets along just fine offline. We get lunch together and sometime we even hang out after hours. But as far as workflows go, there are usually pretty clear lines of demarcation.
And GitHub (or any other source code management platform) is usually one of those lines. It’s by and large a developer-only zone and honestly, everyone on the team is cool with that.
The trouble with this approach is that it that it comes with a cost. When everyone works in silos, collaboration becomes messy. Feedback becomes harder to communicate and to understand. Meetings intended to “keep everyone in sync” start popping up way too frequently.
At Livecycle for example, we’ve actually designed our platform to buck these trends. We’ve built a platform for front-end development teams that brings the non-technical stakeholders into the GitHub workflow. Using collaborative PR preview environments, everyone is “invited to the PRty” in a way that actually makes sense.
Only Half the Battle
But the workflow involvement is only half the battle.
A good illustration of this is a recent LinkedIn poll asking “why don’t developers like marketers”. 45% of respondents said it due to lack of communication and the inability to understand and speak to developer personas.
Simply put: many non-technical folks working in tech companies are simply… not technical enough. So inviting everyone to the PRty is not enough. We also need to make sure that everyone feels familiar and comfortable once they arrive.
So in that spirit, this is a quick start guide to some common front end development methods, written with the less-technical folks in mind.
Hopefully this will help to get the whole team better oriented with key concepts and relevant tools.
Frontend Development Methods for Web Apps
Web apps are like pizza: they come in many shapes and sizes, and there are lots of ways to go about creating them.
But just as serving anchovy-laden pizza isn’t always the best way to please a crowd, some Web development techniques are better than others. The best frontend development method for a given Web app will depend on factors like who your users are and how many development resources you have.
To drive home the point, let’s compare three common frontend development methods for the Web – single page applications, static site generation, and server-side rendering – in order to explain when it does and doesn’t make sense to use a certain approach. We’ll also discuss some of the major development frameworks available for each type of app.
Single Page Applications
Single page Web applications are what they sound like: Web applications that consist of just a single page. When the application needs to serve new content to the user, it does so by updating existing content on the page that has already been loaded, instead of loading an entirely new page.
The main advantage of single page applications is speed. When single-page apps make network calls, they load on the data that they need to render for the specific user, then perform the rendering on the client side. This is faster than pulling an entire website’s contents when only part of those contents apply to a given user.
Perhaps the biggest disadvantage of single page apps is that they tend to be relatively complex to build. In turn, they can be more difficult to secure, because it’s easy to overlook security risks when coding the apps. The need to generate new content within the page on a recurring basis can also lead to relatively high resource consumption.
A second major disadvantage of single page applications is that it can be difficult for users to navigate back to historical content once the content has been updated. Even if backwards navigation is possible, it often requires regenerating the previous content from scratch instead of relying on cached content. In this respect, the user experience for single page apps may not be as strong as it is in apps that enable conventional, browser-based navigation.
Finally, single page applications may place a high processing burden on client devices – especially if they rely on a language like JavaScript and client devices lack efficient JavaScript interpreters.
Single page apps work well for use cases where you want to minimize the number of requests between the client and the server, or where you can deliver the best user experience by loading most of your content upfront, then modifying some parts of the page on an as-needed basis.
AngularJS, ReactJS, and Vue are probably the most popular development frameworks for single page apps today. Each of them is pretty easy to work with, and they are relatively lightweight – although AngularJS is a bit heavier than the other two, with the tradeoff being that it tends to offer better performance.
Static Site Generation
The static site generation frontend development method makes it possible to deliver Web content in the simplest form – static HTML – while still building dynamic, auto-generated sites that tailor content for each user.
Static site generation achieves this by generating static HTML pages based on preconfigured templates. The templates define most of the content on each page of your app. But the static site generator allows you to customize specific elements for a given user, then store the resulting page as static HTML.
This frontend development method is sometimes referred to as “headless CMS” because it essentially lets you manage content using a Content Management System (CMS), but without the frontend of a traditional CMS. Technically, a headless CMS and a static site generator are not exactly the same thing – the former is a system for managing site content and the latter is the engine that actually generates static site pages – but in practice the terms are often conflated.
The main advantages of static site generation include:
- Performance: Because content is served as simple HTML files, it’s usually fast to download and requires minimal client-side processing. This adds up to excellent site performance.
- Security: There’s little for hackers to exploit in a static HTML file, as opposed to user-facing pages that include scriptable content. For this reason, statically generated apps tend to be among the easiest to secure, at least from the client side. (On the server side, they’re not necessarily more secure.)
- Simplicity: When you serve your content as HTML pages, you can maintain a simple, minimalist Web server environment.
The biggest drawback of statically generated sites is that you are restricted by whatever site format and structure your templates support. In addition, the need to generate an entirely new page in order to update any content can slow performance in situations where you need to change only one small part of a website. In the latter case, single page applications usually perform better because they can update small content elements more quickly.
Thus, static site generation is a good strategy for use cases where content does not change too frequently. It also works well when your development resources are limited.
Popular static site generators include VuePress, Next.js, Hugo, and Gatsby.
Server-Side Rendering
Server-side rendering is a frontend development technique in which all content is generated by the server, typically using a server-side scripting language. It’s the opposite of a site that requires client devices to generate or process content locally using a framework like JavaScript.
There are two main reasons to use server-side rendering:
- Client-side performance: Server-side rendering minimizes the processing burden placed on the client. For this reason, it’s a useful technique in situations where client-side resources are in short supply. For example, if you’re building applications for low-end mobile phones, server-side rendering may improve performance and user experience.
- Security: Like static site generation, server-side rendering minimizes the risk of client-side exploits because script execution takes place on the server.
The obvious disadvantage of server-side rendering is that it places a high processing burden on the server. In turn, it may lead to higher hosting bills. You’ll also need to maintain server plugins for the various scripting languages you use to generate content, which can increase the complexity of your server environment.
You can create applications via server-side rendering using standard scripting languages, like PHP or Python. However, you can simplify development using a framework (like Django, which is based on PHP, or Flask, which is based on Python) that is designed to help use these scripting languages for building websites.
Better Together: Using More Than One Method
Although each of the frontend development techniques described above can be used independently, you can also combine them.
For example, a single page app and a statically generated site could both be rendered entirely on the server-side (although they could also include client-side processing if desired). You could also have a single page app that is statically generated, an approach that may work well if the content does not need to change at all during each user session.
Conclusion
Modern application developers have a variety of frontend development techniques at their disposal. None is necessarily better than the others; the best choice depends on your use case. And in some situations, you’ll want to take advantage of multiple development methods at once.
We hope this overview helped give you a better understanding of some of the core concepts and tools used in frontend development.
