From hobby to career, my love for frontend development is where it all began
TypeScript
My first introduction to JavaScript was through jQuery. It was the go-to solution for web development back then. Being able to manipulate the DOM and create effects and interactions not possible with HTML and CSS alone had a strong attraction to me.
When I changed career paths to software engineering, jQuery was barely relevant. I couldn’t rely on it and had to grow stronger in vanilla JavaScript alongside the libraries and Frameworks I was using.
Finally, TypeScript entered my life when I joined a company that had a vast library of type definitions and strict standards around using the tool. I was able to pick up a good understanding of it rather quickly, especially as I began to benefit from using it.
While I will ignore it and just use JavaScript for very small code exercises, TypeScript is my language of choice for large projects and foundations. I feel the pros outweigh the cons and it’s worth anyone’s while to learn and use.
Pros
Static Typing
Error Detection: Catching errors at compile time rather than at runtime helps in reducing bugs
Code Quality: Enforces type safety which improves code quality and maintainability
Tooling Support: Enhanced IDE support with features like autocompletion, type checking, and navigation
Improved Readability and Maintainability
Explicit Types: Makes the code more readable and understandable
Self-Documenting: Types serve as documentation, making it easier for new developers to understand the codebase
Cons
Learning Curve
Initial Overhead: Requires learning TypeScript-specific syntax and concepts, which can be a hurdle for new developers
Complexity: Can add complexity, especially for small projects or simple scripts
React
While my first software job was on an Angular team, I got the role due to my proven ability to learn and adapt quickly. I demonstrated this during the interview process by guiding the people on the call through a React app I had designed and built while learning the library.
I was strongly drawn to JSX as a solution versus templates. I like how content, layout, and functionality all happen in a way that is natural to HTML. There are no proprietary attributes to learn such as those in frameworks that prefix features with the framework name or abbreviation. Want something to happen on click? You can just use onClick! Want conditional content? Use ternaries right in the markup!
I find creating and maintaining a React app to be smooth and easy to understand, especially when being introduced to a new-to-me codebase.
Pros
Component-Based Architecture
Reusability: Components can be reused across different parts of the application, reducing duplication and effort
Modularity: Encourages separation of concerns, making the codebase more manageable and scalable
Virtual DOM
Performance: Efficiently updates and renders components, leading to high performance in large-scale applications
Minimal DOM Manipulation: Reduces direct manipulation of the DOM, which can be error-prone and slow
JSX Syntax
Readability: JSX combines JavaScript and HTML, making the code more readable and easier to understand
Declarative: Encourages a declarative programming style, making UI logic more predictable and easier to debug
Strong Ecosystem
Community Support: Large and active community provides a wealth of resources, tutorials, and third-party libraries
Tooling and Libraries: Rich ecosystem of tools like Create React App, React Router, and state management libraries (e.g., Redux, MobX)
Cons
Learning Curve
Complexity: Can be difficult for beginners to learn, especially with advanced concepts like hooks, context, and higher-order components
JSX: Some developers may find JSX syntax unfamiliar or cumbersome
State Management Complexity
Multiple Approaches: Various ways to manage state (e.g., Context API, Redux, MobX), which can be confusing and lead to inconsistency
Boilerplate Code: State management solutions like Redux can introduce a lot of boilerplate code, making the codebase more complex
SEO Challenges
Client-Side Rendering: Out-of-the-box React may not be optimal for SEO, although this can be mitigated with SSR frameworks like Next.js
Styled Components
I’ve long claimed that I can speak CSS better than English. I’m one of the odd engineers that gravitates towards it instead of writing it begrudgingly. It has come so far since my early career and I am very quick at knocking out styles utilizing the simplest approaches and tools that it has to offer.
When I started learning React, one of the courses I took used Styled Components. I hated it immediately. Pretty much the only reason was I had long been a believer in the separation of concerns. Your markup (HTML), your styles (CSS), and your interactions (JS) should all live in their own places of organization.
But React changed that viewpoint. Since I was already utilizing HTML and JavaScript in the same place due to JSX, why not bring CSS over too?
I’m not completely loyal to this approach as there are strong pros and cons to other solutions: SASS, Emotion, utility libraries like Tailwind, etc. I just find maintaining the component library part of a design system simple and easy with style isolation. Funny enough, this means losing both “cascading” and “sheets”.
Pros
Scoped Styles
Avoids Global Scope Issues: Styles are scoped to individual components, preventing style conflicts and making it easier to manage large codebases
Encapsulation: Encourages encapsulation, as styles are tied directly to components, enhancing maintainability
Dynamic Styling
Props-based Styling: Styles can be dynamically adjusted based on component props, allowing for highly flexible and reusable components
Conditional Styling: Enables conditional styles directly within the component logic
Enhanced Developer Experience
Tagged Template Literals: Uses ES6 template literals, making the syntax easy to read and write
CSS in JS: Allows the use of JavaScript to manipulate styles, leveraging the full power of JavaScript for complex styling logic
Syntax Highlighting and Autocompletion: Integrates well with modern code editors, providing syntax highlighting and autocompletion
Theming Support
ThemeProvider: Built-in support for theming allows for easy implementation of theme switching and consistent styling across an application
Global Themes: Themes can be defined globally and accessed throughout the application
No Class Name Conflicts
Unique Class Names: Automatically generates unique class names for styles, avoiding class name collisions and specificity issues
Cons
Performance Overhead
Runtime Styling: Generates styles at runtime, which can introduce performance overhead, especially in large applications or with frequent re-renders
CSS-in-JS Performance Issues: CSS-in-JS solutions can sometimes be slower than traditional CSS due to the additional JavaScript processing required
Learning Curve
New Syntax: Requires learning new syntax and concepts, which can be a barrier for developers unfamiliar with CSS-in-JS or tagged template literals
Integration Complexity: Integrating Styled Components into an existing project with a different styling approach can be complex and time-consuming
Tooling and Debugging Challenges
Linting and Formatting: Standard CSS linters and formatters may not work out of the box, requiring additional configuration or tools
CSS Feature Limitations
Pseudo-selectors and Animations: Some complex CSS features and animations can be more cumbersome to implement compared to traditional CSS or pre-processors
Strapi
When I was first introduced to WordPress back before it earned the ability to be called a Content Management System, it launched me into a career I didn’t know I could achieve.
Having the ability to manage content separate from markup, was revolutionary, not to mention the ease in which you could keep your code DRY.
Fast forward to my software years and I’m still impressed with WordPress’s strong ecosystem, the standards and policies the team of contributors hold that helped shape me into a stronger programing discipline, and the features. It has so. many. features.
What I’m not fond of, is PHP. Yes, you can go headless since they introduced the REST API, but it kinda negates a lot of the power that you get from the templating system and even permalinks.
So much WP talk, what about Strapi?
Since I love writing SPA’s with React, I easily fell in love with Strapi, its strong content type and dynamic zone features, and the fact that it’s all JavaScript, baby!
While I have a healthy list of cons below, the only ones that give me a slight pause are the performance concerns and vendor lock-in.
Pros
Headless CMS
Decoupled Architecture: Allows you to use any front-end framework or technology to consume the content via RESTful or GraphQL APIs
Flexibility: Suitable for a wide range of applications, from websites to mobile apps and beyond
Customization and Extensibility
Customizable Admin Panel: Easily customize the admin interface to fit specific needs
Plugins and Middleware: Extend functionality through a rich ecosystem of plugins and middleware, or develop custom ones
API Support
RESTful and GraphQL APIs: Offers both RESTful and GraphQL APIs out of the box, providing flexibility in how content is consumed
Customizable APIs: Allows you to customize and extend the generated APIs to meet specific requirements
Content Types and Dynamic Zones
Content Type Builder: Provides a user-friendly interface for creating and managing content types and fields
Dynamic Zones: Allows the creation of flexible and reusable content structures, enhancing the ability to manage complex content
Localization and Internationalization
Multi-Language Support: Built-in support for managing content in multiple languages, catering to global audiences
Cons
Performance Overhead
Heavyweight: Strapi can be resource-intensive, especially for high-traffic applications, potentially leading to performance issues
Server Requirements: Requires a robust server environment, which can increase hosting costs
Learning Curve
Complexity: While the admin interface is user-friendly, understanding and customizing the backend codebase can be complex for beginners
GraphQL Complexity: Using GraphQL effectively may require additional learning for those unfamiliar with it
Limited Built-in Features
Basic Features: Out-of-the-box features may be limited for certain use cases, requiring additional customization or plugin development
Plugin Dependency: Reliance on third-party plugins for extended functionality, which may vary in quality and support
Vendor Lock-in
Strapi-Specific Code: Heavy customization might lead to vendor lock-in, making it challenging to switch to another CMS without significant refactoring