{"id":3532,"date":"2021-12-02T14:08:13","date_gmt":"2021-12-02T22:08:13","guid":{"rendered":"https:\/\/coderpad.io\/?p=3532"},"modified":"2023-06-05T14:38:16","modified_gmt":"2023-06-05T21:38:16","slug":"web-components-101-framework-comparison","status":"publish","type":"post","link":"https:\/\/coderpad.io\/blog\/development\/web-components-101-framework-comparison\/","title":{"rendered":"Web Components 101: Framework Comparison"},"content":{"rendered":"\n<style>\n.wp-block-table table, th, td {\n  border: 1px solid black;\npadding: 10px;\n}\n<\/style>\n\n\n<p>Alright alright, I know for a lot of the last article seemed like a big ad for Lit. That said, I promise I\u2019m not unable to see the advantages of other frameworks. Lit is a tool in a web developer\u2019s toolbox. Like any tool, it has its pros and cons: times when it\u2019s the right tool for the job, and other times when it\u2019s less so.<\/p>\n\n<p>That said, I\u2019d argue that using an existing framework is more often the better tool for the job than vanilla web components.&nbsp;<\/p>\n\n<p>To showcase this, let\u2019s walk through some of these frameworks and compare and contrast them to home-growing web components.<\/p>\n\n<aside class=\"\n    cta-banner\n     cta-banner--bg-blue      cta-banner--has-media \"\ndata-block-name=\"cta-banner\">\n    <div class=\"inner\">\n        <div class=\"content\">\n                            <h2 class=\"headline\">Learn how to run front-end developer interviews that don&#8217;t suck<\/h2>\n            \n                            <div class=\"cta-buttons\">\n                                    <a href=\"https:\/\/coderpad.io\/blog\/interviewing\/5-tips-for-interviewing-frontend\/\" class=\"button  js-cta--read-our-guide\"  data-ga-category=\"CTA\" data-ga-label=\"Learn how to run front-end developer interviews that don&#039;t suck|Read our guide\">Read our guide<\/a>\n                                <\/div>\n                    <\/div>\n                    <div class=\"media\">\n                <img loading=\"lazy\" decoding=\"async\" width=\"432\" height=\"342\" src=\"https:\/\/coderpad.io\/wp-content\/uploads\/2022\/08\/Illustration-of-man-with-beard-popping-out-of-computer-chat.png\" class=\"attachment-large size-large\" alt=\"\" srcset=\"https:\/\/coderpad.io\/wp-content\/uploads\/2022\/08\/Illustration-of-man-with-beard-popping-out-of-computer-chat.png 432w, https:\/\/coderpad.io\/wp-content\/uploads\/2022\/08\/Illustration-of-man-with-beard-popping-out-of-computer-chat-300x238.png 300w\" sizes=\"auto, (max-width: 432px) 100vw, 432px\" \/>\n            <\/div>\n            <\/div>\n<\/aside>\n\n\n<h2 class=\"wp-block-heading\">Pros and Cons of Vanilla Web Components<\/h2>\n\n<p>While web frameworks are the hot new jazz &#8211; it\u2019s not like we couldn\u2019t make web applications before them. With the advent of W3C standardized web components (without Lit), doing so today is better than it\u2019s ever been.<\/p>\n\n<p>Here are some pros and cons of Vanilla JavaScript web components:<\/p>\n\n\n<table class=\"wp-block-table\">\n    <tbody>\n        <tr>\n            <th>\n                Pros\n            <\/th>\n            <th>\n                Cons\n            <\/th>\n        <\/tr>\n        <tr>\n            <td>\n                <ul>\n                    <li><span>No framework knowledge required<\/span><\/li>\n                    <li><span>Less reliance on framework<\/span><\/li>\n                <\/ul>\n                <ul>\n                    <li><span>Maintenance<\/span><\/li>\n                    <li><span>Bugs<\/span><\/li>\n                    <li><span>Security issues<\/span><\/li>\n                <\/ul>\n                <ul>\n                    <li><span>Smaller \u201chello world\u201d size<\/span><\/li>\n                    <li><span>More control over render behavior<\/span><\/li>\n                <\/ul>\n            <\/td>\n            <td>\n                <ul>\n                    <li><span>Re-rendering un-needed elements is slow<\/span><\/li>\n                    <li><span>Handling event passing is tricky<\/span><\/li>\n                    <li><span>Creating elements can be overly verbose<\/span><\/li>\n                    <li><span>Binding to props requires element query<\/span><\/li>\n                    <li><span>You\u2019ll end up building Lit, anyway<\/span><\/li>\n                <\/ul>\n            <\/td>\n        <\/tr>\n    <\/tbody>\n<\/table>\n\n\n<p>To the vanilla way of doing things\u2019 credit, there\u2019s a bit of catharsis knowing that you\u2019re relying on a smaller pool of upstream resources. There\u2019s also a lessened likelihood of some bad push to NPM from someone on the Lit team breaking your build.<\/p>\n\n<p>Likewise &#8211; for smaller apps &#8211; you\u2019re likely to end up with a smaller output bundle. That\u2019s a huge win!<\/p>\n\n<p>For smaller applications where performance is critical, or simply for the instances where you need to be as close to the DOM as possible, vanilla web components can be the way to go.<\/p>\n\n<p>That said, it\u2019s not all roses. After all, this series has already demonstrated that things like event passing and prop binding are verbose compared to Lit. Plus, things may not be as good as they seem when it comes to performance.<\/p>\n\n<h3 class=\"wp-block-heading\">Incremental Rendering<\/h3>\n\n<p><br>On top of the aforementioned issues with avoiding a framework like Lit, something we haven\u2019t talked about much is incremental rendering. A great example of this would come into play if we had an array of items we wanted to render, and weren\u2019t using Lit.&nbsp;<\/p>\n\n<p>Every time we needed to add a single item to that list, our <code>innerHTML<\/code> trick would end up constructing a new element for every single item in the list. What\u2019s worse is that every subelement would render as well!<\/p>\n\n<p>This means that if you have an element like this:<\/p>\n\n<pre class=\"wp-block-code\" aria-describedby=\"shcb-language-1\" data-shcb-language-name=\"HTML, XML\" data-shcb-language-slug=\"xml\"><span><code class=\"hljs language-xml shcb-wrap-lines\"><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">li<\/span>&gt;<\/span><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">a<\/span> <span class=\"hljs-attr\">href<\/span>=<span class=\"hljs-string\">\u201dhttps:\/\/example.com\u201d<\/span>&gt;<\/span><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">div<\/span> <span class=\"hljs-attr\">class<\/span>=<span class=\"hljs-string\">\u201dflex<\/span> <span class=\"hljs-attr\">p-12<\/span> <span class=\"hljs-attr\">bg-yellow<\/span>\u201d&gt;<\/span><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">span<\/span>&gt;<\/span>Go to this location<span class=\"hljs-tag\">&lt;\/<span class=\"hljs-name\">span<\/span>&gt;<\/span><span class=\"hljs-tag\">&lt;\/<span class=\"hljs-name\">div<\/span>&gt;<\/span><span class=\"hljs-tag\">&lt;\/<span class=\"hljs-name\">a<\/span>&gt;<\/span><span class=\"hljs-tag\">&lt;\/<span class=\"hljs-name\">li<\/span>&gt;<\/span><\/code><\/span><small class=\"shcb-language\" id=\"shcb-language-1\"><span class=\"shcb-language__label\">Code language:<\/span> <span class=\"shcb-language__name\">HTML, XML<\/span> <span class=\"shcb-language__paren\">(<\/span><span class=\"shcb-language__slug\">xml<\/span><span class=\"shcb-language__paren\">)<\/span><\/small><\/pre>\n\n\n<p>And only needed to update the text for a single item in the list, you\u2019d end up creating 4 more elements for the item you wanted to update\u2026 On top of recreating the 5 nodes (including the <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Text\" target=\"_blank\" rel=\"noopener\">Text Node<\/a>) for every other item in the list.<\/p>\n\n\n<h3 class=\"wp-block-heading\">Building Your Own Framework<\/h3>\n\n<p>As a result of the downsides mentioned, many that choose to utilize vanilla web components often end up bootstrapping their own home-grown version of Lit.<\/p>\n\n<p>Here\u2019s the problem with that: You\u2019ll end up writing Lit yourself, sure, but with none of the upsides of an existing framework.<\/p>\n\n<p>This is the problem with diving headlong into vanilla web components on their own. Even in our small examples in the article dedicated to vanilla web components, we emulated many of the patterns found within Lit. Take this code from the article:<\/p>\n\n<pre class=\"wp-block-code\" aria-describedby=\"shcb-language-2\" data-shcb-language-name=\"HTML, XML\" data-shcb-language-slug=\"xml\"><span><code class=\"hljs language-xml shcb-wrap-lines\"><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">script<\/span>&gt;<\/span><span class=\"actionscript\">\n  <span class=\"hljs-class\"><span class=\"hljs-keyword\">class<\/span> <span class=\"hljs-title\">MyComponent<\/span> <span class=\"hljs-keyword\">extends<\/span> <span class=\"hljs-title\">HTMLElement<\/span> <\/span>{\n    todos = &#91;];\n\n    connectedCallback() {\n      <span class=\"hljs-keyword\">this<\/span>.render();\n    }\n   \n    <span class=\"hljs-comment\">\/\/ This function can be accessed in element query to set internal data externally<\/span>\n    setTodos(todos) {\n      <span class=\"hljs-keyword\">this<\/span>.todos = todos;\n      <span class=\"hljs-keyword\">this<\/span>.clear();\n      <span class=\"hljs-keyword\">this<\/span>.render();\n    }\n\n    clear() {\n      <span class=\"hljs-keyword\">for<\/span> (<span class=\"hljs-keyword\">const<\/span> child of <span class=\"hljs-keyword\">this<\/span>.children) {\n        child.remove();\n      }\n    }\n   \n    render() {\n      <span class=\"hljs-keyword\">this<\/span>.clear();\n   \n      <span class=\"hljs-comment\">\/\/ Do logic<\/span>\n    }\n   \n  }\n\n  customElements.define(<span class=\"hljs-string\">'my-component'<\/span>, MyComponent);\n<\/span><span class=\"hljs-tag\">&lt;\/<span class=\"hljs-name\">script<\/span>&gt;<\/span><\/code><\/span><small class=\"shcb-language\" id=\"shcb-language-2\"><span class=\"shcb-language__label\">Code language:<\/span> <span class=\"shcb-language__name\">HTML, XML<\/span> <span class=\"shcb-language__paren\">(<\/span><span class=\"shcb-language__slug\">xml<\/span><span class=\"shcb-language__paren\">)<\/span><\/small><\/pre>\n\n<p>Here, we\u2019re writing our own <code>clear<\/code> logic, handling dynamic value updates, and more.<\/p>\n\n<p>The obvious problem is that we\u2019d then have to copy and paste most of this logic in many components in our app. But let\u2019s say that we were dedicated to this choice, and broke it out into a class that we could then extend.<br><br>Heck, let\u2019s even add in some getters and setters to make managing state easier:<\/p>\n\n<pre class=\"wp-block-code\" aria-describedby=\"shcb-language-3\" data-shcb-language-name=\"HTML, XML\" data-shcb-language-slug=\"xml\"><span><code class=\"hljs language-xml shcb-wrap-lines\"><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">script<\/span>&gt;<\/span><span class=\"javascript\">\n  <span class=\"hljs-comment\">\/\/ Base.js<\/span>\n  <span class=\"hljs-class\"><span class=\"hljs-keyword\">class<\/span> <span class=\"hljs-title\">OurBaseComponent<\/span> <span class=\"hljs-keyword\">extends<\/span> <span class=\"hljs-title\">HTMLElement<\/span> <\/span>{\n    connectedCallback() {\n      <span class=\"hljs-keyword\">this<\/span>.doRender();\n    }\n\n    createState(obj) {\n        <span class=\"hljs-keyword\">return<\/span> <span class=\"hljs-built_in\">Object<\/span>.keys(obj).reduce(<span class=\"hljs-function\">(<span class=\"hljs-params\">prev, key<\/span>) =&gt;<\/span> {\n            <span class=\"hljs-comment\">\/\/ This introduces bugs<\/span>\n            prev&#91;<span class=\"hljs-string\">\"_\"<\/span> + key] = obj&#91;key];\n            prev&#91;key] = {\n                <span class=\"hljs-attr\">get<\/span>: <span class=\"hljs-function\"><span class=\"hljs-params\">()<\/span> =&gt;<\/span> prev&#91;<span class=\"hljs-string\">\"_\"<\/span> + key],\n                <span class=\"hljs-attr\">set<\/span>: <span class=\"hljs-function\">(<span class=\"hljs-params\">val<\/span>) =&gt;<\/span> <span class=\"hljs-keyword\">this<\/span>.changeData(<span class=\"hljs-function\"><span class=\"hljs-params\">()<\/span> =&gt;<\/span> prev&#91;<span class=\"hljs-string\">\"_\"<\/span> + key] = val);\n            }\n        }, {})\n    }\n   \n    changeData(callback) {\n      callback();\n      <span class=\"hljs-keyword\">this<\/span>.clear();\n      <span class=\"hljs-keyword\">this<\/span>.doRender();\n    }\n\n    clear() {\n      <span class=\"hljs-keyword\">for<\/span> (<span class=\"hljs-keyword\">const<\/span> child <span class=\"hljs-keyword\">of<\/span> <span class=\"hljs-keyword\">this<\/span>.children) {\n        child.remove();\n      }\n    }\n   \n    doRender(callback) {\n      <span class=\"hljs-keyword\">this<\/span>.clear();\n      callback();\n    }   \n  }\n<\/span><span class=\"hljs-tag\">&lt;\/<span class=\"hljs-name\">script<\/span>&gt;<\/span><\/code><\/span><small class=\"shcb-language\" id=\"shcb-language-3\"><span class=\"shcb-language__label\">Code language:<\/span> <span class=\"shcb-language__name\">HTML, XML<\/span> <span class=\"shcb-language__paren\">(<\/span><span class=\"shcb-language__slug\">xml<\/span><span class=\"shcb-language__paren\">)<\/span><\/small><\/pre>\n\n<p>Now our usage should look fairly simple!<\/p>\n\n<pre class=\"wp-block-code\" aria-describedby=\"shcb-language-4\" data-shcb-language-name=\"HTML, XML\" data-shcb-language-slug=\"xml\"><span><code class=\"hljs language-xml shcb-wrap-lines\"><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">script<\/span>&gt;<\/span><span class=\"javascript\">\n  <span class=\"hljs-comment\">\/\/ MainFile.js<\/span>\n  <span class=\"hljs-class\"><span class=\"hljs-keyword\">class<\/span> <span class=\"hljs-title\">MyComponent<\/span> <span class=\"hljs-keyword\">extends<\/span> <span class=\"hljs-title\">OurBaseComponent<\/span> <\/span>{\n    state = createState({<span class=\"hljs-attr\">todos<\/span>: &#91;]});\n\n    render() {\n        <span class=\"hljs-keyword\">this<\/span>.doRender(<span class=\"hljs-function\"><span class=\"hljs-params\">()<\/span> =&gt;<\/span> {\n            <span class=\"hljs-keyword\">this<\/span>.innerHTML = <span class=\"hljs-string\">`&lt;h1&gt;You have <span class=\"hljs-subst\">${<span class=\"hljs-keyword\">this<\/span>.state.todos.length}<\/span> todos&lt;\/h1&gt;`<\/span>\n        })\n    }\n  }\n\n  customElements.define(<span class=\"hljs-string\">'my-component'<\/span>, MyComponent);\n<\/span><span class=\"hljs-tag\">&lt;\/<span class=\"hljs-name\">script<\/span>&gt;<\/span><\/code><\/span><small class=\"shcb-language\" id=\"shcb-language-4\"><span class=\"shcb-language__label\">Code language:<\/span> <span class=\"shcb-language__name\">HTML, XML<\/span> <span class=\"shcb-language__paren\">(<\/span><span class=\"shcb-language__slug\">xml<\/span><span class=\"shcb-language__paren\">)<\/span><\/small><\/pre>\n\n<p>That\u2019s only 13 lines to declare a UI component!<\/p>\n\n<p>Only now you have a bug with namespace collision of state with underscores, your <code>doRender<\/code> doesn\u2019t handle async functions, and you still have many of the downsides listed below!<\/p>\n\n<p>You could work on fixing these, but ultimately, you\u2019ve created a basis of what Lit looks like today, but now you\u2019re starting at square one. No ecosystem on your side, no upstream maintainers to lean on.<\/p>\n\n<h2 class=\"wp-block-heading\">Pros and Cons of Lit Framework<\/h2>\n\n<p>With the downsides (and upsides) of vanilla web components in mind, let\u2019s compare the pros and cons of what building components using Lit looks like:<\/p>\n\n\n<table class=\"wp-block-table\">\n    <tbody>\n        <tr>\n            <th>\n                Pros\n            <\/th>\n            <th>\n                Cons\n            <\/th>\n        <\/tr>\n        <tr>\n            <td>\n                <ul>\n                    <li><span>Faster re-renders* that are automatically\n                            handled<\/span><\/li>\n                    <li><span>More consolidated UI\/logic<\/span><\/li>\n                    <li><span>More advanced tools after mastery<\/span><\/li>\n                    <li><span>Smaller footprint than other frameworks<\/span><\/li>\n                <\/ul>\n            <\/td>\n            <td>\n                <ul>\n                    <li><span>Framework knowledge required<\/span><\/li>\n                    <li><span>Future breaking changes<\/span><\/li>\n                    <li><span>Not as widely known\/used as other frameworks (Vue,\n                            React, Angular)<\/span><\/li>\n                <\/ul>\n                <p><span><\/span><\/p>\n            <\/td>\n        <\/tr>\n    <\/tbody>\n<\/table>\n\n\n<p>While there is some overlap between this list of pros and cons and the one for avoiding Lit in favor of home-growing, there\u2019s a few other items here.<\/p>\n\n<p>Namely, this table highlights the fact that Lit isn\u2019t the only framework for building web components. There\u2019s huge alternatives like React, Vue, and Angular. These ecosystems have wider adoption and knowledge than Lit, which may make training a team to use Lit more difficult.<\/p>\n\n<p>However, Lit has a key advantage over them, ignoring being able to output to web components for a moment &#8211; we\u2019ll come back to that.<\/p>\n\n<p><br>Even compared to other frameworks, Lit is uniquely lightweight.<br><br>Compare the bundle sizes of Vue &#8211; a lightweight framework in it\u2019s own right &#8211; compared to Lit.<\/p>\n\n\n<figure class=\"wp-block-image\"><a href=\"https:\/\/bundlephobia.com\/scan-results?packages=vue@3.2.14,lit@2.0.0\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" src=\"https:\/\/coderpad.io\/wp-content\/uploads\/2021\/12\/img_61a943cd4417d.png\" alt=\"Lit weighs in at 16.3 kilobytes while Vue weighs in at 91.9 kilobytes\"\/><\/a><\/figure>\n\n\n<p>While tree shaking will drastically reduce the bundle size of Vue for smaller applications, Lit will still likely win out for a simple component system.<\/p>\n\n<h2 class=\"wp-block-heading\">Other Frameworks&nbsp;<\/h2>\n\n<p>Lit framework isn\u2019t alone in being able to output to web components, however. In recent years, other frameworks have explored and implemented various methods of writing code for a framework that outputs to web components.<\/p>\n\n<p><br>For example, the following frameworks have official support for creating web components without changing implementation code:<\/p>\n\n\n<ul class=\"wp-block-list\"><li><a href=\"https:\/\/v3.vuejs.org\/guide\/web-components.html#definecustomelement\" target=\"_blank\" rel=\"noopener\">Vue<\/a><\/li><li><a href=\"https:\/\/angular.io\/guide\/elements\" target=\"_blank\" rel=\"noopener\">Angular<\/a><\/li><li><a href=\"https:\/\/github.com\/preactjs\/preact-custom-element\" target=\"_blank\" rel=\"noopener\">Preact<\/a><\/li><\/ul>\n\n\n<p>Vue 3, in particular, has made massive strides in improving the web component development experience for their users.<\/p>\n\n<p>What\u2019s more is that these tools tend to have significantly larger ecosystems. Take Vue for example.<\/p>\n\n\n<p>Want the ability to change pages easily? <a href=\"https:\/\/router.vuejs.org\/\" target=\"_blank\" rel=\"noopener\">Vue Router<\/a><\/p>\n\n\n\n<p>Want a global store solution? <a href=\"https:\/\/vuex.vuejs.org\/\" target=\"_blank\" rel=\"noopener\">Vuex<br><\/a>Prefer similar class based components? <a href=\"https:\/\/class-component.vuejs.org\/\" target=\"_blank\" rel=\"noopener\">Vue Class Component Library<\/a><\/p>\n\n\n\n<p>Prebuilt UI components? <a href=\"https:\/\/www.antdv.com\/docs\/vue\/introduce\/\" target=\"_blank\" rel=\"noopener\">Ant Design<\/a><\/p>\n\n\n<p>While some ecosystem tools might exist in Lit, they certainly don\u2019t have the same breadth.<\/p>\n\n\n<p>That\u2019s not to say it\u2019s all good in the general web component ecosystem. Some frameworks, like React, <a href=\"https:\/\/custom-elements-everywhere.com\/\" target=\"_blank\" rel=\"noopener\">have issues with Web Component interop<\/a>, that may impact your ability to merge those tools together.<\/p>\n\n\n<h2 class=\"wp-block-heading\">Why Web Components?<\/h2>\n\n<p>You may be asking &#8211; if you\u2019re going to use a framework like Vue or React anyway, why even bother with web components? Couldn\u2019t you instead write an app in one of those frameworks, without utilizing web components?<\/p>\n\n<p>You absolutely can, and to be honest &#8211; this is how most apps that use these frameworks are built.<\/p>\n\n<p>But web components play a special role in companies that have multiple different projects: Consolidation.<\/p>\n\n<p>Let\u2019s say that you work for BigCorp &#8211; the biggest corporation in Corpville.<\/p>\n\n<p>BigCorp has dozens and dozens of full-scale applications, and not all of them are using the same frontend framework. This might sound irresponsible of BigCorp\u2019s system architects, but in reality, sometimes a framework is better geared towards specific applications. Additionally, maybe some of the apps were part of an acquisition or merger that brought them into the company.<\/p>\n\n<p>After all, the user doesn\u2019t care (or often, know) about what framework a tool is built with. You know what a user does care about? The fact that each app in a collection all have vastly different UIs and buttons.<\/p>\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/coderpad.io\/wp-content\/uploads\/2021\/12\/img_61a943cea067b.png\" alt=\"Two different apps, each with different text cutoff points in their button's text\"\/><\/figure>\n\n\n<p>While this is clearly a bug, if both codebases implement the buttons on their own, you\u2019ll inevitably end up with these types of problems; this being on top of the work-hours your teams have to spend redoing one-another\u2019s work for their respective frameworks.<\/p>\n\n<p>And that\u2019s all ignoring how difficult it can be to get designers to have consistency between different project\u2019s design components &#8211; like buttons.<\/p>\n\n<p>Web Components solve this problem.<\/p>\n\n<p>If you build a shared component system that exports web components, you can then use the same codebase across multiple frameworks.<\/p>\n\n\n<p>Once the code is written and exported into web components, it\u2019s trivial to utilize these new web components in your application. Like, it can be a <a href=\"https:\/\/v3.vuejs.org\/guide\/web-components.html#tips-for-a-vue-custom-elements-library\" target=\"_blank\" rel=\"noopener\">single line of code trivial.<\/a><\/p>\n\n\n<p>From this point, you\u2019re able to make sure the logic and styling of these components are made consistent between applications &#8211; even if different frameworks.<\/p>\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n<p>While web components have had a long time in the oven, they came out swinging! And while Lit isn\u2019t the only one at the table, they\u2019ve certainly found a strong foothold in capabilities.<\/p>\n\n<p>Lit\u2019s lightweightness, paired with web component\u2019s abilities to integrate between multiple frameworks is an incredible one-two punch that makes it a strong candidate for any shared component system.<\/p>\n\n<p>What\u2019s more, the ability to transfer knowledge from other frameworks makes it an easy tool to place in your toolbox for usage either now or in the future.<\/p>\n\n<p>Regardless; whether you\u2019re using Vue, React, Angular, Lit, Vanilla Web Components, or anything else, we wish you happy engineering!<\/p>","protected":false},"excerpt":{"rendered":"<p>Lit\u2019s lightweightness, paired with web component\u2019s abilities to integrate between multiple frameworks is an incredible one-two punch that makes it a strong candidate for any shared component system.<\/p>\n","protected":false},"author":1,"featured_media":3563,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[9],"tags":[],"persona":[29],"blog-programming-language":[62],"keyword-cluster":[],"class_list":["post-3532","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-development"],"acf":[],"_links":{"self":[{"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/posts\/3532","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/comments?post=3532"}],"version-history":[{"count":17,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/posts\/3532\/revisions"}],"predecessor-version":[{"id":8052,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/posts\/3532\/revisions\/8052"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/media\/3563"}],"wp:attachment":[{"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/media?parent=3532"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/categories?post=3532"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/tags?post=3532"},{"taxonomy":"persona","embeddable":true,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/persona?post=3532"},{"taxonomy":"blog-programming-language","embeddable":true,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/blog-programming-language?post=3532"},{"taxonomy":"keyword-cluster","embeddable":true,"href":"https:\/\/coderpad.io\/wp-json\/wp\/v2\/keyword-cluster?post=3532"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}