161–170 of 235 posts
Web Components were crafted for jQuery world. $("#datepicker").datepicker() Custom elements resolves problem we had with XHR HTML response, it instantiates automatically. Problem solved. Widgets were popular and easily broken by CSS, solved by Shadow DOM.
Shadow DOM does not solve any real life problem. sDOM is spherical horse in a vacuum, my pardon.
Web Components were crafted for jQuery world. $("#datepicker").datepicker() Custom elements resolves problem we had with XHR HTML response, it instantiates automatically. Problem solved. Widgets were popular and easily broken by CSS, solved by Shadow DOM.
Shadow DOM does not solve any real life problem. sDOM is spherical horse in a vacuum, my pardon.
Any sample that can be done by sDOM and is not feasible without it and associated machinery?
Earlier quoted context omitted.
> I strongly believe the abhorrent overuse of React and other such libraries on the web is the sole reason our computers have gotten hundreds of times faster but the web is only slightly as quick. If browsers provided data binding and reactivity out of the box, frameworks and applications would be much faster and lighter.
Web browsers provide many features out of the box but frameworks rarely use them. Web components are one thing; HTML templates are another. Streaming video is being decoded by Javascript even though every browser supports H.264, input elements such as calendar controls are rewritten, animations are done in JS instead of smooth CSS transitions, drag and drop support is manually rewritten in JS... Whenever a feature ge…
Popular browsers such as Firefox and Safari don't have native date controls: https://caniuse.com/input-datetime
This post is needlessly snarky, but I don't disagree with the basic premise. Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that i…
JavaFX bindings are a joy to work with and everything "just works". You have FXML for Mark up, you have controllers for logic, and you have the freedom to create your own beans or database classes or use Spring or whatever you want to do. JavaFX is arguably an external library, but since it is packaged with Java I would say it is closer to being part of the standard library (certainly more so than React is part of JS).
There needs to be a dead simple way to tie the properties of a Web component to a JSON object. That's all it would need for now. I could develop some great small-medium Web apps without a single line of external JS with that alone. No more event triggers followed by queries followed by DOM manipulation. I just want to update a JSON object, and have that immediately reflected on the UI, for both built in and custom components.
This post is needlessly snarky, but I don't disagree with the basic premise. Here's what killed web components: lack of native databinding on the web. That's the reason the standard is useless without JS. Any modular, dynamic, modern UI requires databinding, which means it's going to bring in a framework anyway, which means that self-contained widgets are all going to bring in their own frameworks, which means that i…
I agree! And this is something we plan to address in a future version of https://braid.news!
One problem with standardizing this now is that we don't have a standard for "data that changes." Braid is adding that to HTTP so that you can subscribe to a changing URL. Once that works, we just need a standard way to bind a UI widget to the URL.
Earlier quoted context omitted.
This is literally what a custom element is. Assuming your @event decorator is built upon the EventTarget interface: class MyComponent extends HTMLElement { // lifecycle event/method connectedCallback() {} // lifecycle event/method disconnectedCallback() {} @event("mousedown") onMouseDown(evt) { } @event("click", "button#submit") onSubmit(evt, button) { } @event("change", "input.name") onNameChange(evt, input) { } } T…
> @event decorator is built upon the EventTarget In Sciter it is not. @event there is not calling Element.addEventListener but declares event handlers as static table associated with class. Essentially components are attached to DOM elements by calling Object.setPrototypeOf(element, MyComponent) - no memory allocation is happening (modulo code in componentDidMount) - very fast and lightweight. Yet, in your sample, yo…
Earlier quoted context omitted.
I'm a strong proponent of separation of duties on the web (style and visuals in CSS, layout in HTML, anything interactive in JS). Enabling data binding in HTML would only serve to blur those lines. With some minimal JS, you can update each web component already. Is writing nameField.innerText = response.name really that difficult? What problem does it solve to make a standard for it? As for (de)serialization, JS has…
> anything interactive in JS Except this barrier has never existed. Every HTML input is interactive: text fields, checkboxes, radio buttons. They not only remember their value, but your cursor position within them and the segment of text you've highlighted. The browser knows how far each scrollable element is scrolled, which element is in focus as you tab through the page. Forms have validation state, and can be inte…
No it really shouldn't. Just look at JS. It's a complete mess. And HTML would get there in a short time if they were to adopt "anything that can be neatly siphoned". The problem is that data binding is actually quite complex. I have seen data binding done 10 different ways in different languages and they all had their flaws. It will be very difficult indeed to come up with such a standard that is actually being used universally.
If it is not, what sense does it make to add it to the standard? But for it to be used a lot, it would actually need to solve most problems in most businesses for the forseeable future.
Given the fact that the Web apparently still hasn't figured out quite how UI development is supposed to work (judging by the 1 new language feature, 10 new frameworks, 100 new libraries developed each day), it will be a very poor idea to start baking half baked stuff into a standard.
If there was a way to write JS within the component, I think that they could have taken off - just see how well components are in React, Vue et al. And to get that to happen, all you would need is the ability to refer to `this` within the component. Aside for that, treat the JS within the component as a module, ability to access global vars, but within scope. But instead, you are expected to put the relevant JS in th…
Earlier quoted context omitted.
I built lots of HTML form UIs in the early 2000s. They were garbage. Many modern web UIs are on par with native apps, so much so that folks are now using web technologies to build actual native apps. With 150 years of evolution (at current W3C standards pace) you might get an HTML spec that is capable of expressing the behavior that users expect from present-day applications. Until then we have React et al.
> Many modern web UIs are on par with native apps I strongly disagree. Form/ fields are one of the areas that a native app can slaughter HTML, even if using a WebView within an app. For example, just showing the correct keyboard layout is a nightmare, and heaven help you if you need to do something slightly custom. Another example: browsers do funky shit with scrolling and zooming on input focus. Try using the best H…
It would have helped a lot if JS had a working modules systems on the web. > What hope do those who can’t write JS have? Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”. JS has been in a dark & ugly spot, & WebComponents feeling janky & weird is…
caniuse statistics say that ES2015 module support has reached something like 92% of browsers: https://caniuse.com/es6-module
Maybe things will settle down and browsers will actually run the code that web developers are writing, but the way things are going I don’t see that ever happening. Likely we’ll end up coding in any language and downloading WASM.