girder / girder_web_components

Reusable Javascript and VueJS components for interacting with a Girder server.
https://gwc.girder.org
Apache License 2.0
16 stars 9 forks source link

Migrate templates from pug to html #161

Closed zachmullen closed 4 years ago

zachmullen commented 4 years ago

@subdavis @matthewma7

I am a major fan of pug over HTML, but if I'm the only reason we are using pug in this project, I'd be fine to change to using HTML, which would slightly lower the burden of adopting this library from source downstream. How do you guys like it?

jbeezley commented 4 years ago

I'm with you in disliking writing HTML tags, but I still don't like using Pug in Vue components for a few reasons:

  1. Because it is a templating language, it conflicts with Vue's own templating language. You can avoid using the templating features of Pug, but it can still be confusing to developers.
  2. The standard tooling for linting, editor support, etc generally doesn't work well (or at all).
  3. Downstream libraries not using Pug need to include extra webpack loaders.
matthewma7 commented 4 years ago

The pug did cause some issues regarding the new template syntax. I like the maximum compatibility of HTML in terms of dependency and ease of development when copy-pasting code snippets.

waxlamp commented 4 years ago

We're using pug in Metabolomics, mostly on the strength of @subdavis's convictions, and with proper editor support I don't mind it. But:

We're using HTML templates in Multinet and for some reason they just feel more solid to me there.

zachmullen commented 4 years ago

Thanks for the opinions everyone. I certainly will not stand in the way of removing pug from GWC. It shouldn't be a breaking change to do so.

subdavis commented 4 years ago

I also have a strong preference for pug for the sake of readability.

To respond to Jon's points:

  1. I have personally had no trouble distinguishing between the features of pug that I should and should not use, but I have seen that issue come up in other projects (metabulo).
  2. I agree that pug's linting is terrible. I haven't really felt any pain from this because I've internalized the syntax rules, but I can understand the barrier to entry that this may create.
  3. I would be more concerned about having to include pug-loader in downstreams were it not for the fact that several other loaders are needed as well. Elimination of pug and pug-loader from the dependency list wouldn't really impact the process of getting set up with with GWC.

I'm not convinced that GWC using pug provides any meaningful burden downstream, but I could be convinced to ditch it for the sake of our own developer experience as contributors to this library.

Also, a compiled es6 module library could solve a much larger amount of the adoption pain.

zachmullen commented 4 years ago

The biggest thing to me is the readability / adoptability from the "general public" as @waxlamp put it. My fear would be that using pug makes us weird / nonstandard from what most of the community would expect. I originally chose it because the Vue.js docs cite it as an official first-class citizen, but after some amount of experience with the tooling ecosystem, there are pain points with tools besides Vue itself as you've all mentioned. I've been writing Vue apps lately in both template languages, and they aren't terribly different in writability. I've felt from the beginning that the original value proposition of pug is diminished in the Vue environment, from a full-featured template language down to just a syntactic shorthand for HTML, and I think a lot of the reason we use it here is simply because we had good experience with it in Backbone Girder, an environment where it made a lot more sense.

Also, a compiled es6 module library could solve a much larger amount of the adoption pain.

Is there a straightforward path to this? Sounds like a great option.

waxlamp commented 4 years ago

I'm also curious about that library option.

subdavis commented 4 years ago

I'm backing away from Pug on other projects now.

Overall, I mostly care about Vetur support. I think we should probably begin thinking about converting components to html here. I'll change the name of this issue to indicate this consensus.