Giters

Polymer / polymer-starter-kit

A starting point for Polymer apps

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Ideas for a next-generation PSK

abdonrd opened this issue · comments

commented

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.

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?

commented
  • 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)
commented

@abdonrd

  1. I thought that the Polymer team was going with it's own html function instead of lit. lit may be objectively better (I don't know), but it would be best to stick with the base.

  2. I gather you mean beyond the included <app-route> solution? Gonna be hard to get them to not use internal projects.

  3. 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".

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

commented

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

commented

@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 with polymer 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).

commented

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

commented

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.

commented

Thanks to all of you who have given ideas! 👏

commented

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.

commented

@notwaldorf may I take a look at it? 🙂

commented

@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).

commented

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

commented

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.

commented

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.

commented

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 😁

commented

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.

commented

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.

commented

@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

commented

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 the npm 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

❤️

commented

Thanks for the info @notwaldorf! 👏

commented