This is what I do with my web-component framework:
The website itself also built with web component
HTML Web Components
171–180 of 247 posts
Re: HTML Web Components
#172Earlier quoted context omitted.
Staying closer to web standards is always best for maintainability and portability. I personally like custom direct standards but that doesn't always work in a team for some reason today. There will always be less dependencies in a straight standards solution, that makes for better maintainability and opsec. I also think it is better for web developers to know standards over just abstractions, it makes for better dev…
> Staying closer to web standards is always best for maintainability and portability. I understand that argument, but Lit isn't a web standard, and it's an esoteric choice compared to Vue, which works great with custom elements.
Yeah agreed, that is why I said "if you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice"
Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now.
I still prefer direct and custom with less dependencies but Lit is somewhat trying to communicate web standards while other current frameworks really want lock-in to the platform rather than caring about making sure devs understand the standards.
Re: HTML Web Components
#173Earlier quoted context omitted.
Staying closer to web standards is always best for maintainability and portability. I personally like custom direct standards but that doesn't always work in a team for some reason today. There will always be less dependencies in a straight standards solution, that makes for better maintainability and opsec. I also think it is better for web developers to know standards over just abstractions, it makes for better dev…
> Staying closer to web standards is always best for maintainability and portability. That's what you get if you chose literally anything but web components. Because web components are really bad at using and playing nice with web standards: https://threadreaderapp.com/thread/1717580502280867847 They need dozens of new web standards to fix their self-inflicted wounds and to work with the browser in a way that everyon…
I mostly agree but Web Components is a web standards as is templates/custom elements now.
The others like React/Vue/Svelte etc are all going more for platform/framework lock-in over making sure people are doing augmentation of standards.
Those frameworks have incentive to lock you in while standards are lock-in at a lower level.
Other standards I like playing with direct like html/css/canvas/WebGL/storage/svg/video/audio/geo/etc and ones that are newer are WebRTC/WebGL/WebGPU/WebAssembly etc. All of these are and will be abstracted by some frameworks and people will know less about them and more about the platforms on top if they aren't regularly going direct. I think people that know about the standards more low level make for better framework developers an developers that use frameworks even.
I like platforms that make web standards the core aim not the platform lock in.
Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now.
Lit is somewhat Angular like since Google make both.
Re: HTML Web Components
#174Earlier quoted context omitted.
Most people using react aren't building SPAs. Vue/React can be used the same way as jquery, which is to add enhanced UI functionality that server-side HTML views simply can't offer. The best example is a multi-select box, or a searchable select box with autocomplete (what W3 calls the combobox pattern https://www.w3.org/WAI/ARIA/apg/patterns/combobox/ ) which in jquery was usually via https://select2.org/ For example…
The element with a text input field is an HTML native typeahead, which works great with SSR or you could wire up the datalist client side with an XHR creating the datalist. You maybe don't get full control over the rendering style of it, but it's a still significantly more usable than the Angular Material autocompletes.
On paper, is great but as implemented (or not) in all browsers, it has issues. This post walks through an example of using the element but also summarizes issues (as of June 2023): Under-Engineered Comboboxen?
https://adrianroselli.com/2023/06/under-engineered-comboboxe...
Re: HTML Web Components
#175I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Does it just have styles in it? If so why wouldn't I just use css classes? I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable? Vue/React/Angular don't seem like they are trying to "…
> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app.
Building an entire web app out of Javascript has been an incredibly dumb idea, and some ecosystems are trying to return us to the roots: most of the heavy lifting is done server-side, and JS is a sprinkle of interactivity on top, like the golden age of jQuery.
Before you bite my head off telling me about apps that necessarily have to be SPAs, how many apps are people using React for when a modern server-side framework would do (i.e. Phoenix Live View)?
Re: HTML Web Components
#176Earlier quoted context omitted.
As a counterpoint: I consult for government agencies that have all separately decided to standardise on Angular. They mostly publish static content: alerts, updates, reports, etc… At most they might have a single page somewhere for submitting a payment or a simple form. But because of this JS framework by default policy all their apps end up with extra complexity, extra build steps, and an awful amount of dependency…
Kind of obvious why, any of the react based frameworks all fail an audit. Doesn't even make sense to me why anybody uses them. You cant audit static sites (ones thing I don't like about having traditional linked libraries).
What makes certain libraries auditable? I doubt react was compliant when first came out.
Why can’t you audit a static site? Seems very straight forward. We already audit static sites for accessibility (503 compliance).
Any resources you can point to? Seems like it would be a worthy effort to make other tools compliant.
Definitely something I want to learn about.
Re: HTML Web Components
#177Earlier quoted context omitted.
>Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends True >which feels like a massive step backwards and completely the wrong choice for building a web app. Why? I mean, I'd agree if by 'web-app' you mean something like google-sheets. But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting framewor…
> But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top" We absolutely don't have shared language for these things and we aren't always talking about the same things. The thing is there are just vanishingly few places wh…
React is not a framework.
It is a fancy HTML templating library first and foremost and you should use it when you need HTML templates, which means you that can use as little or as much of it as you want.
I’ve built mostly static pages with React loaded and embedded into parts of the page. The webpages would function without JavaScript enabled.
Re: HTML Web Components
#178Earlier quoted context omitted.
As a counterpoint: I consult for government agencies that have all separately decided to standardise on Angular. They mostly publish static content: alerts, updates, reports, etc… At most they might have a single page somewhere for submitting a payment or a simple form. But because of this JS framework by default policy all their apps end up with extra complexity, extra build steps, and an awful amount of dependency…
That's understandable. Though I actually can see some logic in it. It's got to be way easier to hire Angular developers than it is to hire someone who wants to eek out the maximum performance with this lightest-weight approach (and do it in a maintainable/understandable way). I'll never say Vue/React/Angular are "light" and I'll fully admit we give up some performance for DX (and UX) but it's a tradeoff I think is wo…
> It's got to be way easier to hire Angular developers than it is to hire someone who wants to eek out the maximum performance with this lightest-weight approach.
I disagree, at least around here. Frontend developers with react/angular experience are a hot commodity and really hard to hire, yet just about anyone from any tech tech can knock out html and some minimal css.
Re: HTML Web Components
#179I think I've finally seen the light when it comes to Web Components: https://github.com/kennyfrc/cami.js > No Build Steps, No Client-Side Router, No JSX, No Shadow DOM. We want you to build an MPA, with mainly HTML/CSS, and return HTML responses instead of JSON. Then add interactivity as needed. > Declarative templates with lit-html. Supports event handling, attribute binding, composability, caching, and expressions.
Replace JSX with a custom non-standard DSL, call it a win.
It's a win because it means no build step. You could also say that JSX is a custom, non-standard DSL.
Re: HTML Web Components
#180React Component is a function. HTML web component is NOT a function. You don't just compare those things, they work and compose differently. I would rather combine them: A html web component renderer for React.
So when react components were classes they were comparable, but now that react components are functions they are not?
A class is a closure ?