Ideas for a next-generation PSK
abdonrd opened this issue · comments
This is not official, just a few possible ideas for a next-generation PSK. I also think we should keep in mind that the PSK could scale to a "non-starter kit" in some simple way.
- polymer-lit
- A router solution
- Routes views with authentication
- State management: Redux?
- Update metadata when the page changes for SEO
- Announce when the page changes for accessibility
- Skeleton screens to make the application feel faster
- Animations
- Service Workers: Workbox
- Web Components polyfills only for Custom Elements & Shadow DOM
- CSS Shadow Parts?
- Live Reload in development process
- Multiple builds & PRPL server
- Bundler app: Rollup?
- HTML:
- Minify: html-minifier?
- CSS:
- Prefixes: Autoprefixer
- Minify: cssnano?
- JS:
- Compile: Babel
- Minify: babel-preset-minify
- TypeScript? I think I would only offer it optionally
- 100 Lighthouse score by default.
I don't know to what extent we could abstract some of these ideas in the Polymer Tools.
In the future, how would you like to be able to make applications based on Web Components?
- out of the box with 100/100 lighthouse score
- multiple themes for PSK (material, etc)
- webpack support?
- auto generate config file for firebase hosting
- auto generate http/2 server push manifest for firebase hosting config
- auto run lighthouse test when running
polymer build
- add new page/view directly from the
polymer-cli
? (+ auto update the my-app.js and polymer.json)
-
I thought that the Polymer team was going with it's own
html
function instead oflit
.lit
may be objectively better (I don't know), but it would be best to stick with the base. -
I gather you mean beyond the included
<app-route>
solution? Gonna be hard to get them to not use internal projects. -
Redux is it's own multi-headed hydra. Perhaps a few blog posts or updated videos would be good. It might be a bit of overkill to add into a "starter kit".
-
It looks like they are pushing hard into Typescript. It would make sense to add it to PSK
@limhenry A push manifest is already generated with the polymer build
command (via the cli and polymer-build
projects. You can also serve out any of those builds with something like polymer serve build/es6-bundled
. It's quite convenient. The Lighthouse idea might be a good suggestion for the polymer-build
project that the PSK uses.
@abdonrd great minds think alike! We're working on the next generation of the psk, and it has a lot of the bullets you've called out! We haven't made it public yet, because we were waiting on the code base settling a bit (we've literally been making changes every week and it's pretty annoying if you're a downstream user), as well as the polymer build
story to get a little bit better, but I think we're in a good place, and should be able to make it public for feedback soon!
These are great bullets and ideas though! We can't promise we'll get to all of them, but we'll certainly try.
@abdonrd, I would like to keep an eye on the tests. Currently I'm making tests for Polymer 1.X (latest versions) components inside an application and I would like to share some comments:
polymer test
always throws me an error related I think with the Chrome driver (only browsing the tests via browser you could see the results). This happened to me a few months ago, and recently with different laptops so I decided to back again calling WCT directly.- If you want to use
web-component-tester
via npm, you one extra flag:wct -l chrome --npm
. I think the last flag is not allowed withpolymer test
. - Related with Sinon and WCT.
sinonjs
is unupdated.- Before
polymer test
you could obtain coverages with Istambul plugin without separate your JavaScript code from your HTML code in your component.
To summaryze, I would like updated examples of using the test environment in the PSK (better with the support with npm).
Mind asking one simple question? What do you mean by next generation
? Do you mean the new PSK that uses Polymer 3 only?
Other than that, I'd suggest making the PSK to be more PWA focused like providing the necessary tools for building PWAs. I heard that folks like TypeScript and Redux. I think recipes are good and we should bring that back (do we still have that?)
I will appreciate in PSK to start using Workbox, make SEO improvements, and live reload in development process.
In my opinion PSK should keep the minimun necesary to start a PWA, with the minimum dependencies. Things like Firebase or Redux sounds good, but it agregates an unnecesary complexity to some projects.
To expand PSK, it will be a good idea to provide some mechanism, like plugins, to aggregate modules customizing PSK. Ie, if one developer prefer a PSK with Firebase, could make his own plugin an share it with the community.
Thanks to all of you who have given ideas! 👏
From @motss:
Mind asking one simple question? What do you mean by
next generation
? Do you mean the new PSK that uses Polymer 3 only?
I refer to a project started from scratch, trying to take advantage of new technologies / APIs.
@notwaldorf may I take a look at it? 🙂
@abdonrd not yet. There's a bunch of things still in flux, and I'm worried open sourcing it too early will send the wrong message. For example: bundling doesn't work yet, which means dynamic imports aren't polyfilled, which means the template only works on the latest chrome/safari, so it's bad as a starter kit, etc. All of these can be explained in the Readme, but since people tend to not read the docs, before we know it everyone is tweeting how the new psk doesn't even run on FF. We'll make this public as soon as we can run it on more than one browser (and it doesn't take a full paragraph to explain why you shouldn't be using it right now).
Polymer team, please do not move into typescript (your brother angular, now use typescript) we hate typescript 😂
i use polymer because i hate new angular, they use typescript... 🤣🤣
My opinion: why we need to learn new language (typescript) but the M$ typescript compiler / interpreter later convert it back to javascript to run it? 🤣 Why not we just type it in javascript? 😂😂
This is fantastic @notwaldorf . I was really hoping you'd come up with something like that.
I also think that Redux would be an overkill; and I also really hope that Typescript never becomes any kind of "default" in the Polymer world -- I think it should embrace ES6 really.
I understand it is important to have a minimalist boilerplate to teach the basics of using Polymer, and the starter kit serves this purpose very well. Polymer has always been easy-to-start, opinionated client-side technology, and as such is very enticing for younger developers.
To get better traction and serve the needs of these people even better, however, I think it would be good to have more ready-made boilerplate for real-world-scenarios.
Of course there is prpl-server-node already, but new developers come to Polymer seeking free quick-to-go solutions for their needs, and many of them just don't have any server-side background yet. That's why I think having two starter-kits could be the way to go, one of which would have best practices for Firebase Cloud Functions integrated.
Now I suppose Polymer wants to keep itself separate and at a certain distance, but folks are always looking for a one-stop-shop for their needs, they focus on one environment of their choosing and look how far they are going with that. There are surely many people who start out with Polymer and just love its low-barrier approach, but then feel like they are not really getting any further, and in the end choose a full-blown framework or maybe something like the Predix web-app-starter to hit the ground running.
But with a Polymer-FirebaseCF combo, they would see how they can reach a second level in the game quickly, without having to maintain any server at all for quite some time.
Just my two cents, but I think TypeScript fits really well for P3, and I'd argue for Web Animations inclusion in core, or at least for basic transitions in PSK. That is all 😁
Hi,
I think Typescript would be the final push for people to use Vue rather than Polymer.
Having ts files to describe and define the API, so that IDEs etc. work well, is a great idea. However, not everybody wants their code littered with type annotations. I definitely don't.
TBH, I kind of like TypeScript. Would like to see everything Polymer written in TypeScript and it's our choice to use JavaScript or TypeScript to build our Polymer apps. What I'm saying is that we should make the best of both worlds.
@abdonrd Great work on put all this list together !!!
@notwaldorf only a comment about the phrase "too early will send the wrong message" ,I think the opposite, if you share the plans/roadmap discussions or thoughts with the community in a very clear way, I believe that probably you will have more feedback and ideas; most of the people that use your tools probably are working on something similar to solve their own issues.
I believe sharing will benefit all involved... last year before polymer summit I saw very bad comments about future of Polymer(nothing new was happening ... repo pulse was very low).. and BOOOOOM a bunch of good news on Polymer Summit... Please keep us informed even if the plan is not very strong or are just loud thoughts!!!! let us vote/feedback or only be aware.... and we will be very happy and motivated.
Thanks for all your effort on Using the Platform
Hiya!
We've just made public the 0.8 version of the pwa-starter-kit
, which is our next version of the polymer-starter-kit
: https://github.com/Polymer/pwa-starter-kit
First, thank you so much for all the feedback and the discussion on this issue. It was much appreciated, and we considered a lot of it when we added some of the features to the new kit. I just wanted to take a moment and explain why some of the things you mentioned maybe weren't included, and some of our decisions:
- as you can see in the sample apps section of the wiki, we chose to bake some of the advanced patterns (like authentication, a11y announcers) into separate apps, rather than the template itself. A very heavy template is a bad starting point, since you have to delete a bunch of stuff that you don't need, so we wanted this to be more of a pick-from-a-bunch-of-shelves approach
- we chose Redux for state management because it's a popular and well documented approach, which means you can apply knowledge from other places. If Redux is really not your thing, we also have an identically looking different template that just uses a classic one-directional data flow.
- we didn't go down the TypeScript route yet because introducing a separate language makes the project a bit less accessible to beginners. This isn't to say that in the future we can't add a template that uses TypeScrypt! This project is meant to grow and evolve, so we might revisit this based on the feedback we receive
- We've looked into running
lighthouse
as part of thenpm run test
and oh boy: it really doesn't scale well. Your dev server that lighthouse would run on prolly doesn't have things like https forwarding, any certificates, etc, so the scores we were getting in dev were really bad (and like, unrelated to the actual scores you were getting in production). We'll look more into this in the future, but it wasn't looking good.
Hope this explanation helped! I'm going to close this issue and redirect all your questions to pwa-starter-kit
❤️
Thanks for the info @notwaldorf! 👏