> animations are done in JS instead of smooth CSS transitions, drag and drop support is manually rewritten in JS... I mean... maybe in some legacy plugins that budget-shops drop into a Wordpress site without thinking. This stuff doesn't really happen anymore in real projects; there's not much point. > Whenever a feature gets added to standard HTML, web frameworks and "polyfills" keep implementing their own versions b…
> I think you misunderstand what polyfills are. [..] They get stripped out when possible. In no way are they "their own version" of the standard. That's the idea, but many projects never actually remove the polyfills once browsers catch up to a given standard. In theory they solve the problem, but in practice I'm still ending up downloading polyfills on Firefox and Chrome because Safari doesn't support a particular A…
Please learn how to properly quote things, all of your replies are showing up as part of what you quoted
> I think you misunderstand what polyfills are. [..] They get stripped out when possible. In no way are they "their own version" of the standard. That's the idea, but many projects never actually remove the polyfills once browsers catch up to a given standard. In theory they solve the problem, but in practice I'm still ending up downloading polyfills on Firefox and Chrome because Safari doesn't support a particular A…
Please learn how to properly quote things, all of your replies are showing up as part of what you quoted
Markdown's double newline never fails to trip me up. Sorry.
What's so embarrassing is that the HTML/CSS/Javascript mess does roughly the job Visual Basic did. But worse.
Is that true? If I download Visual Basic right now, could I make a sensible visual app vs React? I’m tempted to see if the truth is really out there.
No, Visual Basic 6 can only place controls by X/Y position, has no databinding and no VDOM or way to create controls other than placing them in the designer or manually creating and destroying them in code.
It's pretty terrible unless you want to make UIs with a fixed size and set of controls.
> To me, it represents a huge failure on the part of the developer community not to make publishing web components the standard The problem is that if you're writing a Vue app, and you import a web component that was written in Preact, you're now loading both Vue and Preact onto your page. That means your app will take twice as long to load. That is a huge downside to weigh against the inconvenience of having to find…
The webcomponents supporters seem hell bent on placing the blame somewhere other than webcomponents themselves. In the “truckload of dependencies” they fail to ask why those dependencies are really there, and in that required JS they fail to ask why its really needed. The webcomponents model isn’t just broken, its thoroughly broken, and I actually hold the opinion that it was never even a good idea, because it’s simp…
I mean, we're using web components to build large web apps at my workplace, and in my experience 95% of the dependencies of web components are... other web components. Which makes sense for anything more complex than a simple button. The whole point of web components is to create portable, reusable code that can be encapsulated within an HTML tag, so if I'm writing an app that needs buttons, inputs, date pickers, etc, obviously I'm going to import components for those things where native controls don't meet my needs. I don't understand why "it has dependencies" is a valid criticism.
(Disclaimer: author and editor of the modern custom elements spec here.) The specific "failed promise" that I see is largely this positioning of web components vs. frameworks. How web components was originally envisioned was as leaf-node or light-DOM-using components, of the sort HTML already has. For example, , , , etc. Web components was supposed to give you the tools to create your own components of this sort, suc…
Agree with this 100%. It's called Web Components since it's best used for writing individual components that be dropped into larger apps. I did a side project with LitElement recently, and just could not find the value add over React. That's when I realized that was never the intention anyways. I think the desire to make Web Components a React competitor also comes in part from the movement towards 100% static sites,…
My thoughts exactly. For some reason people tend to think that a web component should stand on its own from high level. But that's just not how HTML works. Something like should be seen as an anti-pattern IMO.
I see web components as a compositional approach for dealing with complexity.
Something else that is extremely powerful that people seem to forget is that you can add a src attribute to your web component that links to JSON data, or HTML fragements on a server. It can give you a lot of caching and concurrency opportunities, browser engines are extremely efficient dealing with this. For most people an src attribute feels really obvious for an img tag, but apparently less so in other contexts.
React is a nightmare when it comes to performance or energy efficiency... Downloading 500kb of js and processing this is just a nogo. The best advice to anyone interested in page speed, dont use this crap. https://youtu.be/plt-iH_47GE
My website which is entirely built in react (and uses Gatsby). Takes 4kb to full page render (1 file - static only - JavaScript disabled). That’s smaller than most any html+css especially if using some css library. Of course once that is loaded and if JavaScript is enabled, then it will start to load interactive stuff and prefetch (which is around 100kb - but I have a lot of interactive stuff - including a zork style…
Check the time to interactive. Rehydration creates a massive cpu increase.
> Can we fix this? Sure, by returning to basics. Let's assume that Web Component is a DOM element with a code associated with it + lifecycle events. Here is how Components are done in Sciter ( https://sciter.com ) 1. CSS has got `prototype` property: div.my-component { prototype: MyComponent url(script/components.js); } where MyComponent is the name of class in JS, url (optional) is an URL where this MyComponent can…
after doing a bit of vue I wanted this :)
The good thing about this mechanism is that you just need CSS in order to declare your components.
The script will run only if you have elements with matching selectors. So you may have component libraries. Browser will instantiate only used components.
Is that true? If I download Visual Basic right now, could I make a sensible visual app vs React? I’m tempted to see if the truth is really out there.
No, Visual Basic 6 can only place controls by X/Y position, has no databinding and no VDOM or way to create controls other than placing them in the designer or manually creating and destroying them in code. It's pretty terrible unless you want to make UIs with a fixed size and set of controls.
So then I’ll keep the question open. What is the dopest UI framework across any language with great paradigms, design language, developer experience, and of course, dope results?
Right now I’ll say the best iOS/android apps put web to shame. Is Flutter and SwiftUI where we should be looking? The question is specific to semi complex apps (typical crud), not websites.
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…
The web components under the hood would still need a way to program themselves in response to that data, so a templating language would need to be baked in along with data binding. Secondary languages are a bad idea, so hopefully this templating language would be something like jsx/ejs. The proposal really is to bake applications support in to the browser. That seems right to me. The browser is more and more an os, a…
Lit-HTML is a templating system that's baked into Lit-Element, which is basically the successor to the Polymer framework. It simply uses JS template strings, with a few little niceties in the binding syntax to allow for things like setting properties rather than attributes, adding/removing boolean attributes, and defining event handlers inline. It lacks two-way data binding, but we use "data" elements as a centralized data store. That store provides a master state object that's passed down to every component on the page - though frequently it's just a sub-tree of state that gets passed down. If a component receives some input and needs to update its state, it fires off an event with the updated value, which has a corresponding handler in the data element. That handler taps into a functional pipeline we've built to handle function composition, passes the information down the appropriate pipeline, and the master state is updated appropriately. At that point the data element fires a "state-changed" even that basically everything listens for, and whoever cares can then update their own little bit of state from the master store (typically one line of code).