Plain Vanilla Web

I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to.

There are so many way to do commerce both on and offline and if you squint and look closely you'll find interesting people doing interesting things all around you.

There are times when it's the easiest way to handle things, especially for experienced users. But I find it a massive hassle to maintain support for every possible mistake the user can make.

The fact that this all got hyperlinked is a superb. convenient, but also a challenge from tech perspective, and what FAANG did in the 30 years to come (after 1992) led to this horror of entangled and super-complex technologies we have today. Even vanilla web is quite complex if you take into consideration all the W3 standardization.

Security or not, you can have an appliance run much simpler software given longer product lifetimes,... My only hope is now with llm-assisted coding this vanilla approach comes back, as the boilerplate pain becomes more bearable (how I really hated html at some point...). Besides, it is much more pleasant to prompt yourself a website, rather than try to position some image on stupid fb/insta pages/events, which is one major reason to step back and own your content again.

I originally planned to scrape the data and make my own website with better (imo) controls, but v0 turned into pumping the data into a Google sheet.

I've never needed v1. The Google sheets "UI" solves filtering (i.e., breakfast vs lunch), access control, and basic analytics (~7 other colleagues also use this daily).

Enabling customer self administration/configuration of a "B2B SaaS" system mandates some form of interaction. I would be surprised at how many would not expect "touching a browser" to do so.

> 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.

If there is no validation of information given nor system rules enforcement, then I would question the correctness of said sites/applications.

> 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.

This approach obviates the value added by a system enforcing core software engineering concepts such as fitness of purpose, error detection/reporting, business workflows, and/or role-based access control.

In short, while letting customers send Excel files "and then load+merge their results directly into the same SQL tables" might sound nice, this does not scale and will certainly result in a failure state at some point.

> Email and flat files are far more flexible than any web solution.

Some times I feel like I’m taking crazy pills when I read HN lately. Suggesting that we e-mail requests around and have a person on the other end manually do things including merge data into SQL tables is such a bizarre claim to see. Every once in a while I encounter some business that operates like this and it’s inevitably a nightmare, either as a customer or a partner. Not to mention it’s ripe for everything from fraud to the company falling apart because the person who normally reads those e-mails and does the things for 20 years suddenly leaves one day.

This feels like a mix of rose-tinted glasses reminiscing about the old-timey way of doing things combined with a layer of career burnout that makes everything modern feel bad. Dealing with a business that operates this way is not good.

    7:40 - Bob was delayed by 5 minutes. ETA 7.45
    7:35 - Bob is heading your way. ETA 7:40
    7:20 - Bob has picked up your order from Pizza place

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.

That said, there are b2b exchanges where a simple website is perfect. Supplier quality cases where people need to exchange short texts or general supplier information exchange.

Also b2b customers are far less concerned about UX style than the average retail customer. The former wants a system that just works efficiently and everything else is a waste of time. Sometimes productivity clashes with modern sensibilities and in the b2b case productivity still wins.

I hate mail though for formal processes though. In that case a link to a simple website that orderly takes up information and it is the better solution.

I also hate putting excel files into tables. There is always something going wrong, especially with files created in many different languages, and it is still work overhead. But there are already solutions for general information exchange that aren't necessarily parasitic SaaS services.

Of course there are alternatives, but I wouldn't call the usual ERP/CRM software superior to web apps.

Every business is basically a phone number that you can message. It does not matter if you buy a pizza or furniture, book a hotel or need someone to clean your sofa.

No website. No need to fill in forms. No platform fee.

that is, letting your user to blindly and impulsively following what they want is a mistake.

On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requires, and the answer is that it doesn't handle those features because it doesn't require them because it's a blog.

Meanwhile there are also a lot of people on here who have never worked on a large-scale web app and wonder why frameworks even exist when it's so obviously easy to build a blog without them.

It would be nice if we could just agree that the web hosts an enormous spectrum of different kinds of software and make it clear what kind of software we're talking about when we were opining about frameworks—whether for or against.

In this case: this is a WordPress blog.

100kb would never be a considerations for any of the apps I worked on (as a contractor in the corporate world). I mostly work in large teams, sometimes we had mulit-team monorepos with various line-of-buisness apps using React. 100kb are so completely irrelevant, as for LoB or B2B, no-one cares about the initial page load. Your users use the app on a daily basis, so they get all the JS/CSS/static assets served from their browser cache almost all of the time, until we make a new prod deployment (usually weeks). Plus, all users are always on Ethernet or WiFi at least, not some 3G cellular network somewhere in the desert.

If you use some smarter framework like Next.js, you even get smartly chunked js parts on a per-route basis, that are immutable - they contain a sha256 hash of their content in the filename, and we configure the webserver to serve them via `Cache-Control: immutable`. There won't even be a roundtrip to check for newer versions.

Plus Nextjs comes with tons of other stuff, like pre-loading chunks in the background, or when hovering over a link (i.e. using the time between the hover and the click to already load a chunk). Let alone that the initial render is static html and hydration happens completely unnoticed from the user.

I do find it a little annoying that when we have these discussions about vanilla vs frameworks people hold up an example and I go there and see a news site of articles rather than a complex application, and I think to myself yeah I wouldn't have used a framework in this situation anyway. It's annoying from 2 directions: the first that people ARE using frameworks for sites that shouldn't have ever had them in the first place, and I can bring to mind a couple of news sites I visit regularly where this is obviously the case because of the silly ways they work. Secondly that this is then held up as an example, because most of my work is on very interactive sites so I end up thinking well yeah but that's not going to work for me is it. My feeling is that I could do vanilla but would end up with something like a site specific framework.

My current approach is to use a framework and consistent patterns but to try and use as few other dependencies as possible.

Also infinite scroll breaks the most basic usability issue - you can't track where in the article you're with the scrollbar positioning

And you're using WordPress, so yeah you are using a framework. Turns out you do think they're necessary.

And as you can see, framework != slow, whether it's WordPress or anything else.

Shit just show me how long it takes you to create a nice reactive table with search or a form with proper labels, user interaction, validation, errors, etc

Why would I implement that all from scratch when I can install svelte install a UI library and add a couple lines of code, all with a 25kb overhead and get a better, nicer looking, more well tested product that would take you to do in a week?

With most frameworks you don't need 100kB of JS code.

Heck, with Mithril you get the components, vdom, router, and http client in like 10kB gzip.

Puter (https://news.ycombinator.com/item?id=39597030) was also built purely using vanillaJS (or, JQuery to be more precise)

https://news.ycombinator.com/item?id=43960434

Any sharp edges to this approach?

Developer productivity, theoretically. Although some of these frameworks don’t help with that for me personally.

The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology used to build user interfaces for the web remains somewhat mediocre.

It’s unfortunate that history took some wrong turns with X11, Java, Flash, Silverlight, .NET, and countless other alternatives that I haven’t personally lived through.

Hopefully, someone will eventually find a way to make developing web applications comfortable and the broader community will embrace it.

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.

It’s such a pain having clear separation in development where everything runs off of the react server by default, but then it won’t when deploying, so either you end up doing all sorts of weird stuff or you need to be building and running production locally constantly, thus defeating the whole convenience of having a dev server that can hot reload the changes

The author of this article blog is describing some more advanced SPA-like scenarios, but those are completely optional

HTML was supposed to just a slight markup layer to make it easier to transit and render text documents, likewise that's all HTTP was designed for. The ratio of text-to-markup should be fairly high (I'm sure today it's less than 1). But for some reason (probably the initial ease of publishing globally) we decided that the future of application development should be to entirely reinvent GUIs to be built on top of this layer. If you look under the hood at what React is doing, we just have decades of hacks and tricks well organized to create the illusion that this is a rational way to create UIs.

Imagine a world where we decided we wanted to create applications by hacking Excel documents and Visual Basic (being from the before times, I had seen attempts at this), or have every app be a PDF file making clever use of PostScript? When one remembers how ridiculous it is to attempt to do what we have collectively done, it's not too surprising that a website can require megabytes of JS to render properly and, more importantly, to allow reasonable development processes allowing for some organization of the code base.

As someone who stepped away from web for a while and came back to it a couple of years ago, a straight React or Next.js application is so, so much nicer to work with than old-school webapps were. It feels like the web has finally been dragged kicking and screaming into a world of regular software development best practices. JS isn't the best programming language but it's a proper programming language and it does the job, I'm continually baffled that people would rather contort themselves with the sub-Turing tarpit of CSS and what have you instead of just using some libraries, writing some code, and actually solving their problems in what's usually an objectively easier and better way.

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.

To me the killer app in the modern world is reactivity, ie making views that update in response to changes in the data model. To manually create listeners and do differential updates, and manage removal and teardown of event listeners etc, is akin to doing manual memory management. We used to do that with jquery sometimes, and it’s the most error-prone thing you can do. It’s a stateful shithole.

Once they manage to find a way to modularize components in a way that is largely view-declarative, I would be happy to crawl up on the surface of vanilla JS again, but not before. It’s simply missing functionality, imo.

Many of the 25 mentions of Shadow DOM in the Components Page and 14 mentions of it in the Styling page are about solving problems you now only have because the site recommended you use Shadow DOM, and the problem Shadow DOM itself is _trying_ to solve is one I don't have in components written specifically for my app, which will only be used in my app.

* web-component is a way to attache javascript to certain elements. There are other ways to do it, but sometime this way feel cleaner, like when you do server-side rendering and not using any javascript framework.

* shadow-dom is a way to organize your styles. As you said there are other ways to do it, but I find it useful because it offers full isolation, and is compatible with browsers 3 years back.

Noob question, but what happens behind the scenes in terms of these concepts for web components instead?

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 [2]: https://www.npmjs.com/package/@signaldb/core

> (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.

Oh and it's way worse when said framework is home-grown. They can make something totally broken, and they don't take criticism well.

some doesn't even want to make a framework, the habit and the pattern just repeated intensely and the framework just naturally created.

the way it helps someone maybe tangled you that is normal.

instead hating it, just try to understand why the framework do certain things in certain way.

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.

Meiosis Pattern: https://meiosis.js.org/docs/01-introduction.html

Mithril: https://mithril.js.org/

Rendering libraries like Lit handle declarative templates, and there are many state management solutions, the same ones you can use with React, etc.

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.

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.

> 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/inn...

No, generating HTML string and setting innerHTML is unsafe and slower than necessary. It is better to create DOM elements programmatically. HTML is for serialization of the DOM tree; if everything is done in javascript then you don't need HTML as an intermediate step.

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.

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.

Because it was heavily pushed, advertised, and is the default way of writing web components (you have to explicitly specify mode: open)

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/

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.

The browser people literally promoted them as a React alternative. Then their goals and role changed every year, and now they are again promoted as an alternative

Perhaps my brain has been addled by a decade of React but as the examples became more advanced, they just looked a lot noiser and more complex compared to JSX or Svelte components.

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).

> 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.

Tinygo is also on my list to try for Wasm.

/s

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.

I'm sitting on two UIs at work that nobody can really do anything with, because the cutting-edge, mainstream-acceptable frameworks at the time they are built in are now deprecated, very difficult to even reconstruct with all the library motion, and as a result, effectively frozen because we can't practically tweak them without someone dedicating a week just to put all the pieces back together enough to rebuild the system... and then that week of work has to largely be done again in a year if we have to tweak it again.

Meanwhile the little website I wrote with just vanilla HTML, CSS, & JS is chugging along, and we can and have pushed in the occasional tweak to it without it blowing up the world or requiring someone to spend a week reconstructing some weird specific environment.

I'm actually not against web frameworks in the general sense, but they do need to pull their weight and I think a lot of people underestimate their long-term expense for a lot of sites. Doing a little bit of JS to run a couple of "fetch" commands is not that difficult. It is true that if you start building a large enough site that you will eventually reconstruct your own framework out of necessity, and it'll be inferior to React, but there's a lot of sites under that "large enough" threshold.

Perhaps the best way to think about it is that this is the "standard library" framework that ships in the browsers, and it's worth knowing about it so that you can analyze when it is sufficient for your needs. Because if it is sufficient, it has a lot of advantages to it. If it isn't, then by all means go and get something else... again, I'm definitely not in the camp of "frameworks have no utility". But this should always be part of your analysis because of its unique benefits it has that no other framework has, like its 0KB initial overhead and generally unbeatable performance (because all the other frameworks are built on top of this one).

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.

Cognitive burden is relevant to 100% of web apps.

When frameworks are used for that 99% of web apps for which they are overkill, performance actually drops.

> frameworks seem to be the lingua franca for a reason

Sure, but theres no evidence that the reason is what you think it is.

The reason could just be "legacy", ie. " this is the way we have always done it".

I've seen this play out repeatedly. A company needs a basic CRUD system. Consultancy A brings in designers who produce “wireframes” (usually full-featured eye candy) and UX-centric “journeys.” To justify its bloated fees, the consultancy builds something super-slick using frameworks to match the designs. But once the budget runs out, the customer struggles to maintain it. Eventually, the app becomes unmanageable.

So the consultancy sends in a designer again to produce new mockups and “journeys.” The cycle repeats, this time with another framework.

20 lines of anonymous function calling gibberish is so unpalatable.

It's hard to understand what is actual application code in these stacks.

For me it's mostly about de-tooling your project.

For example - I have a fairly complex app, at least for a side project, but so far I managed to keep everything without a single external dependecy nor any build tool. Now I have to convert it all to react and I'm not very happy about that, I will have to add a ton of tooling, and what's most important for me, I won't be able to make any changes without deploying the tooling beforehand.

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.

    a {
       /* the code from the alib-link class */
    }

    a[href*="news.ycombinator.com"] {
       /* more css */
    }

The last 10%, OTOH...

  #include "header.htm"
  <h1>Title</h1>
  ...
  #include "footer.htm"

Interesting. Why do web components have this effect, but some JS frameworks apparently do not? Or do they all?

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.