Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Plain Vanilla Web

plainvanillaweb.com

Post reply on HN
Print view View original

501–510 of 715 posts

Re: Plain Vanilla Web

#501

Post by leptons »

Swizec wrote: post #192
lolinder wrote: post #164

Earlier quoted context omitted.

I think that this comment is a great example of the total disconnect these conversations always have. 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 requi…

I work on a site that was built without frameworks with just a sprinkle of jQuery on top of a traditional MVC framework. It worked great but then the business grew and the software became bigger than what fits in 1 engineer’s head. We now have lots of issues that need fixing. A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 secon…

>A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 seconds to go through but there is no UI feedback so you press the button a few more times because maybe it didn’t work? Then you get an error because the first action worked but the subsequent actions failed due to uniqueness constraints.

It's been standard practice for at least 25 years to disable the submit button once it is pressed. If you aren't doing this as a developer, you are practically begging for trouble, and it's really so easy to avoid that trouble.

Re: Plain Vanilla Web

#502

Post by red_admiral »

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

Re: Plain Vanilla Web

#503

Post by windward »

EZ-E wrote: post #452
landgenoot wrote: post #365

Earlier quoted context omitted.

I moved to south east Asia and the phenomenon of a "hotline" openend my eyes. 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.

I'm thinking about why this is not really how we do in the west. Would customers even want to get on the phone? I think my initial reaction if I was to contact a business through a hotline is that on the other side of the phone it will be a massive call center rather than the business directly which would make me cautious.

Just the fact that you've assumed a phone call highlights the difference in culture. It's done over text!

Re: Plain Vanilla Web

#504

Post by sebak82 »

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

Re: Plain Vanilla Web

#505

Post by emseetech »

zarzavat wrote: post #488
emseetech wrote: post #191

Earlier quoted context omitted.

Not just some people. There are a wildly unnecessary amount of marketing pages and pages with basic forms that are built using React. Every time I've been at a company and suggested moving to vanilla css+html or a static generator, the reaction is like I brought up rewriting in assembly. There needs to be a significant push for simplification of the default toolchain. I understand using React, but reaching for it by…

Why not use React for that? If I use React for everything then I don’t have to decide, I don’t have to use two different tools. Consistency is fantastic, if you only use nails then you only need to carry a hammer. Why use two incompatible languages (JSX and HTML) for different types of web pages, when you could just always use JSX? React can statically render to HTML if your page is really static. I think what you’re…

HTML will be around long after React is dead. What guarantee does a React codebase have that its toolchain will still work in 5 years? We've seen build tools come and go, whole approaches deprecated. What if a security update requires upgrading to a non-compatible version of React, therefore necessitating a considerable refactor?

Meanwhile, the original Space Jam website still renders perfectly.

The standards are superior to the frameworks built on top of them. Abstractions come and go, but web standards, once adopted, have a solid track record of sticking around.

Re: Plain Vanilla Web

#506

Post by ntaso »

skrebbel wrote: post #49
CharlesW wrote: post #43

Earlier quoted context omitted.

I haven't started using Web Components, but I was under the impression that libraries like Lit address most of the issues you mentioned for devs who don't want to write their own minimal base class, no?

Sure but this page is about not using a framework. Once you're on board with using a framework like Lit, you might as well use Preact or Svelte or a similarly lightweight framework. The "web component" angle adds no value if it's all internal to your app. Lit is amazing though. It's fast, lean, and easy to learn. In fact, to my experience, the only things about it that are un-ergonomic, are due to the fact that it's…

The irony is: I wrote a bunch of small custom elements [0][1] that do one thing and I don't use Lit for that, because Lit is still overhead. The litte bit of boilerplate overhead of Web Components, I simply wrote by hand.

[0]: Table of contents element: https://github.com/cmaas/table-of-contents-element

[1]: SVG avatars (React-free fork of Boring Avatars): https://github.com/cmaas/playful-avatars

Re: Plain Vanilla Web

#507

Post by ntaso »

pests wrote: post #169
kdbuck wrote: post #57

Reminds me of this classic: http://vanilla-js.com/

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.

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

Re: Plain Vanilla Web

#508

Post by aucisson_masque »

lolinder wrote: post #312
aucisson_masque wrote: post #286

Earlier quoted context omitted.

> how your frameworkless design handles a dozen different features that their use case absolutely requires Would you mind sharing one or two kind of feature that are required by these development team ?

I could, but it would be a distraction because my entire point is that there are an enormous variety of apps with a large variety of requirements being deployed on the web. If I give examples that's going to turn into an argument over whether these specific examples actually need a framework, which will turn into a whole bunch of other hypotheticals of situations that would justify it or situations that won't. Rather…

Holy moly, that's pretentious.

I was genuinely curious because i never faced the kind of issue a web development team would have, it wasn't about counter argumenting.

You could have just said "x and y".

Re: Plain Vanilla Web

#509

Post by troupo »

skrebbel wrote: post #498
troupo wrote: post #227

Earlier quoted context omitted.

> lit-html is a genius alternative to virtual DOMs, etc It's a haphazard solution that they now fight against with "directives" and even a custom compiler "for when initial render needs to be fast". It's not bad, but it's far from genius. And honestly, the only reason it works is that browsers have spent ungodly amounts of time optimizing working with strings and making innerHtml fast. Additionally, it's weird to ask…

Can you explain more about how they're "fighting against lit-html" with the directives? I'm curious what's the struggle here. > Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework. Fair point. I don't personally really care about that either. I guess I just meant to be say that it's not all too custom :-)

It's not really a struggle, but when all you have is a string, how do you enforce certain rules and requirements?

E.g. classMap https://lit.dev/docs/templates/directives/#classmap

--- start quote ---

The classMap must be the only expression in the class attribute, but it can be combined with static values

--- end quote ---

So now you have to figure out which attribute this is called from, whether this particular call is allowed in this attribute etc.

So what they do is they parse (with regexes) their "close to HTML" code into a structure not dissimilar to React's, figure all this stuff out, reassemble actual HTML and dump it to the DOM

Re: Plain Vanilla Web

#510

Post by EmilyHughes »

sebak82 wrote: post #504

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…

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.
Post reply on HN