> > https://example.com/path/to/img.jpg " alt="..." /> > I thought the standard way to do it is: https://example.com/path/to/img.jpg " alt="..." />
There’s almost no standard way to do anything when it comes to html style.
HTML Web Components
161–170 of 247 posts
Re: HTML Web Components
#162Earlier quoted context omitted.
> 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…
I think the future of webdev is a framework-like system that can be added gradually to basic HTML, rather than one which requires that you totally replace it with JSX, etc. from the start. Webcomponents are a huge step towards a time when we can add state managers and things like that without bringing in a monolith all at once. Some projects require 1% of a framework, others require 98%, but the majority are in a ran…
All the things that "monoliths"[1] bring web components ate not bringing, and won't bring in any conceivable future.
[1] There are very few monoliths among the frameworks these days, and apart from React and Angular [2] most aim for rather small bundle sizes
[2] Out if the blue Angular just released version 17 with all the goodies you'd expect from a framework in 2023
Re: HTML Web Components
#163Earlier quoted context omitted.
> The article argues between the difference of a JavaScript Web component and a HTML Web component, you describing the former, thus the need for JavaScript. The article goes on to add a good little bit of JS to make everything work they way they want. They still need JS to accomplish what they want. If you turn off JS things will break in that example. > Personally I think the main problem here is client side renderi…
Sure, the article is incomplete in the sense that it doesn't fully commit to the idea of HTML Web component as opposed to JavaScript Web components, but it is the correct way of thinking about this. There will almost always be a roundtrip, either to fetch HTML segments or to ask for more JSON data, except for the rare cases you already have everything, because that is the nature of client-server paradigm. By putting…
> Sure, the article is incomplete in the sense that it doesn't fully commit to the idea of HTML Web component
What is that, exactly?
> By putting all your templates in the backend you can render them as a whole document or in parts in one go and send them wherever,
All frameworks can do that. Web Components cannot.
> If you always start with a JavaScript function, and all that comes with that, you need a programmer to be able to create the web, but with HTML (and CSS) first you can have other categories of people do that, like designers.
Web components quite literally don't work without Javascript. And they need Javascript to be able to do trivial things like form participation.
Re: HTML Web Components
#164Earlier quoted context omitted.
The core of the web only need basic HTML with closing tags (and properly shaped singleton element/tags) with the basic grammar (from the specs), utf8 encoded, no script. It is enough for a bazillion of online services, that without requiring a beyond insanely complex and massive web engine from Big Tech. basic HTML forms can do wonders. Of course, you can have a full blown Big Tech web app, but don't forget to have a…
If you are only doing web as documents with links. As soon as you use any Forms and error back-and-forth you have to either patch over the web stardards, or annoy your users with sub-par functionality.
I don't agree, what you call "back-and-forth" is not negative, actually it appears more like "consistency" to me... and in the end, more than enough for a bazillions of online services and that at a ridicule technical cost compared to the one from Big Tech (not to mention all the corollary issues).
Of course, it is a trade-off, bells-and-whistles from rich GUIs are sexy, but the technical cost of such bells-and-whistles in a web context is grostesquely and absurdely unbalanced compared to what can be achieved with simple and consistent noscript/basic (x)html portals for any pertinent goal of a bazillions of online services.
Re: HTML Web Components
#165For those who read to the end... Angular still uses XMLHttpRequest and not fetch, IIRC. Funny, huh.
As of 2023, fetch() still doesn't support upload progress.
Re: HTML Web Components
#166Earlier quoted context omitted.
Web components are only useful IMO in the case of a large enterprise which wants to systematically and consistently style a large number of applications written by different divisions in different frameworks in different languages targeting different clients.
I'd add longevity. If your company works for a product where you'll have to maintain the code you write now for the next decades, you don't want to deal with then-ancient abstractions. The JavaScript of a well-written web component should be as valid now as it will be in 10 years, as you're just using the platform.
This year I pulled class-based React component into a greenfield React project. Worked without a hitch, even though its a 10-year difference between approaches.
Meanwhile, "use the platform":
- all form components written before form participation landed in browsers are broken
- all web components written before cross-root ARIA (not even a spec yet) are potentially broken due to shadow DOM
- ... you may continue this list at your own leisure ...
Re: HTML Web Components
#167I 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.
Re: HTML Web Components
#168Earlier 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 kind of audit are you talking about?
Re: HTML Web Components
#169I've recently just started playing with Web Components without a build environment. Meaning, no npm, no bun, no webpack, etc, and no dependencies; in typescript. Intellij can autocompile down to js and the browser view injects a small onchange handler for live updates when developing. So far no problems. The only thing holding web components back seems to be HTML Modules; being able to link to a .html file instead of…
HTML Modules have been deprecated and removed in favor of JS-only imports.
And no, it's not the only thing holding web components back
Re: HTML Web Components
#170Earlier quoted context omitted.
Sure, the article is incomplete in the sense that it doesn't fully commit to the idea of HTML Web component as opposed to JavaScript Web components, but it is the correct way of thinking about this. There will almost always be a roundtrip, either to fetch HTML segments or to ask for more JSON data, except for the rare cases you already have everything, because that is the nature of client-server paradigm. By putting…
> Sure, the article is incomplete in the sense that it doesn't fully commit to the idea of HTML Web component What is that, exactly? > By putting all your templates in the backend you can render them as a whole document or in parts in one go and send them wherever, All frameworks can do that. Web Components cannot. > If you always start with a JavaScript function, and all that comes with that, you need a programmer t…
> What is that, exactly?
Component rendered before client side JavaScript.
> Web components quite literally don't work without Javascript.
That is why I'm not using them.