Web Development

Front End Does What?

Posted by bgoldstein & filed under Web Development.

On November 4th A List Apart hosted their latest online panel, “The State of Front End Development”. At Spry Digital, we love any chance to get together as a team, eat some great food, and learn how to improve at our craft, so we turned the panel discussion into a lunch and learn, something we do just about every week.

On the panel were some of the leading Front End Developers in the US today, like Una Kravets (@Una), Rebecca Murphey (@rmurphey), Jina Bolton (@jina), and Marco Rogers (@polotek). The panel was moderated by Chris Coyier (@chriscoyier) of css-tricks.com.

They all work on some of the most interesting and complex front end development problems around for companies like IBM and Salesforce, and startups like Clover.


The entire hour long panel is embedded above, but if you don’t want to take an hour to watch the whole thing, we’ve recapped it for you here.

What Is It You’d Say You Do Here?

The panel started with the question of “What is front-end development today?” Chris began by listing various web technologies like HTML (check) and CSS (check). Where this question got interesting were two points of contention. The first was on JavaScript, which is such a broad topic and has seemingly a new framework du jour every month. What everyone came to agree on was that, yes, knowing how to use JavaScript at some level is definitely part of being a front-end developer. Moreover, they all agreed that being an expert at Angular or React or another particular framework wasn’t necessarily that important.

The other point of contention was on related-but-definitely-distinct disciplines like User Experience, Visual Design, Optimizing Performance, and server side programming languages like Ruby, Python and PHP. The consensus was that good Front End Developers definitely do not have to latter day webmasters, or full stack engineers, but need to be aware of the issues and concerns that other designers and developers might to bring to a project.

I really liked hearing that; one of the reasons I joined Spry Digital is our belief that crafting great, nimble web products is a team sport.

This conversation about awareness of different disciplines led to a great discussion on the usefulness of “Front End Developer” as a title. The panelists didn’t come to a conclusion – there’s both the problem of the title not being very descriptive of the work and the problem of it not being terribly indicative of the technical skill a front end developer might have. One panelist quipped that the job title front end developer could include both “someone who can barely use jQuery and someone who could recreate jQuery”.

If the title isn’t meaningful, does it matter whether you are a generalist, or should you specialize in a specific framework or technology? Fortunately this question was easier to answer: not only is front end development broad enough to include specialization under it, but most of those specialities are in demand. If you have or are willing to develop a speciality, you can basically pick where you want to work and the problems you want to solve.

Leveling Up

Piggybacking on the conversation about technical skill was a conversation about what determines a Junior Front End Developer from a Senior Front End Developer.  Unanimously the panel agreed that years of experience doesn’t play a determinative role in whether someone is Senior or Junior. Rebecca Murphey did comment however that experience does yield know-how in solving problems and working with colleagues. What most of the panel agreed on was that a Senior Developer has to be able to multiply the effectiveness of the team. This can happen in many ways, whether by teaching Junior Developers and improving their skills, or helping the team work better together. In fact, some of the panelists suggested that the only difference between a Senior and Junior Developer might be their ability to be a “force multiplier.”

Sine Qua Non

All of the panelists agreed that a healthy intellectual curiosity and a willingness to embrace changing technologies, standards, and practices was necessary for every front end developer, regardless of seniority.

It was a great panel that really helped me and our whole team at Spry think a little bit more clearly on what Front End Development is and is not, and what we should be expecting from Senior Developers as we continue to grow as a company.


A smattering of the tweets I live tweeted out during the panel:

Other people’s best tweets:

Have your own thoughts about what it means to be a Front End Developer? Share your comments with us below.

Why we choose the Zurb Foundation theme for Drupal

Posted by kGoff & filed under Web Development.

One of the most important decisions in building a new Drupal website, and, consequently, one of the first steps, is selecting a theme or theme framework. Currently, there are 1,316 themes available on drupal.org.

During our time as a Drupal developers, we have used the following themes: Omega, Zen, Bootstrap, and Foundation. While each of these themes has a variety of strengths and weaknesses, the Foundation theme by Zurb has quickly become our “go-to” theme.

The Foundation theme is built with the Foundation front-end framework. The Foundation framework is a grid-based, mobile-first CSS framework so one can greatly speed up the processes of front-end development for responsive websites.


The CSS-based grid system isn’t the only feature Zurb packs into the Foundation framework. It also includes several user interface elements and JavaScript libraries to enhance the user experience.

The fact that it’s a mobile-first framework is one of the main reasons why we chose the Foundation framework. Out of the box, the theme comes with standard breakpoints for mobile, tablet, and desktop. You can easily create your own breakpoint to supplement the default breakpoints.


Another great feature of the Foundation framework is that it is built to work seamlessly with SASS. SASS is a pre-processor for CSS. If you are not familiar with SASS, then you are in for a treat. SASS allows you to use variables, nested rules, mixins, and inline imports to streamline your CSS development. SASS files are compiled into CSS via a SASS compiler. If you are new to SASS or would like to learn more about it, click here for a great resource to help get you up to speed.

But what we like best about Foundation is that it’s not Drupal-specific. In addition to several Drupal sites, we have built WordPress sites using Foundation, as well as custom applications built with PHP frameworks like Laravel. Using a common front-end framework regardless of platform means that front-end developers can work faster and smarter, and worry less about platform-specific methods to achieve the same functionality.

We encourage you to check out the Zurb Foundation theme before diving into your next Drupal project. There may be a slight learning curve if you’re new to Foundation, but learning the framework will be time well spent. Foundation has a great community that is always willing to help if you have any questions about the framework. That said, feel free to shoot us an email or comment with any and all questions!

Spry at UMSL Women’s Hackathon

Posted by Ben Scherliss & filed under Web Development.

For 11 straight hours in November, female IT students from the University of Missouri-St. Louis participated in the school’s first “Women’s Hackathon.” They were joined by experienced programmers from area companies such as Enterprise, MasterCard, Boeing and our own Julia Koelsch of Spry Digital.

The challenge presented was to form teams and build a game, web application, mobile app or desktop app designed to help organizations or communities prepare for an effective response for natural disasters. By the end of the event, the 30 students had created ten different prototyped applications. The entire session was provided to the participants for free.

We sat down with Julia to talk about the experience and learn more about the event.

Why was it that Spry wanted to participate this particular event?

It sounded really interesting for both participants and mentors. And events like this help students get interested in software development while learning from and interacting with professional developers.

What was your favorite part about the experience?

I loved working with my team and I was proud of the app we built. It helped people to communicate after a natural disaster. The idea was that you could set up account ahead of time, and if disaster hit in your area you would let the app know if you were OK. At minimum, it reduced the amount of people calling around all at once and reduced strain on communication towers.

What was the most valuable thing the students learned?

There was a brainstorm session first, which helped everyone get great ideas going, then narrow them all down. This approach helped emphasize that the best ideas or apps might just be the ones that you didn’t think about at first. They also provided the teams with Legos and asked us to demonstrate the app using the legos. This made you think more of logistics, which was not something I’d thought about before.

What were some examples of the disaster scenarios and the applications the teams came up with?

The groups were able to make up their own natural disasters. Our group focused on helping people communicate with each other after disaster, and others focused on connecting people with items to others who needed them. Some connected volunteers with volunteer opportunities. Others were games for kids which could be used to teach the kids what do if something happened.

Did the students seem well-prepared for the challenges?

Yes. Most of them had some background in the field and they were programming students. They all knew the basics and did well.

Why was it called a “Hackathon?”

The term means a combination of hack and marathon. This particular hackathon was only for one day, so it was even more condensed than your typical weekend hackathon. You have to get as much done as you can in the time given. The participants don’t come in as a pre-formed group, instead teams are formed randomly. Then you have to quickly decide what you are building based on strengths and talents of who is on the team.

Is there anything else you’d want people to know about the whole experience?

Overall it was just a great experience, and I hope UMSL continues to host this event.

This particular hackathon was specifically for women students, which is a great idea. The tech industry is still struggling with how to attract and retain women, and events like these are encouraging and supportive of women interested in a technical career. It’s a thrilling feeling to work together as a group and produce tangible results in such a short amount of time. The joy and feeling of satisfaction I get from building sites and apps is what I love about my career, and I am so happy I could share that feeling with future app developers.

Improving Productivity with Atom Editor

Posted by Phil Ecker & filed under Web Development.

As a web developer, I’m always looking for new applications/technologies to improve my efficiency. With a large percentage of my time being spent in a code editor, what better place to look to improve productivity?

Why I Chose Atom

In the past, my code editor of choice was Coda 2, but after a recommendation I switched to Sublime Text as my primary editing tool. Sublime Text had a lot of great features, but one feature it lacked was the ability to position the sidebar. I decided to explore some other options to see if there was a better fit for me. Of the editors out there, I considered Brackets, Coda 2, Sublime Text 3, Light Table and Atom. After trying Atom, it quickly became very comfortable to use and better yet, I was able to choose the position of my sidebar!

What really sold me on Atom is the fact that Github built Atom on common web technologies like HTML, CSS, Node and JavaScript so it’s easily customizable without having to learn another language.

Atom Packages

One of the easiest ways to customize Atom is with the community built packages. My top 5 packages are listed below:


Emmet isn’t exclusive to Atom, but it was definitely a selling point when making the switch. Emmet is a plugin for many popular text editors which greatly improves HTML and CSS workflow. It makes it possible to quickly write large amounts of code. If I could only install one package, this would definitely be it.

Sublime Tabs

As the name implies, this a package that mimics the way tabs work in Sublime Text. The main benefit of Sublime Tabs is that it allows you to quickly preview a file without having to open it. This greatly assists in preventing tab clutter in your environment.


Minimap is nice for being able to quickly scan large files. I find it especially useful for looking for code within projects using Foundation. I can look at Minimap to find sections in the file where I have uncommented variables, etc.

Autocomplete Plus

Autocomplete Plus works in conjunction with Emmet – it provides a dropdown list of options as I type, which increases the speed in which I can write code.

File Icons

File Icons isn’t as elaborate as some of the other packages, but I find this to be useful when you’re looking at hundreds of files in the tree view. It visually separates the files, making it quicker to locate the file I’m trying to find.

Atom Themes

Other ways you can modify Atom to be the editor you want is with a combination of available themes for Atom. My personal choice is the default Atom Light UI theme with the Dimmed Monokai syntax theme.

Atom Light UI with Dimmed Monokai Syntax Theme

Themes are another way that Atom allows you to have exactly what you want in an editor, instead of making those choices for you.

The difference between good and great is in the small details that might not be important to someone else. The great thing about Atom is if it’s not exactly what you want out-of-the-box, you can customize it. Between the default features of Atom, the community contributions of Packages/Themes, and it’s overall ease-of-use, Atom quickly became my default editor. It has increased my productivity as a developer, and hope it does the same for you.

The Pixel Is Dead, SVG’s Are Killing Them

Posted by Phil Ecker & filed under Web Development.

What? The pixel is dead? Ok, maybe not 100%, but it’s well on it’s way and I’ll tell you why: SVG’s are killing them. First, for those of you who don’t know much about SVG’s, SVG stands for Scalable Vector Graphics. What does that mean? Simply put, it’s a graphic that is created with XML. All modern web browsers have some form of support for SVG, and there are sites like Can I Use that show what browsers support SVG’s.

Here is my list of the reasons SVG’s are better than pixel based images.

SVG’s are:

  1. Easily editable – SVG’s can be edit via a text editor being they are XML based or can be created through program like Sketch, Inkscape or Illustrator.
  2. Searchable and Indexable – Adds additional content to your site that can be searched/indexed by Google.
  3. Look great on retina displays – They don’t require libraries like retina.js or multiple versions of an image which reduces number of page requests.
  4. Scales without distorting – Since SVG’s are created with code they can be scaled without becoming pixelated, allowing you to use one image at different sizes.

There are instances where you’ll still need to use something other than SVG’s. For example, anything older than IE 9 would require the use of non-SVG images. In theses cases, using something like Modernizr is a great way to do SVG fallbacks. Or if you’re looking for something really lightweight and don’t need any gradients, you may instead opt use a Icon Font. Like SVG’s icon fonts scale well, and they have the ability to accept text based CSS being they are a font library.

With all it’s advantages, there are still instances where you’ll need to use pixels or maybe Icon Fonts, but SVG’s are still a great tool for any developer in an age of HD/retina displays.