I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?".<p>I've discovered that when you start getting really cynical about the actual need for a web application - <i>especially</i> in B2B SaaS - you may become surprised at how far you can take the business without touching a browser.<p>A vast majority of the hours I've spent building web sites & applications has been devoted to administrative-style UI/UX wherein we are ultimately giving the admin a way to mutate fields in a database somewhere such that the application behaves to the customer's expectations. In many situations, it is clearly 100x faster/easier/less bullshit to send the business a template of the configuration (Excel files) and then load+merge their results directly into the same SQL tables.<p>The web provides one type of UI/UX. It isn't the only way for users to interact with your product or business. Email and flat files are far more flexible than any web solution.
I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code.<p>My team and I built <a href="https://restofworld.org" rel="nofollow">https://restofworld.org</a> without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience.<p>We might adopt a framework eventually (I do appreciate how their opinionated structure can cut down on endless debates), but for now, plain JavaScript serves us really well.
I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.
Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely.<p>I run sites that serve hundreds of millions per day and we pour a ton of resources into these projects. We're trapped in a framework (react) prison of our own creation. All failures are those of complexly. Highly coupled state machines with hacked, weaved, minified, compiled, transpiled, shmanzpiled etc. into unreadable goop in production. Yes I know source maps, but only when needed, and they are yet another layer of complexity that can break - and they do. How I long for the good old days before frameworks.<p>Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.
I am not sold on web-components yet. Especially now with @scoped and import{type:css}, I think there's still a lot of merit to rendering an element statically, shipping it, and updating it dynamically via modern JS. I'm not sold on <i>how</i> people typically do that, and I think we should keep trying to innovate <i>outside of</i> the typical frameworks like React/Svelte, but I definitely don't see <i>any part</i> of web-components being useful to <i>any</i> type of site I run (and I run several disparate types).
Once you're building custom components in JS files, aren't you basically writing your own microframework?<p>Sure you don't need bundlers and compilers (such as TS to JS), but at some point you might need async updates on `fetch()` of components that also share state with other components. At this point you're into framework territory, whether using your own or someone else's.<p>Producing a framework with those features that still fits in a single small size JS file would be great, especially if it can do component updates to shared state (without updating the DOM each turn, hence shadow DOM).
This entire endless conversation would be made SO much easier if we spent some time thinking about the difference between web APP and web SITE. They get conflated all the time and although there is of course a Venn diagram where there’s a bit of crossover, they’re basically entirely distinct beasts that require entirely different technical approaches.
This is a great resource.<p>IMHO everyone building for the web should understand how it works and know how to use the foundational web stack, leveraging the web platform per se. Then, by all means use a build system and your preferred frameworks at your discretion, remaining aware of tradeoffs.<p>For my part, one of the things I like best about Remix (/React-router v7+) is its explicit philosophical alignment with leveraging web standards and doing more by doing less (e.g. mutate server data using... the HTML form tag).<p>I also highly recommend <a href="https://every-layout.dev" rel="nofollow">https://every-layout.dev</a> which showcases eye-opening, mind-expanding techniques for implementing performant, accessible, flexible web layouts using only browser-native CSS.<p>Context: I've been professionally involved with web development since 1998.
I know I am in the VAST minority, or perhaps the only one, but I cannot stand frameworks. Sure, there may be a lot of power in them, but there is also a lot of bloat and complexity. IMHO, this "power" can easily be achieved with libraries instead of an IOC framework. After you learn a, typically terse and confusing, framework language, you have to know that framework language along with the base language (Java, C#, JavaScript, Python, etc.) I feel like frameworks are only as popular as they are because product owners and managers like to tick-off the number of tools their developers use; makes them look important, knowledgeable, and efficient.
I don't find WebComponents a good replacement for what in other web frameworks are called components. For one thing they don't support complex values like Objects and Arrays as attributes. The amount of boilerplate you have to write is way too high, and you still don't have reactivity. I do vanilla-ish JS using signals[1]. Not everything the W3C releases should be canon, XHTML is a testament to that.<p>[1] <a href="https://wrnrlr.github.io/prelude/" rel="nofollow">https://wrnrlr.github.io/prelude/</a>
This guide assumes web components is a viable alternative for frameworks like React or Vue. That's a very superficial assumption. React and Vue render the UI as declarative function of state, with the help of components. That's why we use those frameworks. Web components don't solve the state management problem.
Seems like this is more for the hobbyists - building webpages for the love of the act. Frameworks are built to be standardized, enforce best practices via their design, and allow developers to 'hit the ground running', so to speak.<p>No web site is intrinsically valuable - the information and functionality it wraps is what holds its value. Developing the access to that information and function, enforcing correctness, and the timeliness of that development is what frameworks empower orgs to deliver at much lower cost in the present and future, vs. vanilla web dev.
I have some notes here at andrewmcwatters/custom-elements <a href="https://github.com/andrewmcwatters/custom-elements">https://github.com/andrewmcwatters/custom-elements</a>.<p>My business doesn't use React anymore, and I'm so happy I don't have to do pointless maintenance.<p>A side note, included in my repository: you update your element's innerHtml from the constructor, not from the connectedCallback. MDN and the web standards seem to be inconsistent on this, and elsewhere people write about it, too.<p>People talk a lot about data and binding, etc. I think it's weird, it's like people have forgotten how to just use setters. You can call a render() method from a setter, and it does the same thing WebKit et al do when you call an internal setter on an HTML element.<p>I don't see the value in these frameworks anymore.
I did a small project last week<i>. It's completely vanilla and works great. It's a web tool for writing long threads for Mastodon.<p>I kept on wondering while making it if I was doing it wrong without any framework. Because that's what everyone else seems to expect.<p></i> Splinter, splinter.almonit.club, if anyone cares.
Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pretty tedious in vanilla, though!
Note that you can make things even simpler than this: just use vanilla JS to compose HTML strings, and plug them into divs using innerHTML = "...". When your state changes due to user input, just rebuild the page using the new data.<p>I've been building many simple apps using this technique, it works fine. I'm sure there is some kind of performance hit; it's almost never an issue. I have never seen any browser compatibility issues.
Spend five minutes on webcomponents.org for a depressing ride. Broken links, broken demos, ghost town community and shuttered chat servers. Sponsored and abandoned by the Google Polymer team, or so it appears. Just sad.
Hum for me vanilla is html+css.
If you throw in javascript language, I do not see the 'vanilla' anymore :)<p>I ended up using hugo + isso (for commenting) and it works very well.
I moved to this setup after the wordpress drama, and even if I miss something, freedom has no price: <a href="https://gioorgi.com/2024/liberta-come-aria/" rel="nofollow">https://gioorgi.com/2024/liberta-come-aria/</a>
Great resource! I particularly like the fact that their web component section doesn't use the shadow DOM. It's really too bad custom elements got associated with shadow DOM, as they're so useful beyond the more niche usage cases of the shadow DOM.
> The most basic structuring technique is separating CSS into multiple files. We could add all those files in order as \<link> tags into the index.html but this quickly becomes unworkable if we have multiple HTML pages. Instead it is better to import them into the index.css (via @import)<p>You'll eventually need \<link> <i>anyway</i> for preloads, especially with web fonts, since that's the <i>only</i> way to prevent FOUC. Personally I lean on build steps to solve this. I don't like bundlers or frameworks, but I have grown accustomed to custom-building.
Can we just use links to go between pages, instead of toggling css display:none on custom elements to show different "pages"? You're replacing browser functionality with custom code. To get on par with browser default functionality, you need to implement a loading indicator, error handling, back/forward button handling, address bar updates, opening links in a new tab when someone middle clicked or ctrl clicked, new window when they shift clicked, etc.<p><a href="https://plainvanillaweb.com/pages/applications.html" rel="nofollow">https://plainvanillaweb.com/pages/applications.html</a> This example code does exactly one of those things: update the address bar by setting the fragment identifier. Middle clicking and back/forward buttons work because of that. Error handling (if it were to not just be static content but actually loading something from a server like a real website, which can fail) and loading indicators are not present<p>Re-implementing browser code in JavaScript is not using the "plain" or "vanilla" web functionality. You're making your own framework at that point
Personally have had great experience in high throughput, complex paas / saas webapps by rigourously only adding things when it was clearly needed.<p>Recommend you try to start with webcomponents + a well thought out design system -> move on from there and you're pretty sure to have a solid base from which you can always add react, lit, vue or whatever else cooks your noodle.<p>the other way around is near impossible
When it comes to reducing complexity—especially for Java developers—it’s worth checking out Vaadin.<p>It lets you build full web UIs without touching HTML, CSS, or JavaScript, entirely in Java. The UI logic runs on the server, meaning: no API design, no JSON mapping, no Redux — just a Java object model.<p>Vaadin follows a true full-stack approach, where frontend and backend live in a single codebase. Combined with Spring Boot or other JVM frameworks, this creates a cohesive Java application—no complex build pipelines, no split repos, and no friction between frontend/backend roles.<p>What I personally enjoy most is the smooth developer experience: you see your changes reflected in the browser instantly — no manual builds, reload fiddling, or sluggish toolchains - just java and a bit of maven. For many internal business apps, it feels just as “plain” as the old-school server-rendered apps—just with modern capabilities like Web Components and security by default.<p>(Full disclosure: I work at Vaadin, but I’m genuinely a fan of the approach because it saves developers a lot of headaches.)
I tried to build an app with web components but honestly, the DX is quite bad and I abandoned the shadow DOM for light dom until I abandoned the vanilla tech stack entirely and moved the project to React. It is just so much faster to develop in React in comparison. Also when stuff goes wrong with components they many times just fail silently with no errors given to the console.<p>You have such a great community with big, very well thought out libraries like Tanstack Query that is pretty nice to work with. I can have backend and front end code in the same repository in a simple way and reuse code.<p>I also have the project in Phoenix Liveview which is also a much nicer way of using components. The thing is I don't really know which tech stack is gonna win so I made a small prototype in both to see different advantages / disadvantages.<p>One thing is clear tho, pretty much everything is better than using vanilla components and it's really sad because I really do want to use vanilla components and I want them to be good.
Other than for learning purposes or very lean projects, you'll de-framework yourself just so that you have to spend extra time rebuilding it instead of focusing on the essence of your project
I support the general idea here but just because something is in a browser doesn't mean it's a good formalism.<p>Notably, Web Components. They're fantastic for <i>distributing</i> components - after all, a Web Component will work in every framework (even React, the IE of frameworks, finally added support), or even in vanilla HTML. So you can build a component once and everybody can use it. It's fantastic.<p>But for <i>internally</i> composing a web application, Web Components are simply awful. They add nearly no helpful features that vanilla JS doesn't already have, and they add bucketloads of extra complexity. You got attributes <i>and</i> properties, and they're mostly the same but kinda not always and oh by the way, attributes can only be strings so good luck keeping that in sync. You got shadow DOM which is great for distribution but super restrictive if you want any sort of consistent global styling (and a total pain in devtools, especially once you go 10 levels deep). You can turn that off, of course, but you gotta know to do that. And plenty more quirks like this. It's just.. It makes lots of easy things 5x harder and 1 hard thing 1.5x easier. Totally not worth it!<p>If you really want to not use a big clunky framework, but at the same time you have a complex enough app that composition and encapsulation is important, you'd be much better off just making your own object hierarchy (ie without extending HTMLElement), skipping all that awkward web component luggage and solely doing what they do best (tie an object to an element).<p>Or, better yet, get over yourself and just use a framework that does this for you. Your future self will thank you (and your colleagues even more so).<p>ps. rant time: If only the web browser people had gotten off their high horse and not proposed the word "Web Components"! If they would've just been named "Custom Elements", which is what they are, then we wouldn't have had 5+ years of people mistaking them for a React competitor.
I’m tired of SPAs and webpages that don’t render without JavaScript.<p>The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off.<p>Now, web developers give you a blank page if you don’t run a megabyte of their shitty code.<p>No thank you.
In theory, “de-frameworking yourself” is cool, but in practice, it’ll just lead to you building what effectively is your own ad hoc less battle-tested, probably less secure, and likely less performant de facto framework.<p>I’m not convinced it’s worth it.<p>If you want something à la KISS[0][0], just use Svelte/SvelteKit[1][1].<p>Nowadays, the primary exception I see to my point here is if your goal is to better understand what’s going on under the hood of many libraries and frameworks.<p>[0]: <a href="https://en.wikipedia.org/wiki/KISS_principle" rel="nofollow">https://en.wikipedia.org/wiki/KISS_principle</a><p>[1]: <a href="https://svelte.dev" rel="nofollow">https://svelte.dev</a>
As I work on personal projects I often have this internal battle: "Do I really need to use react for this small project? Doesn't this make it more bloated than it needs to be?" ...and then I create a vite react app and get up and running quickly while I still have the inspiration for the idea. There's something to be said for having an opinionated framework that just removes a large amount of extraneous decisions that can slow progress. I want a lightweight page but that is secondary to just wanting the thing I'm trying to make.
I'd recommend vanilla TypeScript instead of vanilla JavaScript. The benefits of typing are enormous. You don't even need npm in the critical path either if you use VSCode since it has tsc built in
When you include "No tools" in your requirements, you're locking yourself out of WebAssembly. WebAssembly still requires that you have a C compiler that can target WebAssembly binary format. Zig works well as a compiler for this purpose, even if it's just building C code.<p>WebAssembly doesn't need to be bloated, I've written a C program that imports nothing, and the resulting WASM file is under 3KB in size, and there's under 10 lines of code to load it up.
I've built a library to make vanilla webcomponents reactive via a manual render() call that updates only changed nodes:<p><a href="https://vorticode.github.io/solarite/" rel="nofollow">https://vorticode.github.io/solarite/</a><p>I was planning to improve performance more before announcing it. But even as is it beats React and approaches Lit.js on the JS framework benchmarks.
As someone with a 'full stack' history (ie basic front end knowledge compared to a full-timer on that coal face every day), I do notice a lot of the stuff jQuery does is now native to the browser, like being able to use fetch with promises in a few lines of code, or select stuff with querySelector(All)? or xpath. Then all the nice additions to CSS (and HTTP, no more sprites) that weren't possible in the past and remove the need for frameworks.<p>I tend to rely on Bootstrap so the layout is reasonable on mobile- but that's purely through my own lack of experience.<p>But I guess someone with a more intimate knowledge can easily get the idea of building a framework. Then add on all the use cases and feature requests...<p>Some web pages, particularly traditional media websites are absolute hell holes of bloat, but I guess that's more about their ad serving than lean web development.
The section on Web Components is... teeechnically correct. Unfortunately, it's missing a lot of information on hidden pitfalls of doing things in certain ways<p>As an example, the examples on `connectedCallback()` don't guard against the fact that this callback gets called every time the element gets inserted into the DOM tree. This could happen because you've removed it to hide it and then added it later to show it again, or it could happen because you've moved it to a new location in the tree (different parent, or re-ordering with respect to its siblings). Or maybe you're not manipulating this object at all! Maybe someone else is moving around a parent element of your custom element. Whatever the case, if you're element's ancestor path in any way gets disconnected and then reconnected from `documentElement`, `connectedCallback()` gets called again.<p>That means that you have to spend extra effort to make sure anything you do in `connectedCallback()` either gets completely undone in `disconnectedCallback()`, or has some way of checking to make sure it doesn't redo work that has already been done.<p>There are some other pitfalls involving attributes, child elements, styling, behavior with bundling, etc., that they never really get into. And generally speaking, you're probably only going to find out about them from experience. I don't think I've seen anywhere that goes into Web Component best practices.<p>Which is a shame, because they are incredibly powerful and I enjoy using them quite a bit. Now that my company has decided to go all in on React, I think they've only really seen the beginner path on both. Web Components as a beginner look harder than React as a beginner. Once you start actually building apps, I find they actually end up having to do largely the same level of manual shenanigans. But I find that I'm doing manual shenanigans to work <i>around</i> React, whereas with Web Components there isn't any magic to work around, but there also isn't a lot of "help" that you'd end up ignoring in most cases anyway.
This is the approach I took for my side project website. The idea of installing a framework and dealing with hosting and whatnot just did not interest me.<p>More importantly, the needs of the site are drop-dead simple so no need to install a Ferrari when all I need is a bicycle.<p>Plain vanilla site served from Github FTW!
There are caveats and warnings already by the time we've added an `<x-header>`, and the attribute boilerplate seems onerous right from the start. It pains me to say that almost a decade on, I'm still not a fan of web components.
Some good patterns here. An Event with a callback (what you're calling [context protocol](<a href="https://github.com/webcomponents-cg/community-protocols/blob/main/proposals/context.md">https://github.com/webcomponents-cg/community-protocols/blob...</a>)) I think will prove useful.<p>My main gripe with web components is that while they expose the first half of the tree traversal (from the outside in, via connectedCallback), they don't provide access to the second half, after child elements have been created. (akin to Initialize and Load events from ye olde .NET)
Any attempt to show that vanilla web components are somehow a viable solution always read like a parody.<p>The boilerplate, the innerHTML strings, the long list of caveats, the extra code to make basic things like forms work, manually attaching styles etc. etc.
"However, this rich functionality comes at the cost of framework and tooling complexity"
this makes not sense, can someone explain how doing stuff in raw DOM is less complex than using react that is doing stuff for you?
I've learned that people use what they familiar with.<p>At first, I learned and use plain HTML/CSS/PHP and I thought that was good. At college, they taught .NET framework and for some years, that was my go to techstack. Then I started to learn about more languages and frameworks. At some point, it's hard to switch between them<p>Now I stick with one thing, unless that platform doesn't support it. This also allow me to be a lot more productive since I know most of the thing needed to be done<p>Sure I can start with vanilla web, or some new framework but it'll take a lot more of time and just not worth it
Question - why would you do this in <i>current year</i>? Is it that much more performant? I might be ignorant but frameworks seem to be the lingua franca for a reason - they make your life much easier to manage once set up!
GPT agrees with me.<p>The site positions itself as advocating for simplicity and minimalism in web development—stressing plain HTML, CSS, and JavaScript—but then pivots into building the entire project using React. That’s a contradiction.<p>If the goal is truly "plain vanilla web," introducing React (with its build tools, dependencies, and abstraction layers) runs counter to that ethos. A truly minimalist approach would skip frameworks entirely or at most use small, native JS modules.<p>So yes, it's philosophically inconsistent. Want to dig into a better alternative stack that sticks to that principle?
When I built my new project (<a href="https://teskooano.space" rel="nofollow">https://teskooano.space</a>) I decided to go all vanilla web for it.<p>No regrets, except I found myself also building a framework....
I’m building a plain vanilla web application right now.<p>The main reason is I want direct control of the DOM and despite having 10 years or more react experience, it is too frustrating to deal with the react abstractions when you want direct dom control.<p>The interesting thing is that it’s the LLM/AI that makes this possible for me. LLMs are incredibly good at plain JavaScript.<p>With an LLM as capable as Gemini you rarely even need libraries - whatever your goal the LLM can often directly implement it for you, so you end up with few of no dependencies.
Truly valuable content! This got 1.4k points so far (and counting) for a reason. I have read the full four chapters in one shot, until I hit <i>Go build something vanilla!</i>. I'm definitely bookmarking it.<p>Also, at the beginning of the first chapter, I read:<p>> In theory it's possible to extend other classes.. but in practice <i>this doesn't work yet in Safari</i>.<p>And was like, Ugh! It's always Safari that ruins the party!
Am I misunderstanding something, or is the routing example suggesting I put an entire HTML webpage inside a JS string? This doesn't look like a reasonable alternative to React with JSX.<p><a href="https://plainvanillaweb.com/pages/applications.html" rel="nofollow">https://plainvanillaweb.com/pages/applications.html</a><p>Also, "the hash-based routing approach is effectively invisible to search engines."
> Styling.<p>The problem I found is that my full-SSR project doesn't use any Node.js at all, and it works fine for everything but CSS, because in order to use includes and variables I need a CSS compiler.<p>For example, I use a CSS library that defines a very nice style class "alib-link" for all links. I would want to set it for all <a> elements, without adding `class="alib-link"` all the time. It's easy with a CSS-preprocrssor, but how to avoid using one?
I’m using HTMX and Hyperscript exclusively for interactivity and I’m loving the simplicity of it.<p>Problems of FAANG are not our problems, yet they've somehow convinced majority of software architects that complexity is good.<p>My only concern is when I use HTMX/Hyperscript in my FOSS projects will others be comfortable contributing to it even though it has very little learning curve but they have to empty their React cup.
One of the best torchbearers for Vanilla Web is Bartosz Ciechanowski[0]. The best part the code is super readable [1].<p>[0] <a href="https://ciechanow.ski/" rel="nofollow">https://ciechanow.ski/</a>
[1] <a href="https://ciechanow.ski/js/watch.js" rel="nofollow">https://ciechanow.ski/js/watch.js</a>
A solid overview with some great tips.<p>One recommendation is to change the mental model here. In my eyes it isn’t “don’t use a framework”, it’s “build the framework you need”. It’s tremendously easy to set up an extension of HTMLElement that has 90% of the functionality you’d want out of react. My SPA non.io is built like this - one master component that has class functions I want, and one script for generic functions.
Love to see this!<p>Although I do think there is merit to "light" frameworks such as Astro, with its scoped styling and better component syntax. But at the same time, independence is also important.<p>I started something similar with <a href="https://webdev.bryanhogan.com/" rel="nofollow">https://webdev.bryanhogan.com/</a> which focuses on writing good and scalable HTML and CSS.
From the people who brought you vanilla-js.com<p><a href="http://vanilla-js.com/" rel="nofollow">http://vanilla-js.com/</a>
This website covers a fair bit of React - in particular, it seems Web Components can be used to create components with both state & props.<p>One can imagine a cross-compiler so you could write React, but have it compiled to React-free javascript - leaving no React dependency in production.<p>Would be a lift, but looks superficially possible.<p>What are the blockers to this?
The navigation bar of that site to not stay put, vertically, when you click one of the links.<p>That in itself undermines a lot of the author's message, as they were not able to reasonably de-framework themselves.<p>(And - it's not hard to get the navbar right, in any number of ways. But you do have to do a bit of work before you preach things to others.)
Man, the example web components seem to work great if you wish to hide data from scraping and search indexing... And if you try to work around this, you end up with something very very similar to <a href="https://stimulus.hotwired.dev/" rel="nofollow">https://stimulus.hotwired.dev/</a> .
From <a href="https://plainvanillaweb.com/pages/components.html" rel="nofollow">https://plainvanillaweb.com/pages/components.html</a> I see this piece:<p><pre><code> if (!this.#span)
</code></pre>
What is <i>that</i> kind of magic syntax sugar?! A shorthand for document.getElementById?
<a href="https://clock.rt.ht/::code" rel="nofollow">https://clock.rt.ht/::code</a> has a sophisticated custom <analog-clock> HTML element!<p><a href="https://go.rt.ht" rel="nofollow">https://go.rt.ht</a> has other custom elements!
If you do this with no build step, how can you have cache busting of your component files? or is there an alternative solution that doesn't sacrifice on performance (but also doesn't serve stale files or an inconsistent version between files)?
Am I the only one who (still) does not feel comfortable seeing JavaScript being intertwined into the so-called "vanilla" web in a way that seems more like a hard dependency and not the progressive enhancement we were taught should be the approach for serious public websites?<p>The page <a href="https://plainvanillaweb.com/pages/sites.html" rel="nofollow">https://plainvanillaweb.com/pages/sites.html</a> uses custom components for all code examples and embedded content. Without JavaScript, it merely shows "enable scripting to view ../XYZ.html" in place of all code examples and demos. Better than having no fallback at all, I suppose, yet still not "navigable".<p>The fact that it does not even bother to build these custom components on any native element with a similar purpose—like, say, a link that users could follow to see the text document (*), or a plain old iframe (**)—is grim.<p>Web components are indeed useful for prototyping and personal testing, but are they really beyond the threshold where it is safe to serve them in the wild, potentially harming some users?<p>(*) I know, view-source: links and embeds are sadly blocked by browsers nowadays. Makes very little sense to me. Someone likely managed to exploit it for some nasty purposes, so now we are "protected", I suppose.<p>(**) See? In the olden days even iframes were said to have a link fallback inside, for user agents that did not support them.
Is there any clean solution to the innerhtml problem in plain JavaScript applications, that does not require a virtual DOM or component lifecycle AND has Jetbrains IDE support?<p>I'd like to use lit-html but Jetbrains does not support it - very annoying.
No one cares how many pedals you have on your guitar pedalboard. But if you hit one wrong note, everyone in the audience will hear it and talk about it. Playing pedals is primarily for you and your team, not your audience.
With advent LLM driven development,the traditional web frameworks may soon be rendered obsolete.<p>All the framework abstractions we made for humans coding productivity will need to be re-visited!
I support plain vanilla web for this reason.
I've been recently going this route, everything is static. If I can't host them on an S3 bucket, then I'm building it wrong.<p>Sites are way too bloated nowadays, a lot of the content being served can be static and cached.
I had built a component library with HTML and CSS, and had named it "Vanilla Web" :)<p><a href="https://vanilla-web.netlify.app/" rel="nofollow">https://vanilla-web.netlify.app/</a>
As a react dev I find this fascinating - in the same way I was fascinated by the foraging walk I went on the other day - but was SO HAPPY that supermarkets exist when I saw how much effort it is.
Ironically the style of this site lets it down, the 2006 look (post-css, pre-gradients and big buttons) makes it feel like it's an outdated framework.
Thank you! This is the resource I've been wanting to hand-feed web components to me.<p>Looking forward to playing around with some personal projects. :)
SPAs are generally not worth it nowadays. Why a >20MB .min.js just for few lines of text content?<p>Yeah I don't need your shitty onclick hijacks. Thanks.
my issue with doing web development without frameworks is how to best manage the app state. In react things like redux help with this, but in my experience state management becomes a mess without frameworks, maybe it's a skill issue on my side I don't know.
Nice, but it's no <a href="https://motherfuckingwebsite.com/" rel="nofollow">https://motherfuckingwebsite.com/</a><p>See also <a href="http://bettermotherfuckingwebsite.com/" rel="nofollow">http://bettermotherfuckingwebsite.com/</a><p>and <a href="https://thebestmotherfucking.website/" rel="nofollow">https://thebestmotherfucking.website/</a>
I think there are two separate things.<p>The static websites and beautiful designs<p>With a lot of iframes and widgets, running some kind of services like Disqus chatrooms were<p>It’s far more secure, too.
Web components are honestly the first time I have seen web stuff in years and thought "that actually looks nice".<p>Maybe it's time for me to crawl out of my systems-software-only hole and play around with the web again.
<p><pre><code> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
</code></pre>
Anything more is for the kids on my lawn.
Be wary of building a website without a framework to abstract stuff like DOM usage and page generation. Raw webdev is <i>hard</i>, due to lots of compatibility issues at every level (CSS, HTML, JS) and are moving targets. You shouldn't even try it until you understand protocol design and have implemented some medium complexity standards like IRC and a basic DNS client or server.