This Dot Blog
This Dot provides teams with technical leaders who bring deep knowledge of the web platform. We help teams set new standards, and deliver results predictably.
State of Meta Frameworks Recap
In this State of Meta Frameworks event, our panelists discussed the current State of Meta Frameworks. This wrap-up covers the panel discussion on the ever-evolving state of meta frameworks in the digital landscape. Our expert panelists delved into the latest trends, advancements, and challenges faced by developers and businesses in adopting and utilizing meta frameworks effectively. You can watch the full State of Meta Frameworks event on the This Dot Media YouTube channel. Here is a complete list of the host and panelists that participated in this online event. Hosts: - Dustin Goodman, Engineering Manager, This Dot, @dustinsgoodman - Mattia Magi, Senior Software Engineer, This Dot, @mattia_magi Panelists: - Ryan Carniato , Author of the SolidJS UI library and MarkoJS Core Team Member, @RyanCarniato - Ben Holmes, Software Developer, Astro, @BHolmesDev - Maya Shavin, Senior Software Engineer, Microsoft, Nuxtjs ambassador, Google Developer Expert , @MayaShavin - Andreas Ehrencrona, Head of Crown Framework Development at Hyperlab | Svelte Maintainer, ehrencrona - Amy Dutton, Lead Maintainer on the RedwoodJS Core Team, @selfteachme In 5-10 years, where do you think web application development and meta frameworks are heading with the current trend of experimentation? The discussion got off to a quick start, and there seemed to be a consensus that the web development ecosystem is currently going through a phase of experimentation, with numerous frameworks and tools popping up and evolving rapidly. This creative and innovative environment allows developers to explore various solutions, leading to a wide array of choices. Looking ahead, it's difficult to predict the exact form of an ideal development environment in 5-10 years. However, there is an expectation that the web development community will eventually converge on some consensus regarding best practices and tools. Some current practices, like hydration (the process of converting server-rendered HTML into a fully interactive application on the client-side), might be considered wasteful in an idealized future and could be replaced with more efficient approaches. One significant consideration for the future of web development is competition between web applications and mobile apps. While the web has advantages in terms of faster initial loading and no need to download large app files, mobile apps are often perceived as having better user experiences. Closing the gap between web and app experiences will likely be a focus in the coming years. The ease of creating meta frameworks is seen as a positive aspect of the current ecosystem. The availability of bundlers and underlying tooling has made it possible for developers to build their frameworks on top of existing libraries and tools. This ease of creation has led to an explosion of ideas and innovation in the space. However, the growing complexity and the abundance of choices can also be overwhelming for newcomers to web development. The abundance of frameworks and tools may make it challenging for beginners to know where to start. Simplifying the development process and making the technology more approachable for new developers will likely be a concern for the future. There's also a cautious perspective regarding abstracting complexity too much. While meta frameworks and high-level abstractions can make development easier and faster, there's a risk of losing touch with the underlying technology and ending up with monolithic solutions that become difficult to maintain and replace. In summary, the web development landscape is currently characterized by experimentation and rapid evolution. As the community continues to explore and innovate, it is expected that the industry will eventually converge on more standardized practices and tools. Finding the right balance between abstraction and maintainability will be crucial for the future of web application development. Will other tech stacks follow Next.js in adopting server-first approaches with React's server components? The discussion revolves around Next.js adopting React's server components, which indicates a shift towards server-first approaches in their development. The conversation contemplates the potential impact of this trend and whether it might lead to similar shifts in other tech stacks. React's server components are viewed as a new and hot trend in the React ecosystem, with no similar implementations currently in other tech stacks. The participants discuss how web development has evolved over the past years, from server-rendered PHP and Rails applications to the rise of JavaScript and single-page applications (SPAs), and now the current move back towards server rendering and server component rendering. Opinions differ on the real benefits of server components compared to more established server-side rendering approaches. Some participants express support for server components, appreciating the server-first philosophy and the idea of shipping HTML from the server to the client. Others question the advantages of introducing server components when client-side models are already highly capable and suitable for building dynamic apps. The conversation touches on the challenges of adopting new approaches and integrating them with existing ecosystems. Legacy concerns and the need for education within the React community are mentioned as potential obstacles to widespread adoption. However, it's acknowledged that some frameworks have already taken the path of starting with server rendering and then adding client-side functionality later. The debate continues, with participants emphasizing the ongoing innovation and experimentation in reducing JavaScript costs and execution in the browser. Despite the differing approaches taken by underlying libraries and frameworks, there seems to be a degree of consolidation and agreement among metaframeworks in terms of handling progressive enhancement, server functions, file-based routing, and other patterns. React server components are considered a special addition to the Redwood framework, which already incorporates a back-end component, mainly focused on GraphQL. The advantages of back-end flexibility and server-side rendering, particularly for tasks like handling Open Graph meta tags, are highlighted. In conclusion, the participants express various viewpoints on the adoption of server components and server-first approaches. While there are differing opinions on their benefits and practicality, the conversation suggests that innovation and experimentation in web development will continue to shape the direction of tech stacks in the future. What advice would you give to developers just starting to learn a new meta framework, and what are the learning curves typically associated with them? For developers starting to learn a new meta framework, the panel suggests considering the purpose of their project and what they want to achieve. For simple projects like personal blogs or static sites, options like WordPress or templating with Astro may be more straightforward. However, for dynamic applications or job prospects, learning a popular component framework like React is recommended due to its extensive documentation and community support. The importance of having a strong foundation in JavaScript, HTML, and CSS is emphasized before delving into meta frameworks. For beginners, learning the fundamentals is key, and then they can progress to using a meta framework that aligns with their interests and goals. The panel acknowledges that the choice of framework might not be as crucial as many believe. The important thing is to pick one that feels comfortable and appealing, as the skills and patterns acquired will be transferable to other frameworks if needed. Job market prospects can be enhanced by being well-versed in cutting-edge frameworks, as companies using less common technologies may highly value developers with expertise in those areas. Ultimately, the advice is to avoid getting paralyzed by the fear of making the "wrong" choice and to focus on finding a framework that resonates with personal preferences and aligns with project requirements. Being adaptable and willing to learn new technologies will make a developer stand out in the job market and as a valuable consultant. What are each of you using for deployments and what is blocking other platforms? When it comes to deployments in different ecosystems, the panelists shared their experiences and challenges. They discussed the adoption of adapters to simplify deployment processes across various platforms. Some mentioned using AWS S3, Netlify, and Parcel for static sites, while others emphasized the importance of considering the platform's limitations and performance. The conversation touched on serverless functions and edge deployments, with mixed experiences across different frameworks. While some found serverless functions efficient and fast, others encountered configuration challenges and a lack of clear documentation. Overall, the panelists highlighted the ongoing experimentation and search for optimal deployment solutions, with open-source collaborations being key to driving progress in this space. What are some common misconceptions or misunderstandings about your respective frameworks? The panelists addressed common misconceptions and misunderstandings about their respective frameworks. Redwood was mistaken as a new framework, but in reality, it has been stable and established for over four years. They emphasized their focus on startups and core infrastructure, partnering with incubators to support end-users in that market. Astro clarified that it is not limited to static sites and can handle dynamic single-client rendered apps with its flexibility in mounting components. SolidJS emphasized its goal of raising the baseline of primitives in the ecosystem, encouraging the use of existing libraries and promoting a future without lock-in frameworks. Crown showcased its selling point of partial hydration for optimal performance but acknowledged the challenge of explaining the concept to potential customers. Lastly, Nuxt was differentiated from Next, and it was clarified that Nuxt is optimized for performance, aims to simplify developer experience, and is not just the "next" version of Vue. The panelists agreed that maintaining a meta framework is not easy and often involves complex version upgrading and bug fixes. Overall, the conversation shed light on the unique strengths and goals of each framework, debunking common misconceptions and providing insights into their usage and focus areas. What's causing the shift away from first-class testing in libraries and frameworks, and will we see a return to testing-first tooling? In this candid conversation, the panelists discussed the changing landscape of testing in libraries and frameworks. They acknowledged that many new releases are moving away from first-class testing in favor of end-to-end testing tools like Cypress and Playwright. Some frameworks, like Redwood, continue to support unit testing with Jest and JavaScript testing library, while others, like Svelte Kit, are shipping with Playwright out of the box. The shift seems to be driven by the complexity of modern applications, where bugs often emerge in the integration of various components and data sources. The panelists emphasized that testing needs to address the actual complexity of the application, and in some cases, end-to-end testing proves more effective in detecting bugs and ensuring the overall system works as intended. However, they also acknowledged that there are still benefits to unit testing and emphasized the importance of having both types of testing in a robust application. The challenge lies in finding the right balance and tooling to suit different types of frameworks and projects. The diversity of opinions and preferences within the community makes it difficult to prescribe a one-size-fits-all approach to testing. Some frameworks prioritize ease of use and simplicity for beginners, while others lean towards comprehensive end-to-end testing for complex applications. Overall, the future of testing-first tooling remains uncertain. While there may be a shift back towards unit testing in some cases, it seems that the focus will be on finding the right combination of testing approaches that best suit the specific needs and complexities of individual frameworks and applications. Q&A What are the panelists thoughts on Docusaurus? The panelists discussed their thoughts on documentation tools, particularly Docusaurus. Some mentioned using their own custom solutions or other frameworks like Vpress and VuePress in the Vue ecosystem. Astro introduced their own documentation starter called Starlight, which aims to bring Docusaurus-like features to static templating languages open to any framework. The panel also mentioned Next.js and how the React 18 documentation process used custom React components rather than Docusaurus. The focus on partial hydration was highlighted as a key factor that can make documentation sites even better. Overall, the discussion reflected a diverse range of approaches and preferences when it comes to maintaining documentation for projects. Is transpiling a necessary technique anymore, and what are the panelists’ thoughts on infrastructure as code? The panelists had an interesting discussion about transpiling and infrastructure as code. Regarding transpiling, there was a consensus that while modernizing code to ESM (ECMAScript modules) is becoming more accessible, transpiling will still be necessary for a variety of reasons, including ensuring optimal performance and compatibility with different environments. The panel acknowledged that build tools and compilers are still widely used and will likely remain integral to the development process. On the topic of infrastructure as code, the conversation centered around how frameworks are starting to offer more opinionated solutions for deploying applications seamlessly. Next.js, for example, automatically infers whether a page should be deployed as serverless or static based on code patterns and fetch calls. However, there were also concerns about the potential challenges and risks of overly automatic decisions when it comes to deploying and managing infrastructure. Astra's approach of explicit configuration and allowing developers to set defaults for routes was noted as a more conservative and safer option. The discussion highlighted the ongoing evolution of these practices and how different frameworks are approaching the challenges of modern web development, providing varying degrees of automation and flexibility for developers. The general consensus was that while transpiling and infrastructure as code practices are continuously improving, they will still be essential components of web development for the foreseeable future. Can you discuss a challenging problem you encountered while developing your meta framework and how you solved it? During the discussion, the panelists shared challenging problems they encountered while developing their respective meta frameworks and how they approached solving them. One major challenge for Redwood was integrating GraphQL into their framework. While GraphQL can be powerful, not everyone is comfortable using it. Redwood aimed to simplify the process by providing conventions and handling complexities, making it easier for developers to work with GraphQL. This allowed applications to scale better, addressing over-fetching and waterfall issues. In the Crown framework, caching was a primary focus due to the heavy reliance on third-party data sources that were not always fast enough. To tackle this, they implemented various caching mechanisms, including in-memory caches, persistent caches (e.g., Redis), and HTTP caching. They utilized decorators to specify which data should be cached and employed patterns like "reusing stale while revalidating" to ensure fresh data while maintaining fast response times. For another panelist, the most challenging aspects of their meta framework were related to adapters and runtime components. They faced difficulties in balancing a generic interface for deploying apps anywhere while leveraging specific features of different platforms. Integrating platform-specific features without making the framework feel too platform-dependent was a considerable challenge. They explored the potential of generalizing certain aspects, such as key-value stores, to address common needs across platforms. The panelists emphasized that navigating the ever-evolving landscape of serverless and edge computing, and integrating the innovations from various platforms without compromising the core functionalities of their frameworks, required careful consideration and creative problem-solving. Overall, the discussion shed light on the complexities and ongoing efforts to build user-friendly and powerful meta frameworks in the dynamic world of web development. What are some of the most innovative or unexpected ways you’ve seen your frameworks being used? During the lively discussion, the panelists shared some unexpected and innovative ways their frameworks have been used in real-world scenarios. For instance, with Astro, they were pleasantly surprised to see Bloomberg experimenting with using it to template news articles. It was used alongside their existing framework in A/B tests, demonstrating Astro's versatility and ease of integration with other platforms. Additionally, Astro's middleware mode was another exciting discovery, allowing it to be deployed as a node server middleware, making it even more adaptable for existing projects. Redwood, on the other hand, was amazed by the diverse range of use cases their framework supported, from consumer applications to deep vertical SaaS implementations. The community's adoption of Redwood for various purposes showcased its flexibility and robustness. In the case of SolidJS, the team was surprised to find developers using Solid as the foundation for mobile apps and Electron applications. Solid's client-only mode was adapted for these use cases, demonstrating its potential to support mobile development and native-like experiences. A particularly jaw-dropping example came from the Svelte community, where developers managed to recreate the classic game Wolfenstein 3D in the browser using just DOM elements and CSS 3D transforms. This creative use of Svelte showcased its DOM manipulation capabilities and the powerful potential of modern browsers. Overall, the panelists were impressed by the ingenious ways developers harnessed the capabilities of their frameworks to solve unique challenges and create unconventional applications. Conclusion The overall discussion provided a glimpse into the dynamic and exciting world of meta frameworks and the ever-evolving possibilities they bring to web development. With such remarkable use cases and continuous innovation, the future of meta frameworks looks promising. The panelists expressed their gratitude to the audience for joining and participating in the event, and they all looked forward to meeting again in future events....
Jul 28, 2023
12 mins
Using Lottie Animations for UI Components in React
Lottie can bring the power of Adobe After Effects's animations to the web. Learn how to integrate these animations into your user interface in a React app....
Nov 10, 2021
3 mins
Connecting to PostgreSQL using TypeORM
In my previous article we learned how to connect to a PostgreSQL database using the node-postgres package pg. This works fine, and will be perfect for many applications, but one may also choose to opt for using an ORM instead. What is an ORM? ORM stands for object-relational-mapping and allows you to interact with your database using objects from your programming language's type system rather than hand writing queries. This allows ORMs to simplify your logic that manipulates data in the database. In this article, we've opted to use TypeORM as it is widely used, and it supports many of the advanced features expected from an ORM framework. Setup We'll be demonstrating examples with both Data Mapper and Active record patterns. Both the Data Mapper and Active Record patterns are supported by TypeORM, and we'll cover the former first. Data Mapper allows you to represent tables and other data as Entity classes. You can then define properties in these classes that map to the respective columns in the database, and even include custom methods in the entities that manipulate them. For starters, you'll want to have TypeScript and TypeORM installed. TypeORM uses TypeScript exclusive features for defining your entities, and although it's not required to use TypeORM, it makes it much easier to do so. TypeScript is an extension to JavaScript that adds a strict type system. At the time of writing this article, TypeORM requires TypeScript v3.3 at a minimum, and this is subject to change. ` Now, TypeORM has to be installed! This can be done with the following npm command in your project root: ` Let's define a database and a simple schema with a people tables like we did in our node-postgres article. Please check out that article if you need instructions on how to set up a PostgreSQL to develop against. ` Data Mapper The Data Mapper pattern allows you to define Entities that represent your data types in the database, and repositories to store your query methods and other domain logic. Entities in Data Mapper are very simple. The following example is how an Entity for our person table is defined using the Data Mapper pattern. This is contained in a file called person.ts. ` Note that this Entity uses decorators that are experimental at the time of writing this article. Make sure you set experimentalDecorators and emitDecoratorMetadata in your tsconfig.json for this to work. You can generate a tsconfig.json by running tsc --init. Let's break down what these decorators and their options mean. @Column: Put above a property that maps to a column. The name of the property is assumed to be the name of the column in the table. If the name in the Entity doesn't match the database column name, you can specify a name in an options object in the decorator. @PrimaryGeneratedColumn(): This signals to TypeORM that this is a PRIMARY KEY column that uniquely represents the entity. To write a query method, we'll need to create a repository. A repository is a class that contains query methods and other helpers. Domain logic that works with Entities is separated from the definition of the data types themselves. This will go in people-repository.ts. ` The following code can be used to set up a connection and interact with the database with our Entity and Repository. It's a better practice to change the fullname property on the class instance and use save() to update it in the database. However, I wanted to demonstrate how the query builder can be used for UPDATE queries as well. We put this in our main index.ts file. ` Now, with all the code in place, it can be executed with tsc && node index.js. The above demos a basic CRUD flow just like we do in our previous article where we use raw SQL. All methods for interacting with the data exist in the Repository class, and this class has our own custom functions and pre-existing functions for saving and removing data that we use. Active Record The Active Record approach allows you to define query methods in the model itself, rather than doing it in a repository like we did with the Data Mapper pattern. You may have used the Active Record pattern before if you've ever used Ruby on Rails. For our example, there won't be very many changes. We can actually use the same Entity as we did in the Data Mapper class, however we will move our query methods into this class. We also make one of the queries static so we don't need an instance of the class to call the method. The name update method can remain an instance method as it can utilize the id property in an instance to simplify making calls to it. Here is the new person.ts. ` The code in index.ts is similar to the data mapper approach, but differs in how the query methods are called. Since we don't have a repository class with Active Record, we just call the methods directly on the Entity instance. ` Both methods are valid, and you should choose whatever you're more comfortable with, and whatever makes the most sense for your project. Conclusion TypeORM is a useful tool, and is capable of so much more than what is showcased here. We've only skimmed the surface of what TypeORM provides, and there is so much more. There is support for many more advanced features such as lazy relations, migrations, pagination, etc. The full documentation on their website has a lot of useful information. You can find all the source code in this GitHub repo!...
Apr 6, 2021
4 mins