At Ackmann & Dickenson, we’ve noticed within the past few years that single-page application (SPA) technology was increasingly dotting the app development landscape and generating a lot of client and developer interest.
As with most new dev technology trends, we do our best to separate the wheat (quality, well-built frameworks) from the chaff (shiny, but flawed, objects). Where sometimes it’s tempting to reach for the shiny new object, our belief that each project build has a most appropriate framework precludes us from automatically deploying the hottest new ‘it’ technology.
As A&D developer Casey Jacobson explains, the choice to harness this particular shiny object paid off in spades.
First off, can you walk us through what SPA technology is?
Single-page application technology allows a website to make dynamic changes to a page (think Twitter, or the updated Gmail platform), rather than loading new pages from a server when a user clicks a link. SPAs do this, generally, by providing a combination of Model-View-Controller architecture, modular components, two-way data binding, routing and state management all within a single framework. Opinions vary, but we tend to think ReactJS, Angular and Vue.js are the heavy hitters in the SPA world these days; among those, Vue is thought of as the flashy new kid on the block.
Give us a quick overview of the build we provided for this nonprofit.
It was basically an interactive experience that paints a picture of what this client sees as a better future for the world, and brings us through the journey of how we get from today to that future. It’s an inspirational project; the design is well done and helps bring the user through that journey — really helps you feel what they’re trying to get you to feel.
What sort of unique challenges did the project present?
The biggest thing is that there were a lot of very complex user interface (UI) pieces — different types of interactivity — and the small details were really important. We had a big focus on the transitions between different states and the subtle animations as the user navigates the different components in this application.
What technologies did A&D consider?
Starting a new project always provides a good chance to reassess what we have been doing and what opportunities exist in the development landscape today. In this case, we were already locked in with an ASP.NET Core MVC project for the back end — that’s the technology that the client uses. But the front end, which was going to be the more challenging part, it was kind of up to our discretion which way to go with that. We considered a variety of options, but we primarily looked at React, Vue or building everything from scratch, meaning we’d use no big framework at all.
We talk about Vue as a hot new technology; in your mind, what makes it that way?
It’s kind of weird; Vue is thought of as the hot new technology right now, but it’s not that new. It’s been around a few years. The first public release of Vue came less than a year after React’s, but it’s just now growing really fast in popularity. I think people have been frustrated by the complexity of some React apps and they’re looking for a different way to approach problems — and Vue provides a different way. It combines a lot of things that people like about different frameworks into one.
So it’s now getting this notoriety because it has grown so quickly?
Basically. It really is insane how fast in the last year or two that Vue has grown. The biggest indicator of this might be GitHub Stars, the code repository where developers can favorite or like different technologies. Vue actually surpassed React a couple of months ago. That doesn’t necessarily mean it’s used more than React — I think React is still far bigger — but it shows how strongly the development community thinks about Vue.
What made Vue the right technology for this project?
I think the biggest thing is that it would allow the build to be maintainable for the client. Because we weren’t just building this thing and then it was done. Neither were we building this thing and then have control of it for its entire lifespan. We were building something for a two- to three-month period and passing it off for the client to maintain for years to come. This application had to survive.
The other reason is because of some of the more complex UI problems we had to solve. There are some things built into Vue that can help with things like animations — there’s native support for building those out. And that’s not the case with React.
Was there a risk in moving forward with Vue as opposed to something more familiar like React?
We don’t take these technological decisions lightly. Every decision we make has a big impact for the client, and all of them carry some sort of inherent risk — whether it’s with a technology we’ve used a bunch or not at all. As an organization we’ve had more experience with React, but we did our due diligence on Vue and on this project. We felt Vue was the right choice. There definitely was a risk, but we felt Vue was the lowest-risk choice.
So, sounds like it was worth the risk?
I believe you have to be willing to make those decisions rather than continue to do things the way you’ve always done them, because innovation is a constant in this field. You can’t just say, “We’re going to do it the way we’ve always done it, because that’s the way we always do it.” Every project is different. Technology changes so fast that framework X might be a good choice one day, and six months later maybe a different technology is a better choice.
What did you learn from deploying Vue for such a complex build-out?
I learned a lot about the framework in general. I learned a lot about component-based design, which is another big thing with Vue. I think Vue and React really enforce that. The basic idea is that you have different, reusable components that you’re building out, and then you create your page from those components. So if you want to create a brand new page, you just import these different components, because you’ve already built them. A button, for example. You build a button once and it’s done. Or some sort of modal overlay on a screen. You build that functionality once and then you can reuse it over and over in your application.
So component-based design helps you be more efficient.
Exactly. And I think that’s something that developers — especially front-end developers — strive for. There are a lot of things we’ve done over the years to try to get to that point, like different naming conventions for our CSS, or our HTML. And we do that to try to get to the point where we build something once and reuse those same patterns over and over. These frameworks enforce that — that’s something both React and Vue do very well.
How has A&D embraced Vue? Though developers had been familiar with the framework, A&D hadn’t deployed it at the same rate as React, for example, prior to this project. Has that changed?
In the past few months, we’ve used Vue to some extent on five or six projects. It’s becoming a powerful tool for the company.
One of the things we haven’t mentioned about Vue: They call themselves a progressive framework, meaning you don’t necessarily have to build your entire application around this technology. You can sprinkle it in here and there where it helps; maybe add a little bit of interactivity to a page. There’s been two projects where we’ve done that, and that’s been really successful. And then there have recently been three or four different projects where we’re building the entire application in Vue.
From your perspective, what are the advantages of jumping on a trendy dev technology?
You can help shape the future of that technology — if you’re in there early enough. At A&D, we’re big supporters of open-source software (OSS), and we use it all the time. One of the great things about OSS is that a developer can become active in the community and talk to the people that are building these tools and give them feedback on how it worked. Maybe what issues you’ve had with it, comparing it to some other technology that you’ve used and discussing those trade-offs.
Another advantage is having a deeper understanding of the choices they made when building out the framework. If you’re active in that community early on, you can understand why they went a particular direction, as opposed to picking something up years later, like, “Okay, everybody uses this now, it’s just the way it works.” As opposed to being there, being active in those discussions about how it should work.
What about disadvantages?
There’s always going to be a learning curve, even if the technology is relatively simple and straightforward. You’re going to have to learn their conventions, maybe different syntax for the code that you’re writing. And if the framework doesn’t become that popular, you’ve kind of lost out on that time; you’ve invested yourself mentally in this thing and maybe a year from now nobody is going to want to use it, so you’ve just wasted all that time. That’s a risk you have to take.
Worse, you might have built something that’s not going to be maintainable for a client in the future, because no other developers use it. Maybe the community isn’t that active, so there’s not many third-party integrations you can use. You’re potentially putting your clients in a tough spot in the future if you jump on some new trendy technology before it’s actually established. Avoiding that potentially disastrous outcome underscores our critical approach and due diligence toward any build-out.
How would you characterize A&D’s approach in leveraging a trendy new technology?
One of the cool things is that this job is about so much more than a paycheck. We do it because we really enjoy what we’re doing, and we enjoy being active in the community. So a lot of us are always looking at these new things and kind of trying them out here or there on the side. But when it comes to actually making the choice for a client, you really have to take into account what the best fit is going to be for them. And sometimes that means you don’t get to use that fancy new toy you wanted to use because it just doesn’t fit. But other times, it might be a good fit, and we have that freedom to make those decisions if it’s going to be the best decision for the client.
Choosing the best app framework for a particular project is always going to be a work in progress — as well it should be, given the speed with which this technology advances. Embracing a newer or trendier framework comes with risk. And how to think critically in approaching that risk — from consultation to sprint planning to scrum to sprint retrospective — will be what sets the modern developer and tech firm apart. To learn more about A&D’s process and what our developers are working on, click here. For more info, contact us.