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

241–250 of 715 posts

Re: Plain Vanilla Web

#241

Post by kalaksi »

a4isms wrote: post #198
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…

Many years ago—2002!—Joel Spolsky wrote this: https://www.joelonsoftware.com/2002/05/06/five-worlds/ His thesis was that before arguing about software development tools, practices, anything really, it's vital to establish what kind of development you're doing, because each "world" has its own requirements that in turn motivate different practices and tools. The worlds he quoted were Shrink-wrap; Internal; Embedded; G…

This is also why it's often frustrating to try to understand people's opinions regarding programming and code. There's almost always too little context, even without handwavy or subjective stuff like "it's too complex" or general bandwagoning.

Actually, I feel like many times the conversations about code are pretty shallow anyway with not much info. Maybe it's just difficult without properly established context but OTOH that can quickly get complicated and require a lot more effort.

Re: Plain Vanilla Web

#242

Post by pier25 »

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've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code

With most frameworks you don't need 100kB of JS code.

Heck, with Mithril you get the components, vdom, router, and http client in like 10kB gzip.

Re: Plain Vanilla Web

#243

Post by 90s_dev »

spankalee wrote: post #197
90s_dev wrote: post #165

Earlier quoted context omitted.

At that point you're not using HTML anymore, you're just calling html() in a fancy way, and that's the whole point of the complaint, that custom-elements are not good at being plain HTML even though that's like its whole thing .

Being plain HTML is important for the user of the element. That the element may use a library for its implementation is basically irrelevant.

Hi.

Re: Plain Vanilla Web

#244

Post by ab5tract »

sofixa wrote: post #208
coolcase wrote: post #131

Earlier quoted context omitted.

Nothing wrong with Flash and Silverlight except each being controlled by a single company. I liked those technologies. Adobe Flex was very nice to program in and use for it's time.

Both were absurdly slow and resource intensive.

Flash was a lot of things, but also, at the same time, neither of these things. (You could come across poorly coded and thus poorly performing apps, but that wasn’t the standard).

Modern day SPAs are far, far worse offenders when it comes to smothering resources.

Re: Plain Vanilla Web

#245

Post by MrJohz »

spankalee wrote: post #195
MrJohz wrote: post #170

Earlier quoted context omitted.

That's not web components, though that's lit-html. That's an additional library you need to pull in to manage your web components. Which kind of ruins a lot of the stated benefits of web components. If I need a framework to write my web components, why not just pull in a different framework that skips the web component level completely and just outputs HTML/CSS directly? What is this intermediate step actually bringi…

How does using a library ruin the goals of the components at all? The goal of web components is to enable interoperable, encapsulated, reusable components, where how they're built is an implementation detail. You can use a web component that used lit-html without knowing anything about lit-html, it even that the component uses it.

In theory it is completely an implementation detail, I agree. In practice, it's bloat. If every web component I use in my project might pull in a completely different framework behind the scenes (and worse: if those web components depend transitively on other web components that pull in yet more frameworks), then I now have to deal with all of those different frameworks. Each of them will load more bytes and make my page's startup time slower. Each of them will have their own state management systems. Each of them will have their own approach to templating. Each of them will behave subtly differently in practice.

Why bother when I can just write everything in a single framework?

Re: Plain Vanilla Web

#246

Post by cmonBro22 »

hdjrudni wrote: post #93
cmonBro22 wrote: post #68

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

...what is this simple compared to?

Re: Plain Vanilla Web

#247

Post by austin-cheney »

someothherguyy wrote: post #224
austin-cheney wrote: post #201

Earlier quoted context omitted.

They care about time and they absolutely do care. If your giant virtual DOM mess takes 10x longer to respond on every user interaction they will absolutely notice. It’s just the developers that don’t care because deviating from the framework puts their job at risk.

> 10x longer to respond 10x longer than what? > It’s just the developers that don’t care because deviating from the framework You realize that many major modern (and legacy) web frameworks started inside companies?

10x longer than not using that framework and yes, I do realize that.

Re: Plain Vanilla Web

#248

Post by cmonBro22 »

someothherguyy wrote: post #229
rhet0rica wrote: post #150

Earlier quoted context omitted.

No-framework web tinkerer here. If I had a nickel for every second of my life I've spent typing document.getElementById, I'd be able to afford new fingers. Should've been renamed to getId() and put in global scope two decades ago, if not three. At least querySelector() is a few characters shorter, but I always feel bad using such an alarmingly overdesigned tool for anything trivial.

Why are you writing it so many times? Write an alias in 10 seconds? function getId(v) {return document.getElementById(v)} Dev tools allows $ $$, dunno, make a macro?

Sorry?

Re: Plain Vanilla Web

#249

Post by pests »

someothherguyy wrote: post #238
pests wrote: post #162

Earlier quoted context omitted.

You don’t have to call getElementById or querySelector on document. You can narrow the search by starting at a specific node, just most people default into document as it’s already a global.

> You don’t have to call getElementById or querySelector on document. You do have to call `getElementById` on a document. There can be many documents in a window.

Ah yes correct on getElementById, especially as every id must be unique.

Re: Plain Vanilla Web

#250

Post by andoando »

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…

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 25kb overhead and get a better, nicer looking, more well tested product that would take you to do in a week?

Post reply on HN