Feature requests for Lit-based app framework #2462
Replies: 21 comments 29 replies
-
I often see the term "full-stack" receive the traditional interpretation of client and server, but it'll be exciting how that could be expanded to mean client, worker, and server. A framework built with workers (server, shared, web) as an first party citizen from the start should be able to find yet another level of benefits from established patterns like PRPL, or app-shell, or Islands Architecture, while expanding on other new patterns; all of which could serve consumers whether they at the "I need to make a blog" side of web development or all the way on the other working to replacement of a native app with a web-first property. Some really interesting areas for a framework of this sort to possibly explore/support:
|
Beta Was this translation helpful? Give feedback.
-
HTML-First Hydration I'd like to see (at least an option for) stampino templates sent over the wire in HTML for hydration, for slimmer hydration bundles |
Beta Was this translation helpful? Give feedback.
-
Multi Page I'd like to see an emphasis on MPA and progressive enhancement |
Beta Was this translation helpful? Give feedback.
-
I would like to see, if it is not LIT specific, but more WebCOmponents specific. |
Beta Was this translation helpful? Give feedback.
-
The only thoughts I have are that you take the same philosophy that Polymer took (as I understood it) - ie prefer to use the platform technologies, or develop/extend features with a view to eventually improving the native platform/standards, and are done in the same style as the platform. Usually, this boils down to "don't try to be too clever" and "don't throw away, but prefer to fix/improve/extend what is already there". |
Beta Was this translation helpful? Give feedback.
-
I think everyone is really excited to see this potentially becoming a thing. I've tried to collect a few initial thoughts here below they are currently a bit scattered at the moment and are more of a brain dump but would be happy to answer any follow up questions on things that don't make sense. Uses "the platform" / standards based Abstracting away cross browser issues Forward Looking Capabilities / Patterns Focused const pubSub = new PubSub();
pubSub.addChannel('analytics-events');
pubSub.addListener({listener: myAnalyticsService, channel: 'analytics-events'}); Some other examples that come to mind would be when I need to store data, when I need a queuing system, when I need to run a task. But just general building blocks is what I am looking for here. In that example of when I need to run a task for example it would be nice to know that all of the "best practices" are taken care of for me under the hood and if it needed to push that out into a worker to get it off the main thread that just happened without me having to think about it. Relatively Strong Opinions At the end of the day I would love for you to be able to say that you know what, after years of building some of the biggest apps in the world like YouTube we have taken all of that knowledge and put it into a framework for you. Here it is... as opposed to death by 100% communal design. Server Side Stuff
But those 3 aspects feel rather distinct to me and I could easily see them as 3 different pieces that can work together rather than a single homogeneous thing. Points 2 and 3 there don't necessarily have much there specific to Lit and people tend to already have good solutions like Envoy or something similar. |
Beta Was this translation helpful? Give feedback.
-
My team and myself have been working on a code generator. I am not sure if I am too old for this crowd, but back in the '90s we had amazing tools to create software -- they were called CASE technologies (https://en.wikipedia.org/wiki/Computer-aided_software_engineering). I have kind of recreated something like that, but using the command line rather than fancy UI (command line is quicker to make). I called it JS-KIT (the name might change). This is what it looks like when it's run:
The beauty of it is that you can add as many pages as you like. And it allows for list, view and add/edit elements. You can add an element inside another one, and everything is routing aware etc. The catch is that it generates client and server code. I know a lot of people out there (especially at Google) are keen on firebase etc. JSKIT on the other hand creates fully features endpoints which will talk to the database. I don't think this is the level you want to get to, but the end result -- that is, the app that is generated -- is very much framework-y. It was meant to be finished months ago, but then school holidays (7 weeks here in Australia over summer, over tomorrow!) and life got in the way. We are about a month away from being done. I am not sure you'd want to embrace our far-reaching project, but I am all for code generation based on templates. |
Beta Was this translation helpful? Give feedback.
-
Awesome! And I think the philosophy behind Lit itself is a perfect way to approach this. It's a very powerful layer that enhances the platform features, gives us opinionated ways to build on it (Reactive Controllers, directives) but still allows good control. I really like the direction of the initial ideas here. We have some very powerful platform features that are not used to their full potential, and popular frameworks tend to make that harder, as people will just go with whatever is ready to use. I'd love to see things like workers and Wasm get more attention and be used to implement less common or new patterns. But the basics will determine adoption, ultimately. I'm living a very relevant scenario. I was hired for a project that used Lit. An offline-first PWA. It is severely hindered by lack of standards, documentation, no SOLID principles, and a complete misunderstanding of how Lit and a reactive, function of data UI works. It would certainly be salvageable, even with messy code, if they had access to a Lit-based framework with clear patterns for the basics:
Instead, it's a total rewrite case, and execs decided to move to React, so they would have a better chance at hiring devs. So, in the end, I'd say it boils down to: How much does it need to have baked in, in terms of patterns and components, so that small teams can build something nice, and big teams can have people working on small pieces that will integrate well. All without feeling like learning a whole new platform. If you can do that while also extracting the most of existing platform features, I'd bet that's a winner. |
Beta Was this translation helpful? Give feedback.
-
We've been building Web Components apps since Polymer 0.5 in 2014, with 10+ open source apps launched into production. We love the flexibility Web Component offer when building web apps and Lit is just great! :) For us, the Polymer Paper, Iron & App elements were the main practical elements of an app framework and have worked great for us. Most of our web apps are now Lit & TypeScript but still use Paper elements and some smaller apps use earlier alpha versions of md2 components. But our main and most complex app is currently using md2 alpha in dev and depends on the md3 production components to go live soon, hopefully! ;) For our main app with 100+ custom app components, our production branch is still Polymer 2. We miscalculated, badly, how quickly there would be a production-ready material design replacement for Paper elements and we've had to implement new features both in Polymer & Lit now for the past year and continue to do so. The key features that would be the most helpful for us would be everything around PWA functionality, like service workers, offline & other PWA features. If you go down the route to create the framework around md3 apps then I'm also sure we could learn from best practices on how to stitch an app like that together - like how best to handle events and UI flows. Or examples on how to use md3 components with the app framework. |
Beta Was this translation helpful? Give feedback.
-
What I'd also like to see, is a helper component like "iron-list" in polymer. A Component wich helps to build a scrollabel list, with reload, selection, ... and much more. https://chromestatus.com/feature/5673195159945216 but no. And I would like to see that, but not in Lit, I would love to see a dependecy less version (wich could be used with any library), but don't know if something like this would be part of the framework |
Beta Was this translation helpful? Give feedback.
-
Why wouldn't you just contribute to |
Beta Was this translation helpful? Give feedback.
-
Not sure if this would be the right place for this suggestion, but running a website with ~80 web components (some of them are lazy loaded), it would be nice to be able to defer the initiation of a component until it's rendered (or until idle?). This would mostly make sense for off-screen elements such as modals/dialogs, etc. to avoid CLS. It would reduce the initial strain on the browser when it has to run all the firstUpdated lifecycle methods of all the components on the page. This could be created as another lifecycle, and you typically see such events in frameworks such as Ionic (for example I haven't measured the impact of this, but I'm happy to experiment by creating a controller that short-circuits the firstUpdated() callback of invisible components. |
Beta Was this translation helpful? Give feedback.
-
I'll try to contain my excitement since I've been looking forward to this since the launch of Lit. I think it's best if I break this down in 3 parts since it sounds like said framework would potentially support static sites and complex PWA's. Part 1 - Snipclip PWAI am in the process of revamping and expanding my PWA Snipclip. That project is currently an SPA built with Lit components all the way down. It uses an implementation of the PWA Helper Router and is built with Vite. Nothing too fancy just Lit components and Vite. I've tried building it several ways and none of them felt like the right fit. I tried 11ty and Astro and even briefly tried Lit inside of a NextJS project using the React wrapper. While I enjoy 11ty and Astro as static site builders they just don't feel like the right tools for building what will eventually be a complex PWA. They both don't have a true "SPA-mode switch" and likely won't ever from what I understand about their goals. I want SSR for some of my planned features and while Astro is working on SSR it still will be in an MPA context using a framework that isn't designed for SPA's. After all my testing I've found my current setup as a custom SPA built with Vite is still the best option for that project's goals and remaining 100% Lit 🔥 Part 2 - Static Site Generator Experience/ObservationsI've tried Gatsby, Next, 11ty, and Astro. I've moved away from React so I'll cover the HTML-first options. I work full-time for a marketing agency and most of our projects are static sites. We've landed on Lit and Astro as our current SSG stack. Astro
11ty
Part 3 Wishlist/TL;DR (in order of importance)
|
Beta Was this translation helpful? Give feedback.
-
For me, the thing I keep wanting is a framework to develop rich web applications that use the web’s standards for its foundation. On top of that, it would add and improve to that foundation, while adding abstractions on top of the more finicky bits (like managing network state and caching). I could even see a tool like this taking a leaf out of TypeScript’s book by allowing the use of future browser features. These more forward-focused features could be integrated through progressive enhancement so that older browsers still receive an equivalent experience. An example of this could allow developers to use the new The reason why Remix interests me so much (admittedly I haven’t used it) is that the philosophy is to work closely with the web platform’s features, (like HTTP caching, prefetching resources). I would love to see something like this, but for web components. I know it sounds a little hand-wavy, and more vision-y than anything concrete (sorry I can’t be more specific I haven’t had any experience building frameworks 😅). With all that being said, another option is having Lit expand its core offering with primitives that deal with app-level concerns, which could be used to build the foundations of a framework. Again, I have no experience with framework development, so I understand if this is idealistic and not realistic. It’s an interesting problem space, and I’m very excited to see how it progresses 😊 |
Beta Was this translation helpful? Give feedback.
-
Honestly, Lit is good enough for UI as it is, with SSR, localization, router, context, and other upcoming "labs" it's going to be even better. In my opinion, what Lit had been lacking was not a "full-stack framework", but branding and promotion. The React world is a zoo of disconsonant technologies, yet they all share the brand making it easier to promote among non-web crowds. Angular completely changed since the first version, but it's still Angular. Meanwhile, Polymer died as browsers failed to adopt some APIs, we got bits of it in lit-html/LitElement and almost no promotion. From the outside, it looked like Google went with Angular and left Polymer/LitElement to its fate... I'm happy that now things are coalescing into Lit and getting some daylight. I believe many suggestions here can be implemented with the existing Lit capabilities, and the fact that it's not immediately obvious is the issue: we need more examples, tutorials, and in general, we have to develop conventions and recommendations as to how to solve common problems with Lit. Though again, I like what's been done already at lit.dev. |
Beta Was this translation helpful? Give feedback.
-
Coming from an Angular background, there are a fair amount of additional packages I need for a full app.
Overall I really like using Lit. I feel like I am just "coding in Typescript" and it all comes together very well and is ridiculously fast and lightweight. The whole idea of web components using lit-html is so clean. There is almost no learning curve. Having something that is more frameworky is enticing. |
Beta Was this translation helpful? Give feedback.
-
Speed, over all other metrics
No Fuss Tooling, over perfection
Open About Borrowed Metrics
TL;DRThat which makes up a framework, such as routing, state management, build systems and ... and ... and ... all involve imperfect tradeoffs - by definition. What makes this extremely difficult is the vast number of somewhat arbitrary choices that have to be made to settle on an opinion or tradeoff. That's why high level objectives are so much more critical than the infinite number of lower level concerns that the rest of us have to wrestle with on a daily basis. Lit in 2022 is the product of almost a decade of tradeoffs. In that sense, it is a mathematical sweet spot. One reason it is so perfect is that it does not venture into the framework areas where decisions have to be so arbitrary, and more like 'mark to Svelte or Next.js and hold as a metric for a year or two until we settle in" Justin, Gray, etc have steered carefully past a minefield of infinite discussions and comparisons, over the years, by simply making choices based on those knowable tradeoffs. It is the careful tradeoffs, not the perfection, that has made things work? Is that true? This tension between arbitrary decisions and evolving metrics (speed, etc) is to be celebrated. The best frameworks resolve such tension by moving between such tradeoffs openly, rather than simply adopting one and holding to it, like maybe JSX based frameworks, or it's opposite by never committing to specific approach because someone might be offended or have a more perfect approach. |
Beta Was this translation helpful? Give feedback.
-
As somebody who's been using NextJS a lot lately, but isn't a huge React fan, I have been wanting this so bad. I've actually been working on something of a NextJS for web components myself. What I've realized is that it's all there and possible, it's a matter of creating an opinionated method of getting things done and bundling things together. When I have written apps using Polymer and Lit, I've encountered some pain points that I'd love to see in a framework, in no particular order:
|
Beta Was this translation helpful? Give feedback.
-
I don't have any professional experience with full stack, just used SvelteKit for personal demo projects and enjoyed it. I had a play with a Lit SSR example app based on the lit-labs demo and it makes sense and is very fast & light, but I reckon there's more to get my head around as a newcomer. These are the "wants" I can think of. Mostly a focus on developer experience. Most of these things are already achievable, but for me as a beginner, knowing how to do them in a sensible structured way is tough.
I know it's early in the process but this is quite exciting news. |
Beta Was this translation helpful? Give feedback.
-
I very much would love to see a |
Beta Was this translation helpful? Give feedback.
-
I have a question, why does Lit use class components instead of function components (hooks), because class components is more in line with ECMA and Browser standards? 👀 |
Beta Was this translation helpful? Give feedback.
-
The Lit team is starting to investigate what it would look like for us to offer a comprehensive, opinionated, "full-stack" application framework.
The idea of an application framework is very broad, open to lots of different takes on what a framework should include. Such a framework might be similar in scope to other projects like Next, Remix, Nuxt, SvelteKit, etc., as well as Google-internal frameworks that the Lit team has experience with. The scope of related projects can range from static-site-generators, to servers with runtime server-side rendering. Some focus on single-page-apps, others on multi-page-apps.
It's extremely early in this process. At this point we're researching, gathering requirements, and analyzing common problems and solutions in this space.
We'd love to start a discussion about what problems our users are facing in this general area and what kinds of things you would like to see in an application framework. Do you build full apps? Have you built your own helpers? Used third-party libraries designed for Lit or web components? Are you familiar with full-stack systems for other frameworks? What do you like or dislike about them? We want to hear it all! 😁
Beta Was this translation helpful? Give feedback.
All reactions