45 ms·

Plain Vanilla Web

• EGreg 1y ago
  I think there are two separate things. The static websites and beautiful designs With a lot of iframes and widgets, running some kind of services like Disqus chatrooms were It’s far more secure, too.
• prezjordan 1y ago
  As a framework-enjoyer, I'm finding this helpful to leaf through just to learn about modern web platform tech.
• kdbuck 1y ago
  Reminds me of this classic: http://vanilla-js.com/ http://vanilla-js.com/
  • kdbuck 1y ago
    Also, http only. Tell me you are a site from the before time without telling me you are a site from the before time.
    • int_19h 1y ago
      What value would HTTPS possibly add to the website in question?
      • vaylian 1y ago
        It makes it harder for ISPs to inject ads: https://superuser.com/questions/1087669/blocking-the-isps-ads-appearing-after-a-possible-dns-grab-and-redirect-via-port https://superuser.com/questions/1087669/blocking-the-isps-ad...
  • pests 1y ago
    Funny story, I have a comment chain here from a few years ago with someone who didn’t realize it wasn’t actually a framework. Total woosh. Lumped it in with the other frameworks and dismissed them all in the same sentence.
    • ntaso 1y ago
      Well, it's totally likely. But there is VanJS, which calls itself a vanilla JS framework, which adds to the confusion: https://news.ycombinator.com/item?id=36067983 https://news.ycombinator.com/item?id=36067983
• sn0n 1y ago
  I missed the part where they show how to do something similar to ejs or PHP HTML includes for things like header.html and footer.html.
  • laurentlb 1y ago
    That's how I wrote my website a long time ago. #include "header.htm" <h1>Title</h1> ... #include "footer.htm" I'm still using it, and I wonder when I'll be able to get rid of PHP.
• andrewrn 1y ago
  Interesting article about ditching frameworks. Embarassingly helpful for someone who jumped rather quick into React after learning js basics.
  • emseetech 1y ago
    We have a whole generation of devs and designers who "think in react" and it's going to take some time for the culture to decouple itself.
• braden-lk 1y ago
  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!
  • 90s_dev 1y ago
    Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.
    • kybernetikos 1y ago
      Web Components can have properties too, and in fact this is the norm.
      • skrebbel 1y ago
        Can't put those in templates though. It's a serious pain and completely unnecessary.
        • spankalee 1y ago
          You absolutely can put properties in templates. Web component authors do this all the time. Here's a lit-html template that sets a property: html`<my-element .someProp=${x}></my-element>`
          • skrebbel 1y ago
            Not in <template>s, the vanilla HTML alternative to this.
          • 90s_dev 1y ago
            At that point you're not using HTML anymore, you're just calling html() in a fancy way, and that's the whole point of the complaint, that custom-elements are not good at being plain HTML even though that's like its whole thing.
• klysm 1y ago
  Good to understand, but most likely better to stick with react for production stuff anyway
  • sureaboutthis 1y ago
    [dead]
  • cr125rider 1y ago
    Yup, the 2000 libraries you depend on when you run npm install react won’t have any bugs and will always work together. /s
    • zero_shift 1y ago
      Just for anyone reading this and wondering what the dependency footprint of React is: - React-DOM has one runtime dependency (a cooperative scheduler) - React itself has no runtime dependencies It's possible the poster above is referring to build time dependencies. This is harder to assess because there are several options. For example, if compiling JSX using TypeScript, this adds only one more dependency.
    • klysm 1y ago
      As the sibling comment points out, react does not bring in dependencies like that. It is not that heavy but people associate it with heavy things
• doc_manhat 1y ago
  Question - why would you do this in current year? 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!
  • henning 1y ago
    Because of the ridiculous complexity in their setup and operation, their glacially slow performance if it is actually written in JavaScript and not a non-web platform language that compiles to native code, and their extreme volatility and instability/pace of deprecation. The benchmarks I've seen actually show web components being slightly slower than the best frameworks/libraries. The idea is: no build steps initially, minimal build steps later on, no dealing with a constant stream of CVEs in transitive dependencies, no slow down in CI/CD, much more readable stack traces and profiling graphs when investigating errors and performance, no massive node_modules folder, etc. Massive worlds of complexity and security holes and stupid janky bullshit all gone. This will probably also be easier to serve as part of the backend API and not require a separate container/app/service just running node.js and can probably just be served as static content, or at least the lack of Node build steps should make that more feasible. It's a tradeoff some people want to make and others don't. There isn't a right and wrong answer.
  • 90s_dev 1y ago
    Frameworks are fine when you just need to get a job done quickly. And they're ideal when you're in a typical corporate code factory with average turnover, and for the same reasons Java is ideal there. React is the new Java. But when you need something the framework can't provide, good luck. Yes, high performance is typically one of those things. But a well engineered design is almost always another, costing maintainability and flexibility. This is why you almost always see frameworks slow to a crawl at a certain point in terms of fixing bugs, adding features, or improving performance. I'd guess React did this around like 2019 or so.
    • Capricorn2481 1y ago
      > React is the new Java. Overly hated on and conflated with frameworks, yes. React requires very little from you. Even less if you don't want to use JSX. But because Facebook pushes puzzlingly heavy starter kits, everyone thinks React needs routers or NextJS. But what barebones React is, at the end of the day, is hardly what I'd call a framework, and is suitable for little JS "islands."
• jonplackett 1y ago
  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.
  • 90s_dev 1y ago
    No, it's more like fast food vs grocery store & home cooked meals.
• bryanhogan 1y ago
  Love to see this! 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. I started something similar with https://webdev.bryanhogan.com/ https://webdev.bryanhogan.com/ which focuses on writing good and scalable HTML and CSS.
• 90s_dev 1y ago
  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 how people typically do that, and I think we should keep trying to innovate outside of the typical frameworks like React/Svelte, but I definitely don't see any part of web-components being useful to any type of site I run (and I run several disparate types).
  • pajamasam 1y ago
    > rendering an element statically, shipping it, and updating it dynamically via modern JS Noob question, but what happens behind the scenes in terms of these concepts for web components instead?
  • vaylian 1y ago
    Web components provide a clean abstraction boundary. You can add additional methods to your own tags which can encapsulate the logic for updating the data in the component.
    • benatkin 1y ago
      They let you encapsulate the logic pretty much however you want, same as not using web components.
      • vaylian 1y ago
        When you call document.querySelector("something") in the main HTML document, it will not find "something" inside the internal HTML of a web component.
        • benatkin 1y ago
          You can use the shadow DOM outside of custom elements, and can use custom elements without a shadow DOM. Edit: I just added a shadow root to a div in your comment, saving its content beforehand, moved its content inside the shadow root, and added a style with * { all: initial } and your comment text got Times New Roman.
• pawelduda 1y ago
  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
  • hnthrowaway121 1y ago
    This is the common wisdom about frameworks but I think it ignores the wastage & other side effects around frameworks and the things they make easy or difficult. Many of the decisions made in any framework will represent guardrails for things that don’t apply to you specifically. I know you’ll “write your own framework” but maybe that’s optimal in some situations - more than we might give credit to at the moment.
  • mikebelanger 1y ago
    I really wish web components weren't promoted as a "framework alternative" and more of a standardization of custom display components. Frameworks like enhance.dev and lit.dev are good examples of this.
• 90s_dev 1y ago
  > 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) You'll eventually need \<link> anyway for preloads, especially with web fonts, since that's the only 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.
  • Etheryte 1y ago
    I don't find this convincing. For one, many sites don't need web fonts to begin with. For two, the sites that do can use `font-display` or, even better, just let the browser figure it out. Browser developers have spent way more time on these problems than any one of us individually ever will and more often than not, the behavior you get out of the box is already pretty fine.
    • 90s_dev 1y ago
      As a user of websites, I definitely notice when a website uses web fonts and relies on font-display. Preloading them is the only way to avoid jarring changes to the layout. Even if the changes are relatively small, they're very jarring. I won't do that to users of my sites. It's not hard to take care of properly.
      • Etheryte 1y ago
        That's a very subjective take on what properly means in this context. Many would argue that serving the content is the main thing that matters to your users, and if your font takes so long to load that you need to deal with it separately, it would be better to not do that to begin with. To put another way, as a fellow user of websites, I would much rather read what's written than look at a blank page while some marginally different version of Helvetica is fetched in the background.
        • 1y ago
• pelagicAustral 1y ago
  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.
  • thenthenthen 1y ago
    Unless the page refresh is fast, I tend to agree with you!
  • gjsman-1000 1y ago
    I have seen more broken SPAs than MPAs, by far. Ironic, considering SPAs are supposed to improve conversion rates and user experience. Even from big companies with no excuse - Reddit is almost unusable on phones, X was straight up broken for a month straight with image loading on mobile. If you’re writing an SPA, and it isn’t Twitter or a content consumption platform, and it isn’t necessary to be API-driven, seriously just stop. You’re not clever, you’re not improving the experience, you’re only appealing to the tastes of other programmers. If billion-dollar companies can’t get them working perfectly, you certainly won’t.
    • pelagicAustral 1y ago
      We created a generation of developers that AIM to over-engineer requirements... and we also came up with extremely pervasive frameworks to go with it... My firm cannot hire people with no React experience... people REALLY only know how to build cruft these days...
      • gjsman-1000 1y ago
        I have no React, Vue, or Angular experience. My websites were built with Livewire, some HTMX (basically Hotwire in the Rails world, server rendered HTML partials; or maybe Blazor SSR in the .NET world). I use Tailwind and a Laravel backend, but have some experience with C#. If you think that’s interesting, send me your firm’s URL, I’ll consider applying. (Edit: or really anyone reading this who is interested - government of a foreign nation outside the US is not viable, unfortunately.)
• andrewmcwatters 1y ago
  I have some notes here at andrewmcwatters/custom-elements https://github.com/andrewmcwatters/custom-elements https://github.com/andrewmcwatters/custom-elements. My business doesn't use React anymore, and I'm so happy I don't have to do pointless maintenance. 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. 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. I don't see the value in these frameworks anymore.
• skrebbel 1y ago
  I support the general idea here but just because something is in a browser doesn't mean it's a good formalism. Notably, Web Components. They're fantastic for distributing 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. But for internally 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 and 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! 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). 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). 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.
  • CitrusFruits 1y ago
    I remember when web components first came out and there was some hype around them, and just being really confused on what they're actually good for. I think it's really telling that since web components came out there's never been a popular framework, website, or company that has heavily leveraged them.
    • 90s_dev 1y ago
      What about Lit?
• coolhand2120 1y ago
  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. 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. 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.
  • aidos 1y ago
    At 100s of millions I’m assuming you have something closer to a static site than an application?
    • deleted 1y ago
      [deleted]
    • coolhand2120 1y ago
      It's a popular non-netflix/google video streaming app that you've maybe heard of. HTML5 apps/sites/whatever are just part of our supported clients. All clients are supported by a largish SOA. All of the HTML clients are indeed sites, SPAs on a CDN to be more specific, and not "apps" but this is the sickly nomenclature our industry has adopted. But I really should have called them sites if I want to motivate others to do the same, thanks for the correction.
  • mikebelanger 1y ago
    >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 feel the same way. React and Angular (well an earlier version of Angular) were made prior to ES2015 being mainstream, so I do think they made sense to use when they were initially created. Since then, I've become burned out from the constant churn of new frontend frameworks to learn. Even within the world of React, there's different ways of writing components, and different state managers.
• troupo 1y ago
  Any attempt to show that vanilla web components are somehow a viable solution always read like a parody. 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.
• andrewmcwatters 1y ago
  I think routing components are mostly out of date now that CSS View Transitions exist.
• jjcm 1y ago
  A solid overview with some great tips. 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.
  • dragonwriter 1y ago
    > It’s tremendously easy to set up an extension of HTMLElement that has 90% of the functionality you’d want out of react. The last 10%, OTOH...
  • edoceo 1y ago
    Get the first 90% easy, the next 90% is much harder.
    • owebmaster 1y ago
      so hard that React is still working on that final 90% after 10 years with 90% more to go now that they think a compiler is the solution for the current mess.
• einpoklum 1y ago
  The navigation bar of that site to not stay put, vertically, when you click one of the links. That in itself undermines a lot of the author's message, as they were not able to reasonably de-framework themselves. (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.)
• mmcnl 1y ago
  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.
  • mbrumlow 1y ago
    State management, state manage management everybody yells when talking about web dev. It’s not some sort of mystery, it’s just a global of your variables. The example given clearly showed components backed by JavaScript. Which means you could implement a state management system in seconds. But beyond that state management is overrated. I remember when react came out and somebody from face book was describing updating some pending message count number. And how they had trouble with it. The issue was they made shitty code, and the result of react was a solution that hid that shitty code. Because I bet to this day if you profile their example they still had the bug but the state management system silently hid it as a future performance problem.
    • mmcnl 1y ago
      The solution to not using a framework is... building your own framework? What problem does that solve?
  • evantbyrne 1y ago
    State should really only be kept at rest in the backend, form elements, and the occasional variable. SPA state management is fun to puzzle around with, but gives developers the false impression of productivity and is totally redundant to the browser's built-in capabilities for shuttling data back and forth to a server.
    • hdjrudni 1y ago
      C'mon. Even something simple like a date picker. Where are you going to store which month you're looking at? There's state everywhere, and we should not be sending it all back and forth to the server.
• ArinaS 1y ago
  I wouldn't call a website automatically loading 7 scripts on your single visit "vanilla web" though.
  • deleted 1y ago
    [deleted]
  • kmoser 1y ago
    Why? The first line of the site explains: > An explainer for doing web development using only vanilla techniques. No tools, no frameworks — just HTML, CSS, and JavaScript. You're thinking of a lightweight site, which this isn't claiming to be.
• jay-barronville 1y ago
  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. I’m not convinced it’s worth it. If you want something à la KISS[0][0], just use Svelte/SvelteKit[1][1]. 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. [0]: https://en.wikipedia.org/wiki/KISS_principle https://en.wikipedia.org/wiki/KISS_principle [1]: https://svelte.dev https://svelte.dev
• ricardo81 1y ago
  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. I tend to rely on Bootstrap so the layout is reasonable on mobile- but that's purely through my own lack of experience. 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... 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.
• phoronixrly 1y ago
  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 https://stimulus.hotwired.dev/ https://stimulus.hotwired.dev/ .
  • pajamasam 1y ago
    > the example web components seem to work great if you wish to hide data from scraping and search indexing Interesting. Why do web components have this effect, but some JS frameworks apparently do not? Or do they all?
    • owebmaster 1y ago
      ShadowDOM makes it quite difficult to parse the whole document as one thing as each ShadowDOM is traversed separately
• deleted 1y ago
  [deleted]
• d_burfoot 1y ago
  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. 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.
  • euph0ria 1y ago
    Beware of xss
  • busymom0 1y ago
    Make sure to sanitize the content before inserting if you use this approach. > Warning: This is a security risk if the string to be inserted might contain potentially malicious content. When inserting user-supplied data you should always consider using a sanitizer library, in order to sanitize the content before it is inserted. https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...
    • reassess_blind 1y ago
      Anything with user input I just use innerText. Or a simple escapeHTML function within the innerHTML - but I prefer innerText in a separate pass, as using escapeHTML as a pattern gives an opportunity to forget to use it.
  • hdjrudni 1y ago
    If the thing you need to input contains inputs, you're just throwing the user's content away.
  • lelanthran 1y ago
    Setting innerHTML is dangerous if it is a value that came from user input. Users will be able to inject cross site scripting attacks into the forms of other users. Not saying to never sit, just saying to be aware of injection attacks on the front end.
• encom 1y ago
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> Anything more is for the kids on my lawn.
• donohoe 1y ago
  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. My team and I built https://restofworld.org https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. 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.
  • throwaway984393 1y ago
    [dead]
  • pmdr 1y ago
    Congtats! Usability should be a first class citizen. Instead we seemed to have perfected the art of loading screens, "hydrating" components, time & power consuming animations and annoying modals.
  • eduction 1y ago
    Kudos, the site feels really snappy and I’ve definitely come across the journalism before. Any sharp edges to this approach?
    • nzgrover 1y ago
      In my experience, the sharp edges are browser compatibility issues, and I've been gratefully avoiding them for years by using jQuery.
  • CharlesW 1y ago
    Ahhh, the beauty of WordPress-generated static pages.
  • lelandfe 1y ago
    One of the nice things about this is that back and forwards in history is snappy as hell. I’m so used to going back on my iPhone and the entire page reloading.
• mikebelanger 1y ago
  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.
  • troupo 1y ago
    > It's really too bad custom elements got associated with shadow DOM Because it was heavily pushed, advertised, and is the default way of writing web components (you have to explicitly specify mode: open)
    • throwitaway1123 1y ago
      > you have to explicitly specify mode: open The mode does not toggle the shadow DOM on and off. It just specifies whether or not the element's shadowRoot object is a public property. An open mode makes this possible: `document.querySelector('my-component').shadowRoot`. You have to explicitly opt-in to the shadow DOM either imperatively by calling `attachShadow`, or declaratively in HTML by giving the element a template child element with a `shadowrootmode` attribute.
      • troupo 1y ago
        I stand corrected!
• mschuster91 1y ago
  From https://plainvanillaweb.com/pages/components.html https://plainvanillaweb.com/pages/components.html I see this piece: if (!this.#span) What is that kind of magic syntax sugar?! A shorthand for document.getElementById?
  • zero_shift 1y ago
    No, the hash is a red herring. It's a way of signifying a private field on an object.
    • mschuster91 1y ago
      Ah. Thanks, that hint pointed me to [1]. Seems like it's been supported by every major browser since 2021, and only specified in the upcoming ECMAScript 2026 spec. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_properties https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      • zero_shift 1y ago
        It has a contentious history and largely was forced through by one person in TC39 who focused on a particular corner case
• lenerdenator 1y ago
  From the people who brought you vanilla-js.com http://vanilla-js.com/ http://vanilla-js.com/
• deepsun 1y ago
  > Styling. 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. 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?
  • alwillis 1y ago
    > I would want to set it for all <a> elements, without adding `class="alib-link"` all the time. a { /* the code from the alib-link class */ } If you need to style anchor links depending on where they point to, you could use an attribute selector: a[href*="news.ycombinator.com"] { /* more css */ } No preprocessing necessary.
    • deepsun 1y ago
      Yes, that's what I do currently. But that css lib has way more useful styles, it's hard to copy everything (e.g. :hover, :visited, @media etc). They also release new versions, fixes from time to time. Would be great if CSS had a feature "bind all styles from that selector to this selector". Or if browsers understood SCSS, it allows that and much more.
• neiman 1y ago
  I did a small project last week. It's completely vanilla and works great. It's a web tool for writing long threads for Mastodon. 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. Splinter, splinter.almonit.club, if anyone cares.
• spoonsort 1y ago
  Be wary of building a website without a framework to abstract stuff like DOM usage and page generation. Raw webdev is hard, 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.
• lenkite 1y ago
  If they just had HTML imports and template substitution, you wouldn't need Javascript nor web components for a lot of apps.
• andrewstuart 1y ago
  I’m building a plain vanilla web application right now. 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. The interesting thing is that it’s the LLM/AI that makes this possible for me. LLMs are incredibly good at plain JavaScript. 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.
• daitangio 1y ago
  Hum for me vanilla is html+css. If you throw in javascript language, I do not see the 'vanilla' anymore :) 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: https://gioorgi.com/2024/liberta-come-aria/ https://gioorgi.com/2024/liberta-come-aria/
• pjmlp 1y ago
  Loved the whole point being made.
• rtcode_io 1y ago
  https://clock.rt.ht/::code https://clock.rt.ht/::code has a sophisticated custom <analog-clock> HTML element! https://go.rt.ht https://go.rt.ht has other custom elements!
• hanlonsrazor 1y ago
  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. 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.
  • jonahx 1y ago
    This is the narrative, of course. In practice, it is sometimes true, and often not. You can't overstate how often decisions are large orgs are driven by hype, follow-the-herd, or "use popular framework X because I won't get in trouble if I do" mentalities. The added complexity of tools can easily swamp productivity gains, especially with no one tracking these effects. And despite being terrible decisions for the business, they can align with the incentives of individual decision makers and teams. So "people wouldn't do it if it wasn't a net positive" is not an argument that always holds.
  • codazoda 1y ago
    I see absolute messes created out of React and associated frameworks. Quite possibly because, “you’re holing it wrong”. Just using a framework is not going to force best practices and it’s very easy to create terribly bloated and slow systems with these tools if you’re not thoughtful.
• Dwedit 1y ago
  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. 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.
  • runlaszlorun 1y ago
    Did you find using Zig's compiler better than using LLVM sans emscripten? Tinygo is also on my list to try for Wasm.
• RyanOD 1y ago
  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. 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. Plain vanilla site served from Github FTW!
  • Waterluvian 1y ago
    That’s exactly what I do. The projects are small enough that it’s perfect. But it reminds me how insane it would be if it was one of my professional projects.
• bl_valance 1y ago
  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. Sites are way too bloated nowadays, a lot of the content being served can be static and cached.
• nomaxx117 1y ago
  Web components are honestly the first time I have seen web stuff in years and thought "that actually looks nice". Maybe it's time for me to crawl out of my systems-software-only hole and play around with the web again.
• FjordWarden 1y ago
  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. [1] https://wrnrlr.github.io/prelude/ https://wrnrlr.github.io/prelude/
  • jonahx 1y ago
    See also: Meiosis Pattern: https://meiosis.js.org/docs/01-introduction.html https://meiosis.js.org/docs/01-introduction.html Mithril: https://mithril.js.org/ https://mithril.js.org/
  • WorldMaker 1y ago
    A lot of the "boilerplate" of WebComponents disappears if you entirely ignore the Shadow DOM, and you can just do that. They can support objects and arrays as attributes in the same way as the old Progressive Enhancement era (jQuery/Knockout-era) web: via data- attributes and the dataset property. Similar to that era you probably still want to support JSON serialization/deserialization to those attributes for SSG/SSR support.
• chrisweekly 1y ago
  This is a great resource. 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. 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). I also highly recommend https://every-layout.dev https://every-layout.dev which showcases eye-opening, mind-expanding techniques for implementing performant, accessible, flexible web layouts using only browser-native CSS. Context: I've been professionally involved with web development since 1998.
• tanepiper 1y ago
  When I built my new project (https://teskooano.space https://teskooano.space) I decided to go all vanilla web for it. No regrets, except I found myself also building a framework....
• lucb1e 1y ago
  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. https://plainvanillaweb.com/pages/applications.html https://plainvanillaweb.com/pages/applications.html 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 Re-implementing browser code in JavaScript is not using the "plain" or "vanilla" web functionality. You're making your own framework at that point
  • JodieBenitez 1y ago
    Indeed... I'd critisize SPAs a lot less if they wouldn't try to (poorly) mimic MPAs that often.
    • zelphirkalt 1y ago
      And at that point of course we would see some 90% reduction of SPAs, and hordes of FE devs looking for work. There is non-technical incentive at work to keep this bloat in the boat.
• wewewedxfgdf 1y ago
  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? I'd like to use lit-html but Jetbrains does not support it - very annoying.
  • lucgommans 1y ago
    Was wondering what you meant so I looked up "the innerhtml problem" and the top result indeed does list quite a few issues with appending to innerHTML that can be easily avoided. For anyone else interested: https://stackoverflow.com/a/33995479/1201863 https://stackoverflow.com/a/33995479/1201863
• runlaszlorun 1y ago
  Is connected callback still needed over a constructor? I read somewhere it's not needed but couldn't say where that was
• deleted 1y ago
  [deleted]
• lerp-io 1y ago
  "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?
  • intalentive 1y ago
    It’s less complex in the sense that you only need an editor and a browser. You don’t need to install npm or Vite.
    • deleted 1y ago
      [deleted]
  • austin-cheney 1y ago
    Updating content in raw DOM methods is as direct as: 1. Get the desired node. 2. Write the content. That is it. The corresponding code is two lines. But but but... what about state? State is an entirely unrelated issue from writing content. State is also simple though. State is raw MVC plus storage. The way I do it is to have a single state object, the model. I update that model as necessary on user and/or network interaction, the view. When the page loads I read from the state object and then execute the corresponding changes using the same event handlers that would normally execute in response to the user interactions that wrote the state changes in the first place, which is the control. That is simple, but many people find that simple is not easy.
    • insin 1y ago
      It is simple, and it very quickly becomes un-simple when it comes into contact with increasing app size/complexity (for things which _need_ to be apps, and which have to deal tasks where the size/complexity is essential due to factors which _can't_ be avoided, e.g. an app which deals with Workers' Comp, with laws and requirements which differ by U.S. state in ways which cut across the entire app) and team size/mix of experience.
      • 1y ago
• bob1029 1y ago
  I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?". I've discovered that when you start getting really cynical about the actual need for a web application - especially in B2B SaaS - you may become surprised at how far you can take the business without touching a browser. 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. 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.
  • getnormality 1y ago
    This is how 100% B2B worked before there was B2B SaaS, and it's still how 99% of B2B works today.
    • SoftTalker 1y ago
      Yep. EDI and FTP.
      • accrual 1y ago
        Still is that way in many places. Some smaller clients I've worked with prefer the flat-file + FTP over a more integrated solution (TCP/IP, etc.).
  • _heimdall 1y ago
    Especially for internal tooling that is little more than CRUD, I find the web to be most useful when a consultant is brought in to build it once or when an internal team can't be allocated to help maintain it. If you have even a small bandwidth to maintain it over time, quick and simple solutions like an Excel template and a few custom scripts work great and often end up being more flexible as your end user is mostly working with raw data.
• mariconrobot 1y ago
  [dead]
• naveed125 1y ago
  It’s cool and I wish I had a use case for it.
• nobody42 1y ago
  http://youmightnotneedjs.com http://youmightnotneedjs.com
• mwilcox 1y ago
  aNd jaVaSCripT
• alprado50 1y ago
  [dead]
• nickevante 1y ago
  With advent LLM driven development,the traditional web frameworks may soon be rendered obsolete. All the framework abstractions we made for humans coding productivity will need to be re-visited! I support plain vanilla web for this reason.
• dalmo3 1y ago
  In today's episode of I Hate JavaScript Frameworks, So I Built My Own...
• eric-p7 1y ago
  I've built a library to make vanilla webcomponents reactive via a manual render() call that updates only changed nodes: https://vorticode.github.io/solarite/ https://vorticode.github.io/solarite/ 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.
  • drysart 1y ago
    I've done something similar to this for my own internal applications, making use of snabbdom to handle the DOM updates. Snabbdom is tiny, robust, proven, and unopinionated; so I didn't see any particular need to reinvent that wheel.
    • eric-p7 1y ago
      Nice. I used the open source udomdiff for my domdiffing, since my approach didn't use a virtualdom.
• gcau 1y ago
  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)?
  • Joeri 1y ago
    There’s an article explaining the options on the blog section: https://plainvanillaweb.com/blog/articles/2024-12-16-caching-vanilla-sites/ https://plainvanillaweb.com/blog/articles/2024-12-16-caching...
• webprofusion 1y ago
  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.
  • webprofusion 1y ago
    Literally use WebFontPicker and choose Raleway or something.
    • webprofusion 1y ago
      Although I'm liking the use of javascript classes, not for any technical reasons just that it's a defiant middle finger to the React crew (who you now no longer hear from) that cancelled classes.
• typedef_struct 1y ago
  Some good patterns here. An Event with a callback (what you're calling [context protocol](https://github.com/webcomponents-cg/community-protocols/blob/main/proposals/context.md https://github.com/webcomponents-cg/community-protocols/blob...)) I think will prove useful. 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)
• fitsumbelay 1y ago
  I always appreciate a reminder of this site
• namuol 1y ago
  Lost me at Web Components. There are many things the web does great, but Web Components is not one of them. Can we move on?
  • vaylian 1y ago
    Why do you think web components are not great?
• solumos 1y ago
  I know not with what tools Web 3.0 will be built, but Web 4.0 will be built with vanilla HTML, CSS and Javascript.
• cadamsdotcom 1y ago
  This website covers a fair bit of React - in particular, it seems Web Components can be used to create components with both state & props. 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. Would be a lift, but looks superficially possible. What are the blockers to this?
  • cube00 1y ago
    I suspect that's where the new React Compiler will eventually head where based on your code it will try and remove as much React runtime as possible if it's not needed.
    • cadamsdotcom 1y ago
      Took a look - after the pain of React memoization, that's a super exciting development. Thanks for the pointer!
• est 1y ago
  SPAs are generally not worth it nowadays. Why a >20MB .min.js just for few lines of text content? Yeah I don't need your shitty onclick hijacks. Thanks.
• umvi 1y ago
  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
  • n2h4 1y ago
    [dead]
  • fud101 1y ago
    interested in this.what do you mean vscoe has it built in?
• deepriverfish 1y ago
  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.
  • ardleon 1y ago
    You can use Redux outside of React, you also have this option, RxJS.
• quantadev 1y ago
  There's another solution to the "Plain Vanilla Web". It's called Markdown.
• deleted 1y ago
  [deleted]
• Julesman 1y ago
  GPT agrees with me. 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. 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. So yes, it's philosophically inconsistent. Want to dig into a better alternative stack that sticks to that principle?
• docuru 1y ago
  I've learned that people use what they familiar with. 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 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 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
• TaboZ 1y ago
  [dead]
• hsnice16 1y ago
  I had built a component library with HTML and CSS, and had named it "Vanilla Web" :) https://vanilla-web.netlify.app/ https://vanilla-web.netlify.app/
• moron4hire 1y ago
  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 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. 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. 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. 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 around 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.
• sneak 1y ago
  I’m tired of SPAs and webpages that don’t render without JavaScript. The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off. Now, web developers give you a blank page if you don’t run a megabyte of their shitty code. No thank you.
  • zzo38computer 1y ago
    > The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off. I agree. (This should also include CSS, TLS, cookies, and many other things; I often disable CSS, and it should work just as well if CSS is disabled just as much as if pictures or JavaScripts or cookies are disabled.) However, there are some uses where JavaScripts may be helpful e.g. if a web page has a calculations or something like that implemented by JavaScripts; but that is not an excuse to prevent the documentation from being displayed if JavaScripts are disabled. They should really make documentation and as much other stuff to work even if JavaScripts are disabled (and, depending on what it does, may provide a description of the calculation or of the rules of the game being implemented, or a link to API documentation, or something else like that). Pictures also might be useful in some articles (but are often overused); but even then, if the picture is not displayed you could use an external program to display them. However, if it can be explained in the text, then it should be explained in the text if possible so that even if you do not have a suitable program to display that picture (or do not want to display that picture, e.g. the file size is too big; or maybe you are using text to speech or a braille display or something else like that) then it will still work. TLS also should not always be mandatory, either. For things that require user authentication, and for writing, it can be useful to be mandatory (especially if you are using X.509 client authentication; this will be better than using cookies or other methods for authentication, anyways); but for read-only access to public data, TLS should be optional (but the server should still allow it in case the client wants to use TLS for read-only access to public data too).
    • sneak 1y ago
      No, TLS should always be required. We should be moving away from plaintext anything on the wire, if for no other reason than privacy (but also for integrity, injecting scripts into an HTTP response is a nasty attack surface).
• anhtran 1y ago
  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.
• Uptrenda 1y ago
  If every website did this I wonder if there would be a measurable impact on things like: battery life, performance, and bandwidth usage.
• cmonBro22 1y ago
  [dead]
• Ygg2 1y ago
  I'm seriously starting to wonder do we even need JavaScript. Or images. How much could you do with UTF-8 web page.
  • perilunar 1y ago
    “I only read it for the articles”
• dmje 1y ago
  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.
• klaushougesen1 1y ago
  Personally have had great experience in high throughput, complex paas / saas webapps by rigourously only adding things when it was clearly needed. 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. the other way around is near impossible
  • TimTheTinker 1y ago
    Yeah, vanilla HTML is a difficult approach when a corporate design system and component library is thrown into the mix of requirements. From where I sit, Lit looks like one of the best ways forward. Here's an awesome design system someone built using Lit: https://nordhealth.design/ https://nordhealth.design/
• deleted 1y ago
  [deleted]
• red_admiral 1y ago
  Once you're building custom components in JS files, aren't you basically writing your own microframework? 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. 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).
  • oxcabe 1y ago
    Just checked what's there for libs implementing local state management + server-side sync in vanilla JS. The best options I found were `@tanstack/query-core`[1] and `@signaldb/core`[2]. The former packs no dependencies, with a total size of 89.18 kB if you were to put all the module JS code together, unminified, on a single file. Which could be even smaller with an optimising bundler that tree-shakes and minifies the build. [1]: https://www.npmjs.com/package/@tanstack/query-core https://www.npmjs.com/package/@tanstack/query-core [2]: https://www.npmjs.com/package/@signaldb/core https://www.npmjs.com/package/@signaldb/core
  • WorldMaker 1y ago
    That's why there are an increasing number of "microframeworks" for Web Components such as Lit and FAST. (My own Butterfloat I think works very nicely in Web Components, too, though some would quibble that it isn't a "microframework" because its one and only dependency is RxJS, which isn't as bloated as people remember it being, but has that reputation.) > (without updating the DOM each turn, hence shadow DOM). Uh, Shadow DOM doesn't help with DOM performance and can make some things worse. If your Web Component has terrible DOM performance in the Shadow DOM that can still noticeably degrade DOM performance of the entire DOM. I'm of the growing opinion that the Shadow DOM is over-complicated for what it tries to do and most Web Components don't actually need the Shadow DOM and would be better without it and would have a better idea of their own performance (issues) without it. Hot take: The Shadow DOM is built for advertisers that want beefier iframes, not for building good performance.
• sebak82 1y ago
  When it comes to reducing complexity—especially for Java developers—it’s worth checking out Vaadin. 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. 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. 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. (Full disclosure: I work at Vaadin, but I’m genuinely a fan of the approach because it saves developers a lot of headaches.)
  • EmilyHughes 1y ago
    This still of programming does not adhere to MVC though, you can't ever swap out the frontend because it's basically merged to the backend and I suspect complex to debug simmilar to JSF.
    • sebak82 1y ago
      So a pattern is not mandatory with Vaadin, but you can make the UI “simple” changeable with a corresponding pattern of your choice. MVP and MVVM would be good examples of this. Debugging in the frontend is not trivial, but can still be done with the appropriate setting in the properties (https://vaadin.com/docs/latest/flow/configuration/development-mode#disable-precompiled-bundle https://vaadin.com/docs/latest/flow/configuration/developmen...)
    • int_19h 1y ago
      All MVC (or rather something more modern like MVVM) happens on the server in this scenario, but it doesn't mean that it doesn't happen at all. A different View + ModelView on top of the same Model could then be used to provide a different frontend if that is ever required (in practice, it probably won't be).
• myfonj 1y ago
  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? The page https://plainvanillaweb.com/pages/sites.html https://plainvanillaweb.com/pages/sites.html 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". 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. 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? (*) 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. (**) See? In the olden days even iframes were said to have a link fallback inside, for user agents that did not support them.
  • tzebco 1y ago
    You're not the only one. I block most subresources by default and was disappointed to see empty figures peppered throughout their articles. I'm learning to not automatically equate advocacy of "vanilla" with advocacy of robustness.
  • int_19h 1y ago
    It depends on the context. What you say makes a lot of sense for web sites, but expecting a web app to use JS strictly as a "progressive enhancement" is IMO unreasonable. Now, this particular website is indeed a proper website, and so it shouldn't need JS to do its thing. But it's also a website that advocates for a certain way of developing web apps (even if they don't use such terminology themselves), and as such, is essentially a demo for the same.
    • myfonj 1y ago
      This is quite fair point, yet I'd argue that still most so called web apps could (and should) use basic old-school HTML forms as the underlying technology, and progressively enhance from that baseline, up to the "app-y" look and feel we know and ~~ha~~__love__. Obviously, there are some limits where application built with bog standard HTML forms becomes too cumbersome or makes no practical sense, as you say, but I think that that threshold is far higher than what current web-app landscape exhibits. I think the threshold is around video editing software, or real-time multi-user collaborative spaces perhaps. But for the rest, following three old steps Make it work — just HTML. Make it nice — add some CSS. Make UX slick — add JS. still makes sense to me. In context of the plainvanillaweb.com it would mean just moving the content from non-semantic attributes of custom components to their semantic initial content, such as adapt <x-avatar src="https://i.pravatar.cc/150?u=a042581f4e29026024d"></x-avatar> to get the data from its contents: <x-avatar><img src="https://i.pravatar.cc/150?u=a042581f4e29026024d" alt></x-avatar>
• Abishek_Muthian 1y ago
  I’m using HTMX and Hyperscript exclusively for interactivity and I’m loving the simplicity of it. Problems of FAANG are not our problems, yet they've somehow convinced majority of software architects that complexity is good. 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.
• gembeMx 1y ago
  [dead]
• montag 1y ago
  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.
• montag 1y ago
  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.
  • LAC-Tech 1y ago
    Of what relevance is this? Custom elements are very well documented and work in every browser. Get your server to render html with your own elements in them - your own "island architecture", no vercel necessary. That some site promoting them is moribund doesn't change the fact they work - and are widely used.
• staticelf 1y ago
  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. 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. 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. 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.
• Meneth 1y ago
  Nice, but it's no https://motherfuckingwebsite.com/ https://motherfuckingwebsite.com/ See also http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/ and https://thebestmotherfucking.website/ https://thebestmotherfucking.website/
• coxley 1y ago
  Thank you! This is the resource I've been wanting to hand-feed web components to me. Looking forward to playing around with some personal projects. :)
• NoSalt 1y ago
  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.
  • dandelion9 1y ago
    I agree. It's career-driven bullshit bingo. It gives junior's an opportunity to gain an advantage over senior's ("Oh you don't know JavaScript micro-framework 2025 #10?") and everyone involved in billing for time (employees and consultant) a reason to "refactor" and keep the magic money tree around.
    • shoeb00m 1y ago
      I would argue the web has remained more stable than any other development space. You can still build something with jQuery code from 2007, and it's still supported by modern browsers. You can even start using modern browser APIs without even upgrading jQuery. You could add any modern library as long as it doesn't depend on jQuery. If you had a python 2 codebase from the same year, you would basically have to scorch it and do a rewrite.
  • archarios 1y ago
    I think a big advantage of a framework is that the team(s) don't end up arguing over architecture as much because the framework made those decisions for us. Also the framework has a proven history of this architecture working well for xyz problems. Also it makes finding compatible talent much easier. If you're using a framework, finding someone who has worked with that same framework for years makes it a safer bet that they will start being useful quickly. If you have your own bespoke system, it could be years until a new hire feels comfortable with the existing system's quirks and nuances and stops breaking things as much.
• jdlyga 1y ago
  Who else considers plain vanilla web to be writing websites in pure html like it's 1995?
  • owebmaster 1y ago
    Happy to see that you're alone on that
• kingbob000 1y ago
  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.
• lozzo 1y ago
  I am so very pleased to see a site called "plain vanilla web dot com" being almost at the top of hackernews in 2025.
• frollogaston 1y ago
  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. https://plainvanillaweb.com/pages/applications.html https://plainvanillaweb.com/pages/applications.html Also, "the hash-based routing approach is effectively invisible to search engines."
• sagaro 1y ago
  One of the best torchbearers for Vanilla Web is Bartosz Ciechanowski[0]. The best part the code is super readable [1]. [0] https://ciechanow.ski/ https://ciechanow.ski/ [1] https://ciechanow.ski/js/watch.js https://ciechanow.ski/js/watch.js
• peter-m80 1y ago
  What about state management? All little demos ignore this
• createaccount99 1y ago
  Webcomponents are such a mess! Never ever will I use them as they are presented.
• redbell 1y ago
  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 Go build something vanilla!. I'm definitely bookmarking it. Also, at the beginning of the first chapter, I read: > In theory it's possible to extend other classes.. but in practice this doesn't work yet in Safari. And was like, Ugh! It's always Safari that ruins the party!