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

71–80 of 715 posts

Re: Plain Vanilla Web

#71

Post by mikebelanger »

pelagicAustral wrote: post #14

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.

The nice thing about the plain "vanilla" approach is it can be used to enhance a more traditional SSR-rendered site. And it doesn't need a complete rewrite in React or whatever.

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

Re: Plain Vanilla Web

#72

Post by evantbyrne »

mmcnl wrote: post #44

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.

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.

Re: Plain Vanilla Web

#73

Post by smokel »

pelagicAustral wrote: post #14

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.

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

Re: Plain Vanilla Web

#74

Post by CharlesW »

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…

> Sure but this page is about not using a framework.

Fair enough, but the way I read TFA, it doesn't dissuade developers from using tiny convenience libraries that leverage native browser capabilities. Based on your pushback, it sounds like my perception that Lit is mostly a convenient base class for Web Components is very incorrect. I'll dig into that more, thanks!

Re: Plain Vanilla Web

#75

Post by mikebelanger »

coolhand2120 wrote: post #23

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 a…

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

Re: Plain Vanilla Web

#76

Post by pmdr »

donohoe wrote: post #66

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 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 frame…

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.

Re: Plain Vanilla Web

#77

Post by Etheryte »

90s_dev wrote: post #12

> The most basic structuring technique is separating CSS into multiple files. We could add all those files in order as \ 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 \ anyway for preloads, especially with web fonts, since that's the only way to prevent FOUC. Personally I lean on…

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.

Re: Plain Vanilla Web

#78

Post by 90s_dev »

jakelazaroff wrote: post #55
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.

Imagine 50 years ago: “Data passing seems inherently broken in Unix, because all processes must use strings for input and output. Such a model just can't be built on top of.”

Show me a successful GUI made with bash.

Re: Plain Vanilla Web

#79

Post by eduction »

donohoe wrote: post #66

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 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 frame…

Kudos, the site feels really snappy and I’ve definitely come across the journalism before.

Any sharp edges to this approach?

Re: Plain Vanilla Web

#80

Post by mikebelanger »

90s_dev wrote: post #24
braden-lk wrote: post #4

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!

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.

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