aNd jaVaSCripT
Plain Vanilla Web
341–350 of 715 posts
Re: Plain Vanilla Web
#342Earlier quoted context omitted.
My problem with all this vanilla showcases is they are dead ass simple pages with the most basic layouts and user interaction. 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 25k…
Increasingly, this is actually an argument in favor of vanilla web components. The WC ecosystem has grown a lot, and one of the great things about native web components is that they can be consumed by most major frameworks at this point. There are also many mature component sets you can pick from, like shoelace, etc... you can mix and match components from different offerings, something that's not practical with Reac…
If you use a bunch of libraries for routing, UI, authentication, the only thing thats left is the rendering.
And quite frankly I don't see why Id want to reinvent the wheel there.
{#each notes as note} {note.content} {/each
is exactly what Id want to implement for example if I were writing JS functionality to render a collection.
And Svelte for example doesnt restrict you from using vanilla JS whenever you want either
Re: Plain Vanilla Web
#343[dead]
Re: Plain Vanilla Web
#344Earlier quoted context omitted.
Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work and assert that they could do it better no matter how much context you share. This group is particularly fond of leaving dismissive comments without any substance. Dogma is a hell of a drug.
> Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work > In this case: this is a WordPress blog.
If you assign a value judgement to that statement that's on you, not me. I was just providing the missing context: why OP didn't need a frontend framework to meet their requirements.
Re: Plain Vanilla Web
#345With advent LLM driven development,the traditional web frameworks may soon be rendered obsolete.
All the framework abstractions we made for humans coding productivity will need to be re-visited! I support plain vanilla web for this reason.
Re: Plain Vanilla Web
#346Earlier quoted context omitted.
Sure, but the runtime is not exactly designed to guide you to the best way to do this. Hence the prevalence of frameworks to paper over the runtime. I openly admit that I'd rather learn a new framework than touch anything to do with figuring out how the browser is intended to behave in practice. What an abomination and insult to humanity. Edit: holy shit y'all do not like the earnest approach to technology
Huh? The built-in APIs aren't perfect, but we're talking about something simple as ``` fetch('/my-content').then(async res => { if(res.ok) { document.getElementById('my-element').innerHtml = await res.text(); } }) ``` Something like that. Doesn't get much easier. Gone are the days of browser inconsistencies, at least of you stick to "Baseline Widely available" APIs which is now prominently displayed on MDN.
[deleted]
Re: Plain Vanilla Web
#347I'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…
What do you even need JS for on that site? It looks like it should be doable with plain HTML.
Re: Plain Vanilla Web
#348In today's episode of I Hate JavaScript Frameworks, So I Built My Own...
Re: Plain Vanilla Web
#349Earlier quoted context omitted.
> Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work > In this case: this is a WordPress blog.
If you assign a value judgement to that statement that's on you, not me. I was just providing the missing context: why OP didn't need a frontend framework to meet their requirements.
Well, at least you found your category.
Re: Plain Vanilla Web
#350Earlier 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.
Totally different caching techniques. MPAs have a built in mechanism called back/forward cache. It works automatically on most sites, though some invalidate the cache. https://web.dev/articles/bfcache SPAs need to hold onto the data themselves, and correctly transition it between pages/components. Poorly-built ones will simply refresh it every time, or discard it if the data is too large. Both mechanisms can allow fo…
And frankly, most big sites in my experience break bfcache. For instance: YouTube, Gmail, NYT, steampowered.com, CNN. All have broken bfcache in Chrome.