161–170 of 200 posts
Earlier quoted context omitted.
Browsers do have built-in support for web components. You can extend HTMLElement in every current major browser.
And such extension is a major PITA to do. The API is atrocious, like most of the DOM API is.
I mean it’s decidedly not React to be clear, but I’m not sure what makes it atrocious
Web components to me represent the architecture I’d like to have. I think a good arch could be: 1. Build a rails/django type site, make everything work vanilla http+html etc. 2. Create standalone web components for the places you need some more interactivity, like type-ahead search box, “click to add” type thing, or a datatable So most of your performance stuff could be handled/improved on the server, focus on aggres…
Have you heard about Phoenix LiveView? Sounds like what you want. It's a Rails-like framework written in Elixir (piggyback-ing off 30 years of BEAM), and LiveView changes the game by allowing you to build rich front-end application from your backend. The way it works is that it serves you static HTML on initial load (yay SEO), and then it establishes a websocket connection to the server (very efficient thanks for BEA…
Here’s a demo I built for a small wrapper around Bulgaria CSS. Running on a tiny VPS: http://lacritch.xyz/
Now Elixir/BEAM is an excellent platform for this as the average and 99.9th percentile response times are really consistent. So your UI interactions don’t usually take 70ms with every Xth one taking 400 ms, which would be really annoying.
is there any reason you can't write a web component with a block, a block, and a bunch of html? the wedging everything into js is messy, to say the least. it seems the main benefit is being reusable and tightly scoped, but with randomized class names, you could tightly scope the aforementioned bundle as well. even better would be if html added 'for' attributes to and tags, like labels have, so you could target nodes…
I usually structure a component like the following. The nice thing about WebComponent is everything is scoped to the component and you can have pretty generic names for things except the defined component name ("component1" in this case).
/components/component1.js
import cu from "/util/comp-util.js";
import comp2 from "/components/component2.js";
import comp3 from "/components/component3.js";
(function() {
let template = `
@import "/styles/shared.css";
@import "/components/component1.css";
...
`;
class ComponentElement extends HTMLElement {
constructor() {
super();
cu.attachTemplate(this, templete); // the attachment boiler-plate code in util.
}
...
}
window.customElements.define("component1", ComponentElement);
}());It infuriates me that the concept of composable web pages using small templates/components is not baked into the html spec and supported by browsers. Every bit of code that we write in any programming language is made of composable bits which can be imported into other bits of code. But we cannot do anything similar with html. every time any attempt at having composable component based html is made, it gets mired dow…
I appreciate how Web Components are not opinionated meanwhile Component libraries are free to innovate and build on the Web Component foundation.
And the opinion has shifted from "this is the future" to "Web Component specs is aimed primarily at library authors, we don't expect people to author them by hand"
Earlier quoted context omitted.
And such extension is a major PITA to do. The API is atrocious, like most of the DOM API is.
How is it atrocious exactly? I mean it’s decidedly not React to be clear, but I’m not sure what makes it atrocious
And that's just two attributes.
Earlier quoted context omitted.
And such extension is a major PITA to do. The API is atrocious, like most of the DOM API is.
What's your suggestion for a better API? You can't just say "React" though, you have to show how it actually integrates with the DOM that we have. "Throw away the DOM we have" isn't a realistic option either.
How is React different from any of the libs and frameworks you are supposed to use for WebComponents? [1]
As for the API. How about a declarative API lime the one Polymer uses? [2]
[1] https://twitter.com/dmitriid/status/987771666846699520?s=20
[2] https://twitter.com/dmitriid/status/865518972380237825?s=20
I would highly encourage people to give it a shot. It's just going back to basics and working with class-based inheritance. It will take you a day to write out the basic functions you will need for 95% of your components, and you'll be left with a tiny library that not only solves your needs, but you know inherently.
If you're curious, lines 1-26 are all you need to easily bind an html block, a style block, and to do event/attribute binding via @/? statements: https://github.com/jjcm/soci-frontend/blob/master/components... . The rest of the file are just shared helper functions.
I love the simplicity of StencilJS. Not sure why it's adoption is so low but those guys have put a lot of work. Much better than what Google is doing with Lit Element.
'cuz Facebook spent a bazillion dollars to push the developer community towards React? They are really good at––how should I say this––controlling the 'community direction and sentiments'. Even countries for that matter.
It would be great to include metrics on: 1. size of framework javascript required to load first 2. tooling to compile. For example, the Vue.js works without tooling, but the React w/Class requires command line tools to build before the site is ready. That's a HUGE difference, IMHO.
co-author here. 1. The bundle size barcharts shows the component size (in light blue) and the framwwork size (darrk blue) 2. The Bundle Analysis chapter contains a description of the build tooling use for each component. Vue can be used without build tooling if you choose to use the Vue lib with the compiler included but we use the pre-compiled way for max performance and smaller Vue runtime (without compiler).
I'm not into web development at all so this sounds very new to me, but aren't components in general meant to be self-contained so that they can be reused as "building blocks" for larger applications (or pages, i guess)? Doesn't using a framework in this case mean that you also have to at least bundle that framework with the component? What happens if you want 10 components that each use a different framework? Or some…
Sums up "state of the art" web we're using right now = absolute mess, bail out if you can, save yourself, stay sane
https://jsfiddle.net/4qkpLw3c/
ghee, that was hard????