WebComponents Will Outlive Your JavaScript Framework | Prime Reacts
Vložit
- čas přidán 11. 11. 2023
- Recorded live on twitch, GET IN
/ theprimeagen
Reviewed article: jakelazaroff.com/words/web-co...
By: Jake Lazaroff | / jlazaroff
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts - Věda a technologie
Good thing about Lit is that it’s dependency free. It’s a js class that you use as a base class for you web component, that gives you performant templates, performant styles as a static class field and takes all the boilerplate you need to write for vanilla WC out of the picture. It’s mostly about developer experience and even if it’s no longer maintained you do not really need to update it, its pain is under the hood. There is no better tech to build design systems than WC.
My usages of Web Components and HTMX are incredible.
My server is maybe great with the superpower of HTMX but sometimes I need to validate complex form. And those form are added at any moment by HTMX.
It's here Web Components save me cause I can create some custom Form Controller components to manage those boring things.
This save me for the need to import React and need to manage two life cycle at once and also it make me profit of Web Standard ❤
All the ways to build something in react part cracked me up. Thanks neighbor! This article and your comments are living rent free in my mind right now.
Totally agree about the "template strings development" not being great.
I'm currently writing a components library using Web Components and have external HTML and CSS files next to the JS file.
The HTML file has the markup and a `link` element, both inside a `template` element.
The CSS is just that, CSS.
The JS has the logic, state, etc... and actually imports the HTML with a function I wrote, it then sets the `href` attribute on the link to the aforementioned CSS file [`import.meta.url.replace(".js", ".css")`]
Adding JSDoc into the mix and I have a nice dev flow with no build at all.
I'd love to setup a Markdown live interpreter for the blog posts but I have to see regarding performance as it's a core selling point of my current business.
I’m basically doing this right now (JSDoc + WC) with my project svelte-retag which allows you to make better web components with your Svelte components. It’s not very big, it’s still fairly easy to read and there is effectively no build step. Best of all, if you’ve got it linked in project (like I often do for development), it’s a bit easier to modify it in-situ since it’s not compiled. Not that it’s much harder to do more, it’s just anything you can do to make it easier is always a huge plus.
Yeah I mean I would love to use more standard web apis and not rely on frameworks when it comes to HTML, but for the types of apps I build these days these standards just don't cut it yet for me personally. Web components are the future of web development, but I think they are not the present.
I do really agree that aligning with the platform as much as possible is usually the better option long term. I personally didn't jump on the css in js hype train and used mostly vanilla CSS (plus some SCSS) and got by just fine without too much issues. Now that css in js is considered a bad choice, I'm not really affected by it at all.
I learned React when class components were the norm. I then learned functional paradigm and helped migrating some code into it. Then I learned that hooks are the devil and now people explain to me how metaframeworks with backend and frontend code mixed together are the future. Every step on the way I was told that the previous solution was bad and the new one is good, because nobody was able to describe the problem in other way that "old bad, new good, here is 10 reasons for each". A proper breakdown always required at least a few months of experimentation, anything before that was just marketing speak.
Which is why I am somewhat scared while watching "why hooks and bad and Signals are so great!" videos: I feel like I watch yet another round of marketing for yet another solution, that will be replaced in a year or two, because it has some problems nobody is gonna tell you about now. This is the current state of the web people: a lot of hype for shiny new tools followed by realization that no, they were not that great in the first place, we just decided not to talk about the downsides.
That perception is exactly how it is. You are not being paranoid. I switched back to embedded systems after trying web dev f-ckfest of never ending frameworks marketing sillyness.
Feels like you are now less on the junior side aka the hype side than the senior side. I totally agree
Your comment perfectly describes the state of FrontEnd development. We're still navigating towards stability in this sub-field, as such, solutions are varied for addressing problems.
FrontEnd annoys me in the sense that we need more and better standards, since the standards are considered incomplete, solutions are trying to propose de-facto ways of doing things.
I'm still a FullStack Engineer, but these days I'm just trying to steer clear of this hype trends of the FrontEnd world and seriously considering just going all-in on BackEnd.
18:00 you will still need to use typescript (the ide extension) to have an static analisis of your js docs and detect type errors. And, on frondend apps, jsdocs will still need to be strip from your code to reduce the bundle size, so you still need to build with a tool like webpack, just like typescript types (if you disable some compilation magic of ts, it will literally just strip the types of your code.
There is a new proposal that you allow us to use typescript types and javascript engine will threat it like a comment (as a type anotation).
What would be awesome if those JSDoc were interpreted by browser, and you could debug website at runtime, 'from prod'
Also, if you're distributing a library that exports types, you need to run `tsc` over your JS+JSdoc files to generate `d.ts` files as consumers cannot understand JSDoc from within node_modules. So you will still need a build step.
I'm on the JSDoc team though, it's really convenient and, imo, hope to see it developed further in future
>And, on frondend apps, jsdocs will still need to be strip from your code to reduce the bundle size
Why, though? What's the actual, real-world benefit on modern devices? You save maybe a kilobyte or so of what the client-side treats as effectively whitespace. Sure, it's _nice_ to make sure everything is neatly minified and reduced to the minimum possible size load, but the vast majority of sites simply don't need it - they don't (or shouldn't) need enough code for it to be a reasonable concern. Near zero parsing impact, zero processing impact, and negligible transfer size impact.
@@foxoninetails_ "But the vast majority of sites simply don't need it" This is DEFINITELY not true. If you decide to go vanilla (most JS frameworks use build tools by default, the only coherent way of not wanting a build tool is going vanilla), even for trivial apps, you will use a lot of other dependencies on which a lot of them are shared by many libs (no build means replicate the exact same code in a lot of different place). Even if we ignore those repeated codes, there is still a problem, using gzip on a single file saves a lot more space than parting this same file into multiple files and using gzip in each of them. There is more, a single HTTP request to get a js file is faster than multiple HTTP requests to different files. Removing comments is just a small detail of the minification process. Interestingly enough, source code still suffers from a lack of compilation, we should never underestimate the size of the source code, I worked on an application that is not that big and it has 10 MB of source code. I am sure that most nontrivial apps will have relevant sizes on the source code size. And source code (at least well-written one) tends to be broken into many different files, so gzip will not be efficient (it could even make some files size bigger in some cases);
That being said, js apps without minification should not be used on production, even on small apps. It will save on the order of many megabytes, and downloading things from the internet is the thing that impacts the most on the performance of front-end apps (In most cases, network calls and bundle size are the ONLY things that impact performance on the js app).
there’s workarounds
Most things I do with JavaScript do not need strict type checks, JSDoc is sufficient. The problem I have lies more with my colleagues who sometimes ignore warnings and errors (even disabling them in the IDE) and then wonder why things break eventually. Most of the warnings are completely harmless, the code will work. The problem is that if you keep ignoring them, you end up becoming blind to the cases where it is actually important. The same goes for ignoring tests that sometimes fail and other times don't. At some point that will bite you in the ass and that will fail in production. Even if it's just a poorly written test, rewrite the test or whatever it's testing, because you have a bug somewhere.
So this is a mentality issue, not a language issue. You'll have just as much type safety with JSDoc and LSPs as you do in TypeScript. You just don't have a transpiler/compiler to do the job for you.
There's actually a proposal for type hint annotations for JS itself. When that happens, the idea of a no-build JS system is going to really start to get more popular.
@@echobucket That's nice, although I unfortunately suspect it will be rejected. One of the things I dislike about JSDoc is that anonymous functions are a massive pain to add documentation to, so having TS-like type hinting would be a massive improvement for them. For everything else I think it's honestly fine as is.
As time goes on, I realized that warnings are useless because they tend to be ignored as you mentioned. If something is an issue, it should be an error and not a warning. If it's not an issue, then it's not really important.
But of course if you don't have a system to enforce these errors, then errors can be pointless as well since they can just be ignored.
@@rand0mtv660 I consider a warning essentially the same as an error, something I've found is quite uncommon. My mindset is basically "a warning is a future error" and I know just how bad things are when you need to fix loads of things at once because suddenly you're forced to upgrade version and those deprecation warnings are no longer warnings. They are full-blown errors and there is no drop in replacement. So if people have kept using the deprecated feature because "that's what we've always used and it still works" instead of the new way of doing things, your work will now be hell.
@@CottidaeSEA oh yeah deprecation warnings suck if they get ignored and warnings tend to be ignored by most people because they still allow you to continue your work and things "will just work". That's why I generally tend to prefer errors, but of course it would be horrible if frameworks wouldn't give you a time period to adjust and just kick you down immediately. Once you say to someone "oh yeah, you can ignore this particular warning", it's like their brain goes "oh yeah, I can safely ignore warnings in general".
When it comes to warnings that I can control in code such as ESLint config stuff for example, I tend to bump things into errors if it's agreed that it's something that should be enforced or just turn off the rule if it's determined that it's not important. This is one place where I learned people ignore warnings 99% of the time so I started bumping these to errors because I noticed warnings were pointless.
I’ve also decided to lean in and use web components more and see where it goes. I do love JSX and hope to see web components mature to something even more usable
Web components is a cool idea, I work with it since the very first versions, I even added support to old Opera before they migrated to V8.
There are issues.
- Components might race for the name, only one will win.
- Also means that different versions can’t be used in the same document. Only one will take the name.
- SSR is very limited as the shadow DOM is only generated dynamically, so the browser can’t render the component until it download the logic of that component.
I love web components. Takes a little time to setup but you end up being able to build out a nice library of solutions that work so well once you spend the time. Nice getting that total fine control. Not as quick to get started with, but its a great way to get really comfy with css and and js.
One of the best article reviews ever. Thanks 🙏🏽
my favorite is just extending htmlelements with a few extra methods like optional oncreate, ondelete, onresize, onrender, etc and some property listeners then you get everything you want. Then you can import html and css files with esbuild etc as text so you don't lose any templating.
Writing your own html`` function too is not hard like what lit does. My only gripe with lit is it tries to be like react when I think the more vanilla syntax is easier to understand.
I agree about TS and JSdoc. I will say typescript allows for more types, I am think about enums. With JSdoc, you only annotate as much as you want, and you get type checking and documentation.
i've actually written an app with webcomponents, what you could do is you could put your style into a style variable, and differen't portions of markup into variables and then render the variables that way, its not a perfect solution but it would make things more manageable
I wrote an article on webcomponents recently, the standard sucks: Shadow DOM was a huge mistake, it isolates the outside from the inside (as it should, and as view encapsulation does in any CSS-in-JS framework or the new CSS modules), but it also isolates the inside from the outside which goes against the way the web has worked since forever. The web component author has to go out of their way to make them possible to style, and often they don't expose enough.
You could just ignore shadow DOM and use regular light DOM, but then templates cannot use slots for no explainable reason (you can emulate them with a data-slot attribute and a MutationObserver, so it's a restriction for the sake of the standard being garbage).
The way it should have worked, is that a template was the way to define the component, you should have been able to name them and instantiate them directly from HTML with no JS involved, and they should have scoped their CSS and script like any framework does without any need for a shadow DOM. Closest we can get to that is compiling Svelte to web components I guess, but I wish there was something much more lightweight, like a one-file python script that compiles a .thtml file into a dependency-less .js file that defines a custom element (maybe I'll make it at some point).
Hydration and SSR are also a nightmare with web components.
Non Shadow DOM web components can use slots. Things like CSS @layers and @scope make it easier to control the cascade. I never had issues with styles being applied where I didn't want them anyways. If people spent half the amount of time learning and keeping up with CSS as they do JS things would be better.
The problem with jsdocs is that you need to be a lot more disciplined, if you update the signature of a function, you have to make sure to update the jsdocs.
In typescript, that has to happen as you change the function.
While technically true, I'd assume that, if your tooling (or CI pipeline) is using the type hints, it'll warn you when the declared types and actual usage conflict. While that that may not be entirely foolproof (particularly if said fool is the sort who ignores warning), I'd expect it to catch a significant fraction of "oops, forgot to update that too".
> sequence diagram - the only useful UML diagram of all time
Funny because I also feel the same way. It is really useful in explaining how various parts of the system communicate with each other. Especially to the new devs when onboarding them to the project
I can’t wait until type hinting is a thing in JavaScript, I am sure it will become a part of the language and it is just about how long. This will take awhile until browser support will be high enough to allow usage, but just look at the JavaScript we use now that is incompatible with the original language specification. They can add an additional keyword to the strict string to require everything have a type hint.
is go templ actually good? I thought it was a lot slower to iterate on the actual component than html/template. With html/template I see literally instant updates in my browser as I edit the html template. with templ, I need to have a watcher that runs the templ generate command and then another watcher (air) to rebuild and execute that go code... How is this better than raw dogging html/template and using something like browser-sync to inject those html changes into the browser for hot reloading?
I can wrap my web comps for React, or Angular, and still just maintain a single code base. Our users and even own product teams use different frameworks. We’re not going to dictate those decisions. Web comps have some issues (ssr, hydration), but still give some great flexibility.
Ya the only thing makes me hesitant is the SSR and hydration.
@@ivan.jeremic 🤦♂️ Why use SSR if most of your components are to be rendered on the client? And hydration is just not rendering to HTML. It bind reactivity as well. I've had issues with this exactly.
@@justafreak15able can you explain why web comps + ssr is problematic? I've no knowledge about that scenario. can't the serve simply serve the web comps as well? isn't it html/css/js after all?
Using WebSDKs directly will probably always be a recent idea for at least some amount of projects. Its nice that it sorta allows you to do templates without involving JS. Still need a little though
10:20 there's an vscode extension were it treat template literals as html and autocompletions works like it normally work
Managing anything beyond simple state with web components is like the inner ring of hell
Have you used Lit?
You have context, async task, many directives, reactive properties, reactive controllers that are compostable, there are signals now for ez "global" reactive vars if you don't want to use other libs like rxjs...
@@danko95bgd Isn't the point of web components to use web standards and now you mention that a framework like Lit would be a good choice. Doesn't that go against the idea of web components? It just proves that sometimes web standards aren't enough for modern web development.
@@rand0mtv660 maybe if you think literally like that, but if any framework should exist, it should be a very lightweight wrapper around native features that exist (wc). It just uses decorators so you don't have to manually type the getters and setters for properties, query elements or define components.
It helps a little bit that you can use that html func instead of manually defining the template, and selecting it and appending to the Dom and so on.
It doesn't do much at all, just improves dx in a declarative way.
Ideally it shouldn't exist but again, people want to do things differently, wc are low level API at the end, just like how xhr was before fetch.
@@danko95bgd Hmm yeah it would be better if WCs already had a better DX out of the box, but unfortunately they don't. I mean I don't mind using a framework, but people saying "oh you should use web components" kinda omit the part where using them without at least a small wrapper on top sucks so you still have to reach for a 3rd party solution.
Will see in few years from now if web components will be more enticing to me, but for now I'm still not on board with them.
Examples wanted.
Your History of React is awesome!!!
I hate a lot of design deductions if with components, like document createElement("my-component").constructor == HTMLElement // true, even thou you create them from a class.
Which means they loose all the methods.
They also can only extend the base element class, so if you want a special list or anything you'll have to make silly things like :host { display:contents; }.
Also encapsulating the styles on it's own shadow from has caused more headaches when i needed to apply some styles on vendor libraries
About JSDoc, I've actually started just using it and it's surprisingly good, there's a bit of noise compared to ts, but it's so much easier without whole build step on simpler things.
I just made a webcomponent for rendering my error messages because of the Shadow DOM not having effect on the actual layout of the page. It was the perfect solution.
The bad thing with using lots of webcomponents is that in a sense they can be misused as globals, because you can place them anywhere in the page. There are webcomponents that just do ajax calls and show nothing. It's easy to understand, but it's hard to grasp where everything comes from if a lot of things happen.
A large system with webcomponents is best as a design system.
I like both htmx and web components.
I would love some ide tools around htmx to make DX even better. At least when working with it in Go.
I’m just learning web development and this video made me want to learn web components before react. Bad idea or good idea?
That "one year later" rant 😂🤣💀 was spot on
Coming back to this video after playing around with generating Web Components that use Leptos on the client for reactive rendering. What's been amazing is that once it compiles, i just have some JS (and/or WASM since you can transpile WASM to JS) that makws the component available, and it doesnt interfere with any other JS I might already have.
Being able to use web components with other libraries is the killer feature in my opinion. I have no idea how to get React, Vue, etc. to play nice together. But with Shadow DOM and web components, you can have TS React components mixed with server side Leptos, etc. and it just works.
My dream is a really good Rust library for making WASM based web components. All the power and DX of Rust with complete compatibility with the outside world.
I've seen an entire login modal done in WebComponents and shadow DOM. Password manager cannot fill it in for me.
Ima give WebComponents a try ty for video
14:28 mindsweeper paint. sweet. sweet.
It's been a while since I've looked at it, but can't Svelte target web components as the build result?
Prime, will you switch from Neovim to JetBrains RustRover IDE?
someone should make a counter for him, for the times he asks the chat to type a number the counter should count how many times the same message has appeared in the past minute or so.
Isn't that just a bad polling system?
@@NibbleMeTwice Yeah it would be a poling system. How would it be bad, you must expand on that.
@@titastotas1416 Polling is already a thing on Twitch. Granted, with your system, there's no need to activate a poll, but I don't think it's inconvenient enough to necessitate what you're suggesting. No offense.
twitch already has polls, he just doesn't use it for quick questions lol
what would be good tech stack wit hhtmx now? Htmx + Go + ???
Love your take on react
Hi,
I don't know if I'll agree to this or not, I have two library on web component first using Stencil and another using Lit on top on metrical Web component.
But in thing Web component lost in the race.
0:29 - "All you have to do is do nothing and your job is complete!" LMFAO!
11:00 just use a tagged template string like html`` and configure your editor to run the LSP inside it
19:20 JS will likely have a type system like PHP in a while - sooo... probably best to just do whatever you like until then?
(I like vanilla JS more; I don't know if anyone really prefers TS or if its just a required evil)
Man, this video has given me a lot to think about.
For my A level project I am making libraries for various things. Since I’m a new developer I don’t know ‘industry standards’ or anything of the sorts so it is all ‘original’ code.
I’m interested to see how it holds up when I know better
You'll think it's absolute garbage in 6 months, but that's fine, happens to all of us. The problem with industry standards is that there are so many standards. Of the projects I've seen, they either don't follow any standard or they follow multiple conflicting standards. So I don't think you need to worry.
Some things I'd recommend learning how to do in general is writing code that is easy to replace. Don't use too much internal state in functions either, it can be very difficult to debug as you'll have a harder time tracking down what the state was at the time of running. Sometimes these things are more or less unavoidable, but at that point you should at least be aware of the tradeoffs.
As above, pretty much everyone else's code and code you've written more than 6 months ago is ass!
@@CottidaeSEA "You'll think it's absolute garbage in 6 months" ~ a form of the artists curse
@@CottidaeSEA That's true. When programming i did consider having less internal state functions but i concluded that they could bring up the source code, disregarding the fact i was looking through the lens of the programmer and not through fresh eyes. Since it is for my coursework im not sure if ill go back and tweak it but if i do, and i know better, ill try to consider the tradeoffs more thoroughly.
Thanks
@@ike__ With library code it can be a bit tricky, since you want to expose the bare minimum to the user, but the functions you use internally are a different story. One of the main benefits is that you can use what are called pure functions, given the same inputs you should always get the same result. This means you are also not allowed to modify reference values. You'll find good examples if you want them.
Good luck with your coding adventure!
At my work we have been going ham on just writing .d.ts files and importing the types with JSDoc. I still am not sold that is better than just typescript for a project but it's better than what we had
My notes and (abandoned but would love to still post) blog posts are written in markdown for this exact reason. Markdown is so portable. Hard winz
I just never understood how you can have reactivity with htmx. If you want to have elements that react to each other on the client... How do you do that with htmx? Wouldn't you have to bundle some kind of other reactive library into the script tag of the specific page? I genuinely don't know.
you can do as you said, but you can also have javascript, htmx emits lots of events. here is a simple script that takes in a form and disables a button during the duration of a request
/**
using js doc so i don't even have a build step
* @param {HTMLFormElement} form
*/
function disableSubmit(form) {
/** @type HTMLButtonElement */
const button = form.querySelector("button[type=submit]");
if (!button) {
throw new Error("form without button");
}
// ensure at load time that button is not disabled
button.removeAttribute("disabled");
form.addEventListener("htmx:beforeRequest", function() {
button.toggleAttribute("disabled", true);
})
form.addEventListener("htmx:beforeSwap", function() {
button.toggleAttribute("disabled", true);
})
}
@@ThePrimeTimeagen Okay ChatPrimeT to get around silly number input quirks I need all values for a text input to be validated as a number to then go into an unseen (not hidden or disabled) number input to use that number inputs validation for it's attributes like max min and step. The text-input should react to any step values from the number input.
Yesssssss - thumbs up for htmx, please! Watch some videos about it and avoid some more years of frustration by switching to this great JS library.
21:00
Imagine me just starting to learn web dev after leaving previous job, struggling a bit making my way through basic js, being kinda happy to launch into react to be "hireable" then going through docs and then this whole mess of debate and iteration and breakin changes in the previous 3 years and having to figure out what any of that means...
Im so shell shocked I moved to Angular
What breaking changes in React? Angular is probably the worst choice if breaking changes was and is your concern, btw.
The React monologue here is spot on 🤣
Web components are awesome! I actually use them in my day to day!
Yeah but how difficult is to setup bun or deno?! I'd say the build step is a non issue now.
how does he show/hide the url/title/tab bar on hover?
10:35 Putting html in JS strings is the absolute worse. LSP support aside, it’s no longer a hypertext markup language document when it’s inside a JS string. At least have it in a
jsdoc looks veeeeery alike phpdoc which i've heavily used on php 7+ projects, can't see any "awfulness" of it, very helpful for lsp and basic static analysis and no-build is another huuuge win imo
It's nice to have only one place to specify type, unlike python doc strings that include type, but then if you change the type on the variable the type in the docstring will be incorrect.
@@Lestibournes just do stuff with care, don't wait for something do your work and think for you - its always helpful to keep your brain in shape
and yes, if you change variable and forget about "comment" lsp's static analyzer will give you a tip
The original actors in Stargate were Kurt Russell and James Spader.
There's some people like me that listen to you on the background, we need a "sarcasm" seal of sorts for messges like the one about react on the backend
I don’t quite see the benefit of js doc just to get around the build step. If there is something worth running on the backend or natively, why not use go or rust? Why give someone something that requires node or bun? Doesn’t even python have optional typing nowadays?
Couldn’t template string DX be solved with better LSP support?
Looking forward to that Elixir on the channel. 🤓
whats the link to this article?
Stargate is awesome, and the characters were kernel Jack O'Neill and Dr. Daniel Jackson.
jsdoc doesn't support generics well, which has always been a blocker for me. That's also the reason I ignored golang for so long
It's funny I don't like coding in typescript for the same reason like its a nightmare to upgrade, takes forever to build and I dont feel it benefits me a lot. I do love JSDoc and i use it verywhere just for the code completion alone its already awesome. that being said, I'm not focused on full app engineering, my stuff is more like building specific widgets and visualizations to be embedded just like he shows in the article. One cool experiment I did do with Web components was bringing some of the design system for the company I work for from Adobe XD to web components. I'm loving not having to install a gajillion packages and other devs can use the components with little overhead and setup. I kind of agree with the article, coding like this feels like its more future proof imo.
PSA: If you like Svelte, like web components, but dislike React style and/or Lit, you can actually very easily compile Svelte components to web components . It's not the best documented thing in the world but once you have it up and running it's actually pretty handy
Update now that I've listened to the whole thing.. this method does get a brief shout-out in the article, but there are concerns about maintainability. I DO get not wanting to be tied to an ecosystem and being concerned that framework updates will break your web components, but I do think this issue is largely mitigated by virtue of Svelte outputting actual web components instead that are just JavaScript, HTML, and CSS with no dependency on Svelte itself. That and Svelte is mostly just JavaScript with templating and reactivity, so there is no radically different syntaxes or functions (as of 4.x).
I think best combination of typescript and jsdoc is having all types in .ts file and importing them in jsdoc. If you have any better ideas, please let me know!
Such a good idea... Thank you. Can't believe I didn't think of that.
Just use typescript is better idea. There's no a single reason to use jsdoc instead except of build step that you probably already have
also writing jsdoc feels so ugly compared to ts
I don't think shadow dom is really that necessary. There are accessibility issues and with things like CSS @layers and @scope or architecting your CSS, using the cascade, and lean on custom properties web components without shadow works more than fine.
Additionally when you add style tags to your web component it is repeated every place it is used. Which gets a bit bloated. Of course you can use something like css adoptedStylesheets to reduce repeated styles. But it seems a bit weird.
Too many people don't put the effort to learn CSS as well as they know JS.
That is where you get things like tailwind.
Epic.
20:56 - 22:42
I enjoyed using stencil
26:00 this works in reverse for Angular right now.
I didnt agree that pixel component is not code, and its framework is not about code too, I guess its about static vs static editable vs dynamic editable vs dynamic ediable static loaded vs dynamic editable dynamic loaded. depends on how content must be handled. syntax evolves anyway but words as syntax can be used in many ways as always. don't believe web will stop people from using exotic syntax cause at some point content == code even if it is to explain how it works.
I'm doing a project using only webcomponents... it's very clean and organized... no lib / framework. fast, readable... it's great!
Fun fact, chrome dev tools are webcomponents
Web components looks pretty simple actually... it's just a nice mixture of all the basic html/css/javascript we're used to (unless you've only used to library's). overall I find it easier when there is less magic going on...
Is managing your own state really that difficult? I dunno... you can build it as slim as you like for your needs. I don't really see what's so impressive about state managers anyway.... they're mostly useful for the mere fact they become "standards".
This is such a good and factual take. I was nutting my pants
Everything you do with htmx I prefer doing with Web components
Who is paying for that server components load?
Is it possible that this is an ask for a heavier cloud operations?
yes)
Amen! Amen!
Everyone is trying to imitate PHP now.
13:05 the author doesn’t seem to have enough experience with web components bc sharing styles or not sharing styles is totally up to the developer
I wish HTMLX worked with hx attributes in the shadow dom.
I've used jQuery, AngularJS, Vue, Angular, and React at my various jobs. Web Components is the only one that actually felt good to walk away from when it was done.
100% AGREE
Random comment, but just wanted to say your vids got me wanting to learn to code again. That, and figure out neovim. Brand new to linux, and haven't used a command line since the days I upgraded from windows 3.11 to win95...and gotta say, not sure what you mean when you poke fun of people that can't figure out how to quit neovim 🤣took me about 45 seconds to figure out :q, then to my AMAZEMENT found :Tutor about another minute later...wish I didn't have to go to sleep now 😠
People have to come together to save the day! Htmx is the the light of hope it should not be put down
Dude I’ve been doing Django since 2012, code I wrote then could still run with latest Django without much changes.
Web Components are dope. Freed me from React and its build steps.
You're not using something to build the Web Components?
would want Theos reaction :))
Elixir is amazing confirmed
In any sane world they should be the standard, using browser API's ..but.. we don't live in sane world.
Shopify make really good use of them (as you will never be writing TS for Frontend) and experience has been positive if you can deal with all the JS class styling writing styles.
Why would you not be writing typescript for frontend with Shopify?
elixir gang hold, we're getting there
Gonna hard disagree on the template strings. I reach for them any time I want madlib-style access to a static text file that isn't supposed to update outside the function I'm writing. Want to update a config file to include a new module you added? Loop through the existing modules and plug their configs into a template string, rewrite the file. Works like a charm.
The spit at "AKA React" 😆😆😆
You don't need JavaScript on the backend for Declarative Web Components served via the server. It's all template literals (until we get import assertion support for HTML).
is that also true for React Server Components? (Never used them) Or do they require a javascript runtime on the server?
IntelliJ can handle template strings as if you are writing normal code. Well, in the Java world anyway. Should work for JS.
He's 💯 correct on JSDoc. The more I use TypeScript, the more I hate it.
Crazy how betting on stability pays off. D: