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

151–160 of 715 posts

Re: Plain Vanilla Web

#151

Post by MrJohz »

spankalee wrote: post #130
90s_dev wrote: post #24

Earlier quoted context omitted.

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.

This is just a lie perpetuated by the React team 10 years ago All HTML elements are JavaScript objects that have properties. You can pass arbitrary data to custom elements via those properties. Look at any modern HTML template system and you'll see the ability to pass data to properties declaratively.

Well it's not a lie, it's how HTML and the DOM work. Attributes are strings, and what you write in HTML will be passed as attributes.

You do also have access to properties, but only in Javascript — you can't for example write something like ``. That means that if you need to pass around complex data types, you need to either manipulate the DOM objects directly, or you need to include some sort of templating abstraction that will handle the property/attribute problem for you.

This is my main criticism of web components. At the simplest levels, they're not useful — you could build this website very easily without them, they aren't providing a particularly meaningful abstraction at this level of complexity. But at the more complex levels, they're not sufficient by themselves — there's no state management concept, there's no templating, there's not even much reactivity, other than the stuff you could do with native JS event emitters.

As far as I can tell, the best use-case for web components is microfrontends, which is a pretty useful use-case (much better than iframes), but it's very niche. Apart from that, I really don't see why you wouldn't just write normal Javascript without worrying about web components at all.

Re: Plain Vanilla Web

#152

Post by debugnik »

c-linkage wrote: post #87
smokel wrote: post #73

Earlier quoted context omitted.

As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly. The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology use…

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

> Many desktop applications are written in .Net so you don't even need to install the runtime because it's preinstalled on the operating system.

The last .NET version to be deployed this way has a 10 year old feature set. Nowadays you bundle the parts of .NET you need with the application.

Re: Plain Vanilla Web

#153

Post by 90s_dev »

throwanem wrote: post #134
90s_dev wrote: post #110

Earlier quoted context omitted.

> ${x} Fine for x:string, but what about w:WebWorker?

Presumably I've defined a .toString() method on w that will behave as I wish when implicitly invoked to perform this coercion. If I haven't, then presumably I'll be satisfied with the inherited default behavior, which will probably look something like " [object Worker] ". If I care about this extremely contrived example case, in other words, I'll do something to handle it. If I don't, I won't. If I do, it's been easy…

Yeah sorry I meant how would you pass it to another GUI component like we can in React.

Re: Plain Vanilla Web

#154

Post by daitangio »

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/

Re: Plain Vanilla Web

#155

Post by mikebelanger »

hdjrudni wrote: post #103
mikebelanger wrote: post #80

Earlier quoted context omitted.

You can invoke custom methods and pass in any kind of data into them. As in class SomeElement extends HTMLElement { constructor() { super(); } someMethod(x) { this.innerHTML = ` ${x} `; } } // ignore registry stuff const customElement = document.getElementById('custom-element-id'); customElement.someMethod(42); But you won't learn that from most mainstream custom element tutorials though, for whatever reason.

That doesn't look like it even has anything to do with custom components, that's just adding a method to a class. OOP 101.

>just adding a method to a class. OOP 101.

You're right, it is just a method call from a class. Nothing interesting or new. And that's exactly why I like it! I like me FE code as boring, unimpressive and as simple as possible.

Re: Plain Vanilla Web

#156

Post by moritzwarhier »

zdragnar wrote: post #144
rjh29 wrote: post #135

Earlier quoted context omitted.

SPAs are supposed to be more efficient by only loading the data needed to update, but somehow back/forward are 100x more responsive on static pages or static sprinkled with JS, and they don't break the back button either. SPAs always have a kind of sluggish feel to them.

That's because backend-rendered sites need a shit load of caching. SPAs tend to just use APIs that aren't cached.

That's primarily because many SPAs aggressively prevent caching of all xhr responses using headers (which are ofc defined from the BE side)

And the reason for that is mainly to prevent edge cases and make sure people in CRUD apps see up-to-date content.

The experience with a no-cache max-age=0 server-rendered site would be very similar.

All of the headaches around custom routing code + restoration of state are pretty much obsolete wirh bfcache, introduced more than 5 years ago.

If you build a dynamic page and use HTTP headers to prevent caching, stop complaining about it. Most people making this argument want to offload dealing with external APIs to the frontend, and then complain about the result when no requirements around API response caching were defined, let alone time was given to define them.

Re: Plain Vanilla Web

#157

Post by evantbyrne »

hdjrudni wrote: post #108
evantbyrne wrote: post #72

Earlier quoted context omitted.

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.

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.

Date pickers aren't simple. I would challenge you to explain why you couldn't just store it in a variable or on the element itself.

Re: Plain Vanilla Web

#158

Post by LegionMammal978 »

c-linkage wrote: post #87
smokel wrote: post #73

Earlier quoted context omitted.

As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly. The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology use…

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

> For the naysayers: please then explain to me why Steam is so successful at deploying large games on multiple platforms?

Because Valve puts lots of time and money into making it work for their customers (https://github.com/ValveSoftware/Proton/graphs/contributors), time and money that the average small business can't afford.

Re: Plain Vanilla Web

#159

Post by pests »

MyPasswordSucks wrote: post #111
c-linkage wrote: post #87

Earlier quoted context omitted.

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

Even the most friction-free ClickOnce deployment is going to be more of a deployment hassle than "hey, users, you know how you go to https://subdomain.local-intranet/place to add or subtract items from the inventory database? Well, continue doing that". The webapp doesn't care if someone's machine was down overnight or if the paranoid lady in design managed to install some local "antivirus" which blocked the updated…

The web browser is not some magic tool that is always guaranteed to work. Group policy alone can wreck total havoc on web apps on all the major browsers.

Re: Plain Vanilla Web

#160

Post by throwanem »

90s_dev wrote: post #153
throwanem wrote: post #134

Earlier quoted context omitted.

Presumably I've defined a .toString() method on w that will behave as I wish when implicitly invoked to perform this coercion. If I haven't, then presumably I'll be satisfied with the inherited default behavior, which will probably look something like " [object Worker] ". If I care about this extremely contrived example case, in other words, I'll do something to handle it. If I don't, I won't. If I do, it's been easy…

Yeah sorry I meant how would you pass it to another GUI component like we can in React.

If I want in the general case to append a child node to a parent (as here with the h1 as parent and the stringified interpolated value as child), I will in almost every case call parent.appendChild(child), where parent and child both implement Node, which is the parent class of Element. The result will correspond closely to the element tree which would be constructed by assigning a string like your example to some other element's innerHTML. (You are essentially using the browser DOM implementation as a templating engine. As sugar over a lot of createElement calls and piecewise tree construction, this isn't a terrible strategy! The JSX with which you're familiar is a more elaborate and more typesafe solution for essentially the same problem.)

Similarly, these references would be from the JS perspective a POJO with lots of seriously heavy implicit "render magic," so you can use them, as with any first-class Javascript value, as function arguments parallel to but a superset of what React does with its props. See the MDN documentation on Node.appendChild (and Node, Element, HTMLElement, etc) for more: https://developer.mozilla.org/en-US/docs/Web/API/Node

If I want to represent the state of a worker thread in the UI, a problem I first recall solving over a weekend in 2016, the way I do it will end up closely resembling the "MVC pattern," with the Worker instance as "model," the DOM element structure as "view," and a "controller" that takes a Worker and returns an element tree. Even if I'm using React to build the UI - which I have also been mostly doing for about as long - I am still going to handle this translation with a library function, even if my component actually does accept a Worker as a prop, which it actually very likely will since that will enable me to easily dispatch effects and update the UI on changes of worker state. I might define that "business logic" function alongside the component which uses it, in the same module. But React or vanilla, I won't put that logic in the UI rendering code, unless it is trivial property mapping and no more (unlikely in this case, since any interesting worker thread state updates will arrive via message events requiring the parent to keep track in some way.)

Does that help clear up what I'm getting at?

Post reply on HN