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

351–360 of 715 posts

Re: Plain Vanilla Web

#351

Post by chaboud »

lolinder wrote: post #164
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…

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…

Absolutely, and this sort of thing happens in large companies as well.

Software engineers are great at providing “well, why don’t you just..” answers to problems they don’t actually have their brains wrapped around. This often leads to attempts to scale poorly scaling approaches (e.g., we’ll just bake every variant, since there are only four today - which becomes combinatorially intractable after a few years of development).

On the flip side, software engineers are also great at choosing how they’re going to solve a problem before they really have a handle on what they’re going to solve.

I use this maybe 5-10 times per year (and several engineers I work with have taken to repeating it): “tell me what you’re doing but, more importantly, tell me what you’re not doing.”

Forcing people to be explicit about what is not in scope helps to bring clarity to otherwise murky tangles of ambiguity.

Re: Plain Vanilla Web

#352

Post by esseph »

cmonBro22 wrote: post #235
esseph wrote: post #113

Earlier quoted context omitted.

Oh no, you're part of the problem :(

yes, probably, even maybe But what's the problem again?

"Nobody knows how to do anything and shit is inefficient and slow and why does all of this software suck" - customers of things built using frameworks but no understanding of the system being abstracted

Re: Plain Vanilla Web

#353

Post by cosmic_cheese »

roywiggins wrote: post #338
cosmic_cheese wrote: post #330

Earlier quoted context omitted.

Nothing got my old iMac G5 whipped into a frenzy like loading a page that had Flash on it somewhere. I’m not kidding when I say that there were many areas in World of Warcraft, a full-fat seamless open world 3D MMORPG, that didn’t make its fans as angry as Flash could manage to. I was so happy when it finally started to disappear. That kind of sheer disregard for my system resources is inexcusable.

I wonder what could have been if it had had the same effort applied to optimize it as JavaScript did.

It probably could’ve been great, but unfortunately such a thing would’ve been unlikely at best with Flash being solely controlled by Adobe. Not only does that company have a disinclination towards optimization that persists to this day, but with there having been no alternative implementations of Flash, there was no possibility of other organizations taking up that torch or for there to be competition between implementations driving things forward.

Re: Plain Vanilla Web

#354

Post by ummonk »

sanderjd wrote: post #277
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…

There is significant path dependency in either direction. A sibling comment to yours described it very well. There really isn't a good substitute for understanding early on whether you're going to be making a website or an application.

Replacing non-framework JS with a framework is very hard. Replacing static HTML+CSS with React is much more doable, as it isn’t too hard to transform HTML to JSX.

Re: Plain Vanilla Web

#355

Post by 90s_dev »

Etheryte wrote: post #310
90s_dev wrote: post #258

Earlier quoted context omitted.

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.

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

That's the point of preloads. You don't need to choose. As soon as the HTML is loaded, the font is ready. You see the HTML immediately (about 10-20ms) with the web font. Win win.

Re: Plain Vanilla Web

#356

Post by eric-p7 »

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/

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.

Re: Plain Vanilla Web

#357

Post by gkiely »

evantbyrne wrote: post #231
MrJohz wrote: post #218

Earlier quoted context omitted.

Sure, that's what we did in the good old days, and there's good reason that most of us, when building more complex components, switched to better state management systems. The main issue is that, typically, if you're storing data directly in the DOM, you're storing redundant data. For example, if you've got an input that should have a green background if the input is one string, and a purple background if the input i…

This is a comical misrepresentation of reality. The actual reason people switched to React was because it was what Facebook was doing and they wanted to imitate one of the wealthiest companies to ever exist, not because the masses had problems with rendering form widgets. This problem was solved twenty years ago. Perhaps the worst part about this slander is that benchmarks have actually shown time and again that vani…

You were doing ok up until this comment.

Re: Plain Vanilla Web

#358

Post by dleeftink »

benatkin wrote: post #219
90s_dev wrote: post #9

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…

I think it’s time to go back to Unobtrusive JavaScript. What is needed for this are lightweight libraries or practices you can code yourself. HTMX is lightweight which is nice but it’s like script tags. I would rather the urls and methods go in plain HTML and stuff like hx-target be determined by JavaScript, using data- attributes if needed. That way all the unused HTMX features aren’t included.

Shoutout to Facet also[0].

[0]: https://github.com/kgscialdone/facet

Re: Plain Vanilla Web

#359

Post by gcau »

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

Re: Plain Vanilla Web

#360

Post by zdragnar »

moritzwarhier wrote: post #156
zdragnar wrote: post #144

Earlier quoted context omitted.

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…

No, this proves my point. Back in my days of backend programming, Varnish was the "magic" that made servers (especially CMSs) feel fast. Memcached is another common go-to cache.

Browser caching isn't a replacement as the first request for every endpoint is still going to be slow.

Yet somehow, APIs aren't treated with the same requirements for performance as web pages.

Post reply on HN