Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "web components"
Please. Hear me out.
I've been doing frontend for six years already. I've been a junior dev, then in was all up to the CTO. I've worked for very small companies. Also, for the very large ones. Then, for huge enterprises. And also for startups. I've been developing for IE5.5, just for fun. I've done all kinds of stuff — accessibility, responsive design (with or without breakpoints), web components, workers, PWA, I've used frameworks from Backbone to React. My favourite language is CSS, and you probably know it. The bottom line is, you name it — I did it.
And, I want to say that Safari is a very good browser.
It's very fast. Especially on M1 Macs. Yes, it lacks customization and flexibility of Firefox, but general people, not developers, like to use it. Also, Safari is very important — Apple is a huge opposing force to Google when it comes to web standards. When Google pushes their BS like banning ad blockers, Apple never moves an inch. If we lose Safari, you'll notice.
As for the Safari-specific bugs situation, well… To me, Safari serves as a very good indicator: if your website breaks in Safari, chances are you used some hacks that are no good. Safari is a good litmus test I use to find the parts of my code that could've been better.
The only Safari-specific BUG I encountered was a blurry black segment in linear gradients that go from opaque to transparent. So, instead of linear-gradient(#f00, transparent), just do linear-gradient(#f00f, #f000).
This is the ONLY bug I encountered. Every single time my website broke in Safari other than that, was for some ugly hack I used.
You don't have to love it. I don't even use it, my browser of choice is Firefox. But, I'm grateful to Safari, just because it exists. Why? Well, if Safari ceases to exist, Google will just leave both W3C and WhatWG, and declare they'll be doing things their way from now on. Obey or die.
Firefox alone is just not big enough. But, together with Safari, they oppose Google's tyranny in web standards game.
Google will declare the victory and will turn the web into an authoritarian dictatorship. No ad blockers will be allowed. You won't be able to block Google's trackers. Google already owns the internet, well, almost, and this will be their final, devastating victory.
But Safari is the atlas that keeps the web from destruction.22
The brief history of Facebook open source:
- FB releases React under an oppressive licence that tells "woopsie, can't sue FB if you use React"
- a lot of money goes into making React popular to gain leverage from mass adoption
- VMware bans React in their company
- FB releases Flux to bring state management. It flops. Replaced by what some Russian student wrote in several evenings (Redux)
- Preact is released. It's faster than React, and it has MIT licence. Vue beats React in GitHub stars.
- Under mass pressure, FB changes React's licence to MIT. Initial plan to gain leverage fails spectacularly.
- FB releases Flow Types. It flops. Replaced by TypeScript.
- FB releases their own app market for React Native. It flops.
- FB releases Relay. It flops. Replaced by Apollo.
- FB tries to push React.Suspense for the whole JS landscape to obey and comply to how it works. Community says "Fuck You".
- FB releases react-native-web. It flops.
- Web Components are out in all browsers, adopted as a standard. React doesn't support them.
- Google releases Lit, a virtual DOM framework on top of Web Components to fuck with React. It's a massive success.
- React 18 is out. Still no Web Components support.
- (you are here)16
Salesforce lightning web components have such bullshit limitations that they claim is because of security but it's just because it's overengineered garbage.
Want to use web components? Nope.
Want to pass in a value to a function in a click listener expression? Nope.
Want to use scss? Nope, compile it to css yourself.
Want to use the fucking document object? Guess what it's overridden except for very specific third party frameworks.
Who in the fuck thought it was a good idea to override the document object? Your app isn't more secure, literally the entire internet uses the document object and it still becomes available in runtime anyway so what the fuck??
LWC is the biggest garbage I've ever seen, you know a framework's a big red flag when there are developers solely for the framework.
There is a new security release coming out that apparently removes some of these nuances (understatement) so there might be some light at the end of the tunnel.4
Sharing a first look at a prototype Web Components library I am working on for "fun"
TL;DR left side is pivot (grouped) table, right side is declarative code for it (Everything except the custom formatting is done declaratively, but has the option to be imperative as well).
TL;DR (Too long, did read):
I'm challenging myself to be creative with the cool new things that browsers offer us. Lani so far has a focus on extreme extensibility, abstraction from dependencies, and optional declarative style.
It's also going to be a micro CSS framework, but that's taking the back-seat.
I wanted to highlight my design here with this table, and the code that is written to produce this result.
First, you can see that the <lani-table> element is reading template, data, and layout information from its child elements. Besides the custom highlighting code (Yellow background in the "Tags" column, and green gradient in the "Score" column), everything can be done without opening even a single script tag.
The <lani-data-source> element is rather special. It's an abstraction of any data source, and you, as a developer can add custom data sources and hook up the handlers to your whim (the element itself uses the "type" attribute to choose a handler. In this case, the handler is "download" which simply sends a fetch request to the server once and downloads the result to memory).
Templates are stored in an html file, not string literals (Which I think really fucks the code) and loaded async, then cached into an object (so that the network tab doesn't get crowded, even if we can count on the HTTP cache). This also has the benefit of allowing me to parse the HTML templates once and then caching the parsed result in memory, so templates are never re-parsed from string no matter how many custom elements are created.
Everything is "compiled" into a single, minified .js file that you include on your page.
I know it's nothing extraordinary, but for something that doesn't need to be compiled, transpiled, packaged, shipped, and kissed goodnight, I think it's a really nice design and I hope to continue work on it and improve it over time1
u know, as a devop/prod/backend engineer, i thought i would be exempt, but world wide web of "one more thing a dev should do" won't let me have it :(