In this installment of our series on building web applications, we look at the SitePen approach to solving challenges in web application development. We employ all of the solutions described in part 2 of the blog series. Additionally, we have some overarching principles we apply to our work.
The right architecture and an emphasis on quality
Solid applications and robust architecture begins with finding the right approach based on the goals and requirements for a particular application. There is no one right architecture for every application, but having the right approach to understanding requirements, translating those to architecture needs, and having a strong emphasis on quality lead to approaches that work for any application. We do this by making sure we ask the right questions and challenge our assumptions for every application we create.
Quality first
At SitePen, our first emphasis is on quality. While we’re not perfect, the main lesson we’ve learned over the years is to set very high goals on the quality of everything we create.
We focus on quality as a way to reduce the time needed for quality assurance at the end of a project, and to decrease the total cost of ownership over the long term. Defects may still occur in the work we deliver, but what is different is that with an emphasis on quality, the time it takes to resolve issues is diminished. It is far easier to track down problems with well architected, documented, and tested source code.
Sound architecture principles are the foundation for high quality code. Beyond that, in order to achieve high quality, we leave time to review and refine our source code until it meets our standards.
You can see some of this in action in our open source work by following our progress on Dojo 2!
As noted previously in this series, we rely on various code linting tools such as TSLint, ESLint, and JSHint to make sure our code meets our standards. We share some of our preferred standards with our shared .jshintrc and Dojo 2 style guidelines.
Clear and flexible architectures
We rely on very configuration driven approaches to architecture, with efficient dependency management, and highly testable code. For example, in a typical application, it will require a one-line change to switch between a mocked test data service and a real production-ready APIs. This level of flexibility makes it very easy to switch between test data and real data to help isolate issues quickly.
Part of this flexibility comes from the features we’ve built into the Dojo Toolkit over the years but it’s a concept that should be achievable within any well-architected application.
Our architectures aim to strike the right balance between the desires of our customers, and our own insight into creating architectures that are clear to follow and easy to maintain.
We have been early adopters of TypeScript because it offers many developer productivity gains, and makes it much easier to express intent within large code bases. This reinforces our approach to clear and flexible architecture.
Constantly improving the development process
Beyond the process improvements described in part 2 of the blog series, including transpilation workflows and source code management, we consider test automation, code coverage, and continuous integration to be a fundamental foundation for solid development, regardless of a particular customer’s development methodology.
Test automation, code coverage, and continuous integration
We created Intern as we needed our approach to flexible architecture for testing. Our customers use a wide variety of continuous integration tools, and we needed the flexibility to be able to easily test everything.
We also expect all of our source code to have a very high level of code coverage, so that we know we’ve tested everything. As a result, we built code coverage into Intern, and we also made it easier to measure code coverage with transpiled code.
Whenever we find a defect, we add a test so we don’t make that mistake again! A strong emphasis on testing efficiently is a substantial competitive advantage.
People: Where the magic happens
We’ve built a strong and focused team that is our biggest strength. We employ many techniques to keep our team focused, relaxed, and productive through a collaborative, patient, and transparent approach to our business.
Collaboration
Our culture is one that encourages collaboration at all times. By being a virtual company, we have had to find ways to ensure that collaboration is frictionless, ideas can be shared and expressed, and that our staff can as easily forge relationships because we lack those “watercooler moments”.
We adopted enterprise messaging long before it became a buzzword and we continue to innovate in those methods of communication. We find ourselves over-communicating compared to those companies who have a physical location and that seems to have improved our whole organization. It also means that we tend to document all decisions by default, rather than trying to remember later why we made a decision.
Patience
We take a very long term and patient view of the web. We started working on Dojo over 12 years ago, and a lot has changed during that time. We are pragmatic in making choices about what works today, what will work soon, and what the future vision is. We aim to straddle all of these worlds based on the needs of our customers.
This patience also means we don’t race around and blindly adopt whatever is new without thinking through the implications, benefits, and challenges. Conversely, we don’t just keep using what we’ve always used because it’s comfortable, as we’re always looking for ways to improve.
InnerSource and open source
We work with our customers on InnerSource efforts to encourage reuse and maximum value within their organizations. We help enterprises overcome the challenges and obstacles they have to help them reduce costs and inefficiencies through recreating software across teams.
Beyond our customer engagements, almost everything SitePen creates is open source. Anything else is delivered internally using an InnerSource model. For an example of the latter, we have an internal slide creation tool that reads markdown files and source code examples and generates slide presentations for our JavaScript workshops, conference talks, and meetup groups.
Over the past 10+ years we have invested at least 20% of our engineering time on open source initiatives that improve our development efforts. This allows us to help shape the platform in a manner that allows us to deliver high quality applications more efficiently.
At the moment, we’re focused on making Dojo 2 a solid collection of packages for building modern applications with ES6 and TypeScript, Intern for testing everything, and dgrid+dstore for rendering large data sets in web applications.
We also create a series of smaller utilities that help our development workflow. For example, we’ve made it easier to use Dojo 1.x with TypeScript, to manage code coverage with transpiled languages, and to deploy TypeScript bundles efficiently.
In our open source efforts, we provide solutions that are consistent, and comprehensive enough for building well architected applications. Yet they remain modular and flexible enough to use as smaller utilities and tools to improve applications built with any approach taken with JavaScript or TypeScript.
Conclusion
Building modern web applications is not trivial, but we’ve found that a healthy mix of software architecture, efficient process, and productive people lead to exceptional results.
By following best practices, having patience, and applying intelligence, we are able to help our customers deliver the best possible experiences to their users, and reaping the many benefits of web applications.
This all begins with a solid foundation of clean, efficient, well architected source code built on top of a solid open source foundation. And we’re constantly learning, teaching, and collaborating along the way.
Learning more
Have a question? We’re here to help! Get in touch and let’s see how we can work together.