Feature requests for Lit-based app framework

[justinfagnani]

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! 😁

[Westbrook]

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:

• offline first patterns: A great first load is critical, but making all the next loads work, no matter where they happen is next level. Is a tight coupling between this process and the lazy loading process possible so that it's dead simple to manage, content => content loading => content loaded or can't load and all the in between.
• service worker stitching: Supporting a number of contexts, including a lot of the above, the stitching of content in the service worker (with similar or shared architecture as a server) means that less content needs to go over the wire to support all of the app/site. Finding ways for this to "just work" as pages come together would make experimenting with and adopting these sorts of pattern less of an after thought for application developers.
• sub-route loading: Sometimes this can be handled simply by a router or simply by service worker stitching, but as the loading of this is pushed into the lazy size, there should be even more benefits to the less linear route this will allow a visitor to load our sites by while continuing to push the boundaries of "instant" when loading content.
• lazy but smart "CDN-ing" of element registrations: Lazy loading of raw esModules is a beautiful future, but sadly still feels like it's pretty far in the future. Some development tools address this by pre-bundling dependencies in isolation, and often route based bundling does this at a level between a single dependency and an entire application. However, a "full-stack" solution should be able to allow a visitor to make it through the app any number of paths getting only what they need in an even more nuanced way, something that splits the isolated dependency bundle and route bundle gap the way route bundles previously split the isolated dependency and single bundle gap. While taking this on, delivering these more unique bundles without running into multi-registration issues will be key.
• patterns for multithreading processing: much more aspirational than other ideas, but more generally put the idea that a framework of this kind could support more complex applications by design rather than as a "hey, it's possible..." will do interesting work to ensure it's not seen as "just another X" and clearly outline how serious it would be taking the breadth of responsibilities something like this would be beneficial in addressing.

[bennypowers]

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

[justinfagnani]

How do you see that leading to smaller hydration bundles? I don't think Stampino templates would be fewer bytes than lit-html templates.

[bennypowers]

It would be way less javascript though. If I have to send almost-the-same markup over the wire twice, I'd rather have the HTML parser handle it first rather than defer to JS parsing

[Westbrook]

There’s a lot of cool areas to explore here. Working with an integrated server likely surfaces options around leveraging the much theorized “compiled lit-html” template that might serve both sides of this convo. Write stampino templates and have the server/worker side of the architecture decide the best way to deliver those to your users. Could see this as being fertile testing ground for future integration of the HTML Module Script specification. 🤩🤩

[bennypowers]

Multi Page

I'd like to see an emphasis on MPA and progressive enhancement

[justinfagnani]

This one is definitely on our list, though I've been impressed with how some efforts in this area blur the line between the two.

[jogibear9988]

I would like to see, if it is not LIT specific, but more WebCOmponents specific.
We Previously used Polymer, and now we use our own Basic component because we mostly used Polymer $ dom component access, and do not like the "render" aproach so much. But we'd like to be also be possible to use this without the need of importing LIT

[justinfagnani]

It's Lit, not LIT

But yes, much of our work already is intended to be library agnostic. The SSR library uses an interface to delegate to library-specific code, so other libraries or individual components can implement that server-side interface.

[davidmaxwaterman]

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".
Of course, there's no problem with being super 'clever' under the hood, if need be.
Some frameworks/libraries (you know who you are!) seem to have gone out of their way to develop things that are incompatible with the platform and standards, so there's little to no hope of them being adopted 'long term' except by way of dominance (ie a de facto standard).

[jogibear9988]

Yes, my framework nearly does nothing more than a few Syntatic-Sugar helpers, to get the elements. So you Can query for them, before ShadowRoot is attached, Get event bindings... Only a few little things.
The one thing I don't like on LIT are the comments wich are added to HTML, but thats how it works...
I only wanted to share, I think it should be a framework, for all WebComponents, maybe lot's of small helpers wich all could be used independly

[mark-dropbear]

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
This is something that already feels extremely tied to Lit as it exists today and I am kind of assuming will continue to be true into the future as opposed to say something like React which seems to do a lot of re-implementing things that are already in modern web browsers (events etc...). But I think this is a core value that gives me confidence as a developer that I am not slowly building myself into an ecosystem that gets more and more cut off from everything else on the web as time goes on.

Abstracting away cross browser issues
Modern web development is in as good of a place as it has ever been in many ways but sadly Safari is still a major thorn in everybody's side when it comes to making things work consistently. Absolutely nobody wants to be hand rolling and testing that kind of code if they don't have to and is exactly the kind of thing I am looking for in a framework.

Forward Looking
Again, this also feels pretty inline with where Lit is today but looking at the next few years there are a lot of really exciting developments on the horizon for the web as a platform that is going to open a lot of new doors for how we build applications. Ideally, they are things that I don't want to have to give up on because the framework I am using made a lot of assumptions when it was first built and therefore can't easily adapt to platform changes because everything was architectured a very specific way. Some specific things that come to mind for me here would be technologies such as HTTP/3, gRPC, WASM, Service Workers, WebGPU etc. I can also see scenarios where maybe some things in my application are handled via technologies like Flutter doing canvas based rendering for example, furthermore maybe that is running inside of a WASM module (this is a real thing that the Flutter team are working towards in 2022 for the record). Being able to hook up those things would ideally not be a nightmare. I could share data back and forth, I could understand when key events have happened in each end and respond to them etc..

Capabilities / Patterns Focused
This is a hard one to capture well but anyways :)
I don't really want to spend a lot of time thinking about how things are done. For example: I want a pub-sub system which gives me channels to send and receive messages on and react to them, I would like that to work in the DOM, in a service worker, across tabs etc. I don't care much about how that works specifically and is exactly the kind of thing that I want to push to a team of experts I just want to be able to write something like:

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
I think there are already more than enough options out there for the I want to roll my own everything by hand using home-grown patterns crowd and I don't really want to see whatever this becomes end up more as this very wishy-washy you can do it however you want framework. This is maybe the singular most popular thing that enterprises say about Angular for example and is a reason why it is the obvious default choice for a lot of their use cases. Angular for any of its flaws has actually done an amazing job on this and as a result has been able to build a lot of really amazing tooling on top of it that generally makes for a really slick developer experience.

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
My biggest fear here is kind of getting locked into Node too much. There are 3 main components to this for me when it comes to server side stuff:

1. Rendering: I just want to say here is the template and here is the data and getting back my declarative shadow DOM ready to send
2. The actual serving of the content. PRPL looked like an amazing start on this back in the day.
3. Communication between browser and server. There are a lot of transports to think about now beyond just standard HTTP, in fact, I might even make the argument that for most apps I build beyond getting the static content to a user over HTTP I don't actually want to use it much beyond that. I would much rather be able to reach for a bi-directional stream using gRPC for example.

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.

[mercmobily]

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:

merc@merc-All-Series:~$ node Development/scaffoldizer/bin/scaffoldizer -s Development/js-kit -d testing-app add 
Using direct path for scaffold
✔ Chose what you want to add › Reinstallable components
✔ Pick a component to add › client-app-root-page
Installing client-base
> index.html
> src/TestingApp.js
> src/testing-app.js
Installing client-app-frame

Pick the previx of your app's elements. If you pick 'my', elements will be 'my-something', 'my-something-else' and so on

✔ App name … Welcome
✔ Elements' name prefix … my
✔ Enable dynamic loading of pages … off / on
> src/elements/.elements
> src/lib/base/AppElement.js
> src/lib/base/AppElementMixins/ResponsiveMixin.js
> src/lib/base/PageElement.js
> src/lib/base/RoutedElement.js
> src/lib/base/elements/my-header.js
> src/lib/base/elements/my-page-header.js
> src/lib/base/elements/my-toggle-button.js
> src/lib/media-query.js
> src/lib/metadata.js
> src/lib/stores/store-stuff-will-be-here
> src/pages/.pages
> src/styles/app-theme.js
> src/styles/icons.js
> src/styles/shared-styles-animations.js
> src/styles/shared-styles-button.js
> src/styles/shared-styles.js
Installing client-app-root-page
> src/pages/my-landing.js
Installing client-app-root-page
> src/pages/my-not-found.js
Installing client-app-root-page
> src/pages/my-load-error.js
Installing client-app-root-page
✔ Page element name … welcome
✔ Page title … Welcome
✔ Page menu title … Welcome
> src/pages/my-welcome.js

merc@merc-All-Series:~$ node Development/scaffoldizer/bin/scaffoldizer -s Development/js-kit -d testing-app add ;
Using direct path for scaffold
✔ Chose what you want to add › Underlying module
✔ Pick several moduless to install › client-app-stores, client-eslint, server-base, server-db, server-db-sessions, server-stores
Installing server-base
> server/app.js
> server/distributed
> server/envConfig/development.json
> server/envConfig/production.json
> server/envConfig/staging.json
> server/lib/asyncMiddleware.js
> server/lib/dummySession.js
> server/package.json
> server/routes/alwaysIndex.js
> server/routes/appInfo.js
> server/routes/errorPage.js
> server/routes/maybeRedirectToHttps.js
> server/vars.js
> server/www
Installing server-stores
✔ URL prefix for all stores … stores
✔ Default store version … 1.0.0
Installing client-app-stores
> src/lib/base/AddEditElement.js
> src/lib/base/AddEditPageElement.js
> src/lib/stores/AddEditCommonMixin.js
> src/lib/stores/StoreMixin.js
Installing client-eslint
> .eslintrc.json
Installing server-db
✔ DB host … localhost
✔ DB port … 3306
✔ DB name … jskit
✔ DB user … root
✔ DB password … whatever <--- This is a dummy password
> server/lib/makeDbConnection.js
Installing server-db-sessions
✔ Session secret sentence … secret
✔ Session key (in cookie) … testing-app
merc@merc-All-Series:~$ node Development/scaffoldizer/bin/scaffoldizer -s Development/js-kit -d testing-app add ;
Using direct path for scaffold
✔ Chose what you want to add › Reinstallable components
✔ Pick a component to add › client-app-root-page
Installing client-app-root-page
✔ Which type of page? › View page
✔ Page element name … person
✔ Page title … Person
✔ Page menu title … Person
✔ Would you like to create a new store for this element? … yes
Installing server-store
✔ What type of store is it? › DB store
✔ Store name (camel case, starting with lower case) … people
✔ Store version … 1.0.0
✔ Store URL. /1.0.0 … /people
✔ DB table name … people
✔ Should the store manage positioning of rows? … yes
✔ Which HTTP methods? › GET -- one element (e.g. GET /store/1), GET -- several elements (e.g. GET /store), PUT (e.g. PUT /store/1), POST (e.g. POST /store)
✔ Would you like to set more advanced options? … no
✔ Would you like to set this store's fields? … yes
Fields:

✔ What do you want to do? › Add a new field
✔ Field name … name
✔ What kind of field is it › String
✔ Is NULL allowed? (Default is "no", only ever use it if "" is different to "no value" NULL) … no
✔ Field max length … 255
✔ Should trimming be skipped? (leading and trailing spaces will be preserved) … no
✔ Is this field searchable? (An index will be created) … yes
✔ Is this field unique? … no
✔ Default value for this field (leave empty for no default, and "NULL" for null) … 
Fields:
      name: { type: 'string', length: 255, searchable: true },

✔ What do you want to do? › Add a new field
✔ Field name … surname
✔ What kind of field is it › String
✔ Is NULL allowed? (Default is "no", only ever use it if "" is different to "no value" NULL) … no
✔ Field max length … 255
✔ Should trimming be skipped? (leading and trailing spaces will be preserved) … no
✔ Is this field searchable? (An index will be created) … yes
✔ Is this field unique? … no
✔ Default value for this field (leave empty for no default, and "NULL" for null) … 
Fields:
      name: { type: 'string', length: 255, searchable: true },
      surname: { type: 'string', length: 255, searchable: true },

✔ What do you want to do? › All done adding fields, go ahead with changes
✔ Which fields are sortable? › name, surname
> server/stores/1.0.0/people.js
✔ Would you like to sync up the DB's schema with this store? … no
> src/pages/my-view-person.js
merc@merc-All-Series:~$ 

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.

[freudFlintstone]

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:

• Layout/Page components templates
• UI components templates
• Routing
• Shared state
• Offline usage
• Persistent data management
• API communication

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.

[rbjarnason]

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.

[justinfagnani]

We don't have any plans yet for a replacement for Iron, and App elements. MWC should be the upgrade path for Paper elements.

The full-stack app framework concept we're considering isn't so much about components - it might have a couple for optimizing images, using a router, and/or enhancing forms.

[davidmaxwaterman]

I do miss the iron/app elements. I very much liked the non-visual elements, but maybe they don't quite fit into the 'javascript' focused Lit.

I spent an aweful amount of time trying to make a simple page layout element that just had a header, main, and footer, with various optoins...the problem, as ever, was mostly about mobile Safari and iPhones. IIRC, the number of combinations of things that changed the layout needed testing was up in the 60s due to the exponential nature of the possibilities. orientation, URL bar visibility, toolbar visibility, notch/no-notch, in-browser or from homescreen, and then different browsers too. One 'hmf-layout' that would 'just work' on all platforms/browsers would have saved me a lot of work.
I'm sure there are plenty of other scenarios too.

Still, for sure not what is meant by 'application framework' - but I do wonder if perhaps the usual meaning of that term might not apply especially well to web components, or if, perhaps, we shouldn't be limited by what that means today.

[rbjarnason]

We stopped using iron/app elements a while ago, and for most functionality, it was relatively easy to find replacements, except iron-list (until lit-virtualizer) & iron-form, which we ported to Lit & MWC.

In 2014 the Paper elements got us into Polymer and Web Components. We wanted to create a progressive web app and there were Paper elements to make our lives easier for the UI and Iron/App for a whole app framework. Since starting building websites, in 1993, I've never enjoyed the work so much! :) But we'd never consider Polymer without Paper as a solution, we were building an app and we needed a great UI.

[jogibear9988]

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.
I hoped we would get something like this from virtual scroller proposal

https://chromestatus.com/feature/5673195159945216
https://github.com/WICG/virtual-scroller/blob/main/README.md

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

[justinfagnani]

That's probably out of scope for the app frameworks concept (it's not components so much), but we have been working on a virtual scroller: https://github.com/PolymerLabs/uni-virtualizer/tree/master/packages/lit-virtualizer

[jogibear9988]

Thanks for the info.

[rbjarnason]

We use lit-virtualizer and it's a great replacement for iron-list.

[MikeVaz]

Why wouldn't you just contribute to Open WC, Web dev server or similar.
It seems like your project would largely overlap with the those.
On top of that you can show a way to collaborate with other teams and projects and contribute to the open source community.
I wouldn't like you repeating the similar missteps like you did with Andrea's hyperhtml. A chance for you to make it right this time.

[justinfagnani]

Sorry, it's quite debatable whether there were missteps with HyperHTML. I'm not going to even further entertain that discussion.

We work with Open WC already, meet with them monthly, and are the largest sponsor of the project. There isn't actually much if any overlap with their work and they will be among the first to know what we're doing.

[MikeVaz]

Yeah. It just how it looks from external perspective. I do realize we don't know or see many reasons and details.
I just not sure you need to start another framework or a big project while many other project require help like MWC is kind of a mess right now. So it could be just a question where is the best place to apply your capacity right now if you have some.

[peter-mueller]

I also think solving MWC with idiomatic lit would show strengths and weaknesses of the slots pattern. Articles like https://lit.dev/docs/composition/component-composition/ for events are a real gem in my opinion (the polymer guides on multi-component structure/events have also been really good).

For example: how would a mwc-form od my-form element look like with lit using the MediatorElement from above article? In our usual enterprise applications there is not a single field in a form but up to 40 layed out in a css flex layout.

mwc-table could also be a real challenge to show of how well lit can be used: A selectable table with action-buttons per row, sort events, styleable cells, custom cells, a event for pagination input, .... Are slots really helpful in the table scenario if i have 100 rows to display per page? (vue did something really weird with slotProps here, i don't even think this is possible in lit)

In our application we switched to solving more complex stuff like tables with a combination of class based abstract code (just JS/TS) how the table should look like plus a as simple as can be table webcomponent that renders the abstract representation. https://vuetifyjs.com/en/components/data-tables/#usage solves everything with properties and slots and has become a huge mess (in my opinion).

I think the lit team should decide if the framework (i still think good components (could be mvc) + libs are more useful) shall be for small simple projects or for complex large/dynamic applications. I think a reasonable lit-developer is able to write his own router, but not able to solve more abstract stuff like large form live validation/reactivity/parsing inputs into structs.

[jorenbroekema]

To be fair, @open-wc/create could be expanded to generating more things, e.g. routing, state management and other templates that fill in the blanks currently with regards to creating applications with Lit.

There are definitely areas where there won't be overlap, e.g. SSR / SSG, I think a Lit "framework", maybe equivalent to something like Next.js but webcomponents-based, could be super nice. So far in my SSG projects (e.g. using Astro.build, Next.js, Nuxt.js), webcomponents support has been very minimal, even Astro's lit-renderer which is the best I encountered, doesn't work very well for more complex components. So even with declarative ShadowDOM and some server-side wizardry, I still end up 99% of the time just hydrating the component fully on the client with next to 0 work done on compile-time, there's lots of opportunity here I think.

[rbjarnason]

Yes, actually, our happy path to new web apps and upgrading old ones in recent years has been: npm init @open-wc

[jadjoubran]

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 ionViewEnter). It could be created as component first visible render lifecycle. What do you think?

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.

[daKmoR]

I think this would fit well within SSR... e.g. server render the component and you can then choose when to load/hydrate... for example

• becomes in view
• user clicks
• user hovers
• screen size smaller than x (e.g. load/hydrate burger menu only on mobile)
• ...

[jaydanurwin]

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 PWA

I 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/Observations

I'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

• My personal favorite static site framework right now
• Their partial hydration, islands architecture MPA approach feels like the best take on modern static sites (marketing, blogs, docs, etc.)
• Their templating language is excellent and modern.
• I personally don't care that much about using React, Vue, Lit, etc. together but their first party support of Lit is appreciated.
• Their two most lacking features would be SSR and automatic image optimization which are both in development.

11ty

• 11ty is great but doesn't include the right "batteries" in my experience.
• Having to setup a bundler is honestly annoying and it doesn't play well with Vite out of the box. Slinkity seems promising but it sounds like it's been difficult because Vite and Eleventy share some of the same responsibilities.
• The most frustrating part of 11ty for me was the templating languages felt a little old and cumbersome. Nunjucks was the best but VS code doesn't have a great Nunjucks plugin. (if there is one please send it to me)
• Development feels a bit slow because it's truthfully a 1-man project with a large community

Part 3 Wishlist/TL;DR (in order of importance)

• Handles both static sites, MPAs, and SPAs
• Powerful, modern, fast tooling
  • In my opinion Vite is the clear winner right now in building/bundling and for good reason. It's insanely fast and powerful and it's only going to get better since Astro, Vue, and Sveltekit are all using it.
• A great router that allows for nested routes (Maybe page/ based?)
• State management
• SSR
• Image optimization (lowest priority)

[daKmoR]

hey there 👋

I am working on a static site generator (next major version of rocket) that

• enables themes so you can get started quickly
• has a built-in menu system based on the file system which means you can create files and they will appear in html
• can render pages in isolation so it starts instantly and updates happen in ms
• remove most of the magic which means that you will know at a glance where the layout of a page is defined
• supports lit templates server and client-side so you can share them and hydrate any part as needed
• focuses on web components and es modules so we don't need to bring all these cjs/esm conversion complexities

It's hopefully a starting point for a next/nuxt like "framework" for web components 💪

it's now in an alpha working state and I would like to see how you would interact with in order to find out what is important to document, what are the most "wow" features and what is confusing or missing.

if you would be open for such a screen share session where I would be very interested in your honest feedback then please send me a DM on twitter @daKmoR or in the lit and friends slack

[bennypowers]

Would be good if the "lit framework" was a connection of independent, complimentary pieces, so other frameworks could adopt them piecemeal

[andrico1234]

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 <selectmenu> element recently made available in Chrome Canary.

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 😊

[zandaqo]

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.

[davidmaxwaterman]

I agree about the branding and promotion, and that applies in the world of job hunting too - 'Polymer' was bad enough, with searches turning up all sorts of chemistry jobs, but 'Lit' is significantly worse...nothing of much use comes up without additional guesses at things that might help - usually adding 'javascript' does the trick. On most job sites I have saved searches for "lit-html" javascript litelement javascript lit javascript lit.js javascript litjs javascript. Then there's the prospect of explaining Lit and Web Components to employment agents. It's significantly better to be able to add 'Google' to it, but it'd be excellent if we peons didn't have to struggle to even find ads for the few jobs that are out there. It is just one part of the whole 'branding and promotion' aspect.

I also agree with the examples, etc...I'd like it to be more opinionated.
Tooling is one of the biggest nightmares for me. Open-wc helps a lot, but even that isn't opinionated enough - I was recently asking about what to do about mocking when writing tests, and was told I could use whatever I liked...but I thought the whole point of open-wc was to be opinionated about these things, so we could rely on smart/clever people to make the right choice for us, and show us how with 'starter' examples and/or docs. In any case, I'm looking forward to the return of Polycasts - Litcasts?
Perhaps branding and promotion, and things like open-wc, are (like most things mentioned here) not in the remit of what is meant by an 'app framework'...but still.

[zandaqo]

I'm with you here, despite using lit-html since its first appearance, I only ever mentioned it in CV or stack descriptions as "vanilla js" or "web components". Having separate lit-html and LitElement added to confusion, hence, I'm just happy that they settled on a single name, not very searchable perhaps, but at least it's something.

And yes, tooling could be better. Especially I wouldn't mind vscode plugin getting under the Lit umbrella, but that's just a wish. One of the (big) reasons I stick to lit-html is that it is just JS, it doesn't require compilation or special tooling like JSX and the likes. Thus. it allows for a wider choice of simpler tools. Right now I'm using esbuild for all my compilation/bundling needs, and I even managed to port my Lit-based "framework" (compago) to Deno that comes with all the tooling significantly reducing the headache maintaining the toolchain.

[bencbradshaw]

Coming from an Angular background, there are a fair amount of additional packages I need for a full app.
A few things I would love to see included:

• Singletons and Dependency Injection, something similar to services in Angular, where I can access an instance of a service from any component, share data, etc. Currently using a homegrown solution with "services" set on the window.
• SCSS/CSS file separation (currently using lit-scss-loader)
• A start on a bundle config file. My rollup or webpack config is constantly growing and getting a little unmanageable.
• A router. Vaadin web component router is working well enough for now.
• Better rxjs observable support. similar to Angular async pipe with auto subscribe/unsubscribe, maybe a directive for this. e.g.

${observe(user$, (user) => html`<p>got ${user.name}</p>`)}

• potentially combine observe with .map or the repeat directive somehow.
• A number formatter. Angular has the the number pipe. Within Lit, I'm using numeral, which is pretty good, but built in Lit support could be nice.
• Date formatter. Angular has the date pipe. Within Lit, I'm using dayjs which is pretty good, but built in Lit support could be nice.

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.

[daKmoR]

for number and date formatting using what the browser offers by default should be good enough? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/format

or what are you missing?

[petecarapetyan]

Speed, over all other metrics

• TTI, pageload, etc: fastest possible time to interactive etc
• DX: fastest reasonable DX
• builds, deploys, etc
• a reputation for putting speed first. in all things

No Fuss Tooling, over perfection

• openly declared as no-fuss OVER perfection
• acceptable defaults are better than never committing to a setup
• accept the inevitable constant migrations such as webpack to rollup to esbuild
• not avoiding free tools just because of who owns or maintains them
• not avoiding controversial settings just because some prefer others

Open About Borrowed Metrics

• open about which other [frameworks, standards, whatever] we would like to be as good as at 'this one feature'
• open about the unfortunate side effects of selecting any one approach (router, MPA/SPA, etc)
• open about DX that is chosen because more familiar rather than more perfect.
• open that framework versions will always be changing towards what others are doing better at.

TL;DR

That 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.

[petecarapetyan]

Reviewing what is written above it is almost like saying - If it's not going to be the fastest performance and easiest to use, why bother creating yet another framework?

[andrewscofield]

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:

• First off LitKit ... my name idea for this thing 😂
• Simple state management. I actually like React's Context Provider/hooks, but maybe a standardized way of using custom js events and passing down props would be best?
• Filesystem routing with deep linking, I think this comes in play with my next thing on the list too
• SSR and ISR is a killer feature but for sure requires some server setup
• Help with building / hosting ... to me this is the real sticky factors of Next.js, so easy to push up to various providers or even host it yourself.
• Image optimization/loading help
• For certain apps, I really do appreciate the ability to have the built in serverless functions/api of NextJS. Specially with apps were I just need to be able to process a contact form, or do a couple Stripe calls.

[drk-mtr]

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.

1. I can run a single command to create a template project that I can then run in a watch mode, with hot reloading and SSR.
2. Can see how to add a new route, with components for some routes lazy loaded.
3. Can see how to share styles across components.
4. Can easily add a styling library such as tailwind or bootstrap.
5. Can see how to use styling features I've become accustomed with postcss or scss such as nesting - using both inline styles and separate stylesheet files.
6. Can see which aspects are rendered server side and which are hydrated client side.
7. Can see how to achieve parent/child component communication in a consistent way with terse syntax.
8. Can see how to create shared services e.g. for http calls (Justin did a talk that's on YouTube that was really useful for understanding this).
9. Access to documentation with either minimal assumed knowledge or full examples people can clone / play with in a REPL.
10. Excellent developer experience in terms of syntax support in IDEs. For me with Svelte, things tend to "just work" in vscode, whereas I don't get the correct autocompletion etc. using Lit. I appreciate this isn't Lit's fault, it's just because we're using literals instead of html/css, but I feel it slows me down.
11. I'd echo what others have said about PWA support i.e. knowing how to integrate a service worker into this setup, maybe using something like Workbox.
12. On the more "static site generator" side of things I'd like an easy way to generate content from markdown but I feel this is very out-of-scope for Lit.

I know it's early in the process but this is quite exciting news.

[spdowling]

8. Can see how to create shared services e.g. for http calls (Justin did a talk that's on YouTube that was really useful for understanding this).

A little off-topic, but which video was that? Do you remember the title or event?

[andrico1234]

https://www.youtube.com/watch?v=x9YDQUJx2uw

I'm assuming it's this one. It's a couple of years old but Justin discusses how to manage common application-level concerns using Lit. It's defo worth a watch

[spdowling]

https://www.youtube.com/watch?v=x9YDQUJx2uw

I'm assuming it's this one. It's a couple of years old but Justin discusses how to manage common application-level concerns using Lit. It's defo worth a watch

Thank you! Sounds good, will take a look

[Christian24]

I very much would love to see a @lit/forms package that makes form validation and state a breeze. For myself it feels like a very common pain point that in every project I have worked on I somewhat had to work around. So yes, something similar to Formik or Reactive Forms would be really nice.

[RadisLo]

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? 👀

[jaredcwhite]

@RadisLo A web component is a custom element. Every HTML element, custom or built-in, is part of an object graph (the DOM). In other words, every node in the DOM is an object which is a subclass of either HTMLElement directly (in the case of a custom element) or some other element class like HTMLParagraphElement, HTMLHeadingElement, etc. More documentation on this can be found at https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API.

Building web components out of functions/hooks/etc. can be enabled by third-party APIs for developers who prefer that paradigm, but all that would be doing under the hood is mapping those concepts to underlying objects and an OOP (Object-Oriented Programming) paradigm which is what DOM APIs use.

[bennypowers]

Examples of libraries that don't require the user to use the class keyword:

• hybrids
• haunted
• atomico
• somehooks

All of these are interoperable with lit