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

231–240 of 715 posts

Re: Plain Vanilla Web

#231

Post by evantbyrne »

MrJohz wrote: post #218
evantbyrne wrote: post #185

Earlier quoted context omitted.

Maybe I'll write a blog post on it someday. It depends on the exact method you use to build the calendar my man. You could just change classes and attributes. Or you could use a variable within the scope of where you initialize the component. I wouldn't re-render the whole thing to apply changes, but that's up to you. The nice thing about using vanilla APIs is you don't typically have to worry about thrashing the DOM…

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 vanilla JS is superior to React in terms of performance.

Re: Plain Vanilla Web

#232

Post by insin »

CharlesW wrote: post #74
skrebbel wrote: post #49

Earlier quoted context omitted.

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!

I do know what you specifically mean when you say that, but… _all_ libraries are leveraging native browser capabilities, even ones which implement a better component model than Web Components.

Re: Plain Vanilla Web

#234

Post by MrJohz »

spankalee wrote: post #213
MrJohz wrote: post #151

Earlier quoted context omitted.

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

It is absolutely a lie, because web components can handle arbitrary data just at much as any framework. You're holding web components to a higher standard here in expecting them to take arbitrary data in HTML when HTML itself doesn't support arbitrary data. Notably you can't assign arbitrary data to framework components from within HTML either, so how are web components any more limited?

The original comment was that "all HTML attrs must have string keys and values", which is completely true.

The point of web components is that they create normal HTML elements. So it makes sense to consider what the value of them being normal HTML elements is. You can write them directly in your HTML source code, for example. But if you do that, you only get access to attributes and not to properties, and therefore everything needs to be strings. Alternatively, you can treat them as DOM nodes in Javascript, at which point you get access to properties and can use non-string values, but now you've got to deal with the DOM API, which is verbose and imperative, and makes declarative templating difficult.

Yes, we could compare them to components from other frameworks, but that's honestly an absurd comparison. They're simply trying to do different things. Frameworks aren't trying to create HTML elements. They're trying to reactively template the DOM. It's just a completely different goal altogether. The comparison doesn't make sense.

Re: Plain Vanilla Web

#235

Post by cmonBro22 »

esseph wrote: post #113
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

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

yes, probably, even maybe

But what's the problem again?

Re: Plain Vanilla Web

#236

Post by codazoda »

hanlonsrazor wrote: post #172

Seems like this is more for the hobbyists - building webpages for the love of the act. Frameworks are built to be standardized, enforce best practices via their design, and allow developers to 'hit the ground running', so to speak. No web site is intrinsically valuable - the information and functionality it wraps is what holds its value. Developing the access to that information and function, enforcing correctness, a…

I see absolute messes created out of React and associated frameworks. Quite possibly because, “you’re holing it wrong”. Just using a framework is not going to force best practices and it’s very easy to create terribly bloated and slow systems with these tools if you’re not thoughtful.

Re: Plain Vanilla Web

#237

Post by esafak »

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.

How do you know? Are you surveying them, including the ones who noped out of your site?

Re: Plain Vanilla Web

#238

Post by someothherguyy »

pests wrote: post #162
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.

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.

Re: Plain Vanilla Web

#239

Post by donohoe »

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…

I think that this comment is a great example of the total disconnect these conversations always have.

I just pointed out that frameworks are not always necessary.

>> In this case: this is a WordPress blog.

No. It is not a "blog". It's a news site. It uses WP as a CMS. That does not make it a blog, and comes across as nothing more than an attempt to belittle it. The New Yorker, with its 90 year archive (at the time) was run on WP too for a time. Its used by many major publishers.

If you look at other news sites, be it NYTimes, Polygon, Verge, Wired, etc, most of them use frameworks to some degree. React, preact, svelte, whatever. It works for them. Underscore, and Backbone are two frameworks that were developed at the NYTimes. Its not alway necessary, and you can still do a lot without them.

Re: Plain Vanilla Web

#240

Post by coldtea »

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…

>that their use case absolutely requires

This is where those people and teams are wrong.

Post reply on HN