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

171–180 of 715 posts

Re: Plain Vanilla Web

#171

Post by mikebelanger »

MrJohz wrote: post #161
spankalee wrote: post #137

Earlier quoted context omitted.

What would you expect that to do, in any framework?

In React, say, I might write and expect the worker instance to be passed as an object to `MyComponent` as a prop. But with webcomponents, I can't do something like that. this.innerHTML = ` ` will just stringify the worker and pass that string to the `my-component`. To get the worker instance to be passed correctly, I'd need to do something like this.innerHTML = ` ` this.firstChild.worker = worker;

So this isn't even a question about web workers, it's a question about how to prop-drill non-string/number data through multiple layers of web-components.

Tbh, I'm not sure there's a way for that. But why not just define a method in your target child component and pass the worker in there?

Re: Plain Vanilla Web

#172

Post by hanlonsrazor »

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, and the timeliness of that development is what frameworks empower orgs to deliver at much lower cost in the present and future, vs. vanilla web dev.

Re: Plain Vanilla Web

#173

Post by lolinder »

dorfsmay wrote: post #168
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…

On the third hand, some people use React and some framework to write static web page...

And if you can point me to an example of that I will happily lampoon them.

If we're talking about Medium, then yes, Medium is a complete disaster zone that should not be emulated anywhere. Their reader-facing use case does not require JavaScript at all except as a light optional seasoning on top.

All I'm saying is that we need to actually talk about use cases whenever we're talking about frameworks, which we almost never do. Failing to specify the use cases turns the conversation incoherent because we end up having two different conversations without even realizing it.

Re: Plain Vanilla Web

#174

Post by jemmyw »

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…

Nice site, I found some interesting stories.

I do find it a little annoying that when we have these discussions about vanilla vs frameworks people hold up an example and I go there and see a news site of articles rather than a complex application, and I think to myself yeah I wouldn't have used a framework in this situation anyway. It's annoying from 2 directions: the first that people ARE using frameworks for sites that shouldn't have ever had them in the first place, and I can bring to mind a couple of news sites I visit regularly where this is obviously the case because of the silly ways they work. Secondly that this is then held up as an example, because most of my work is on very interactive sites so I end up thinking well yeah but that's not going to work for me is it. My feeling is that I could do vanilla but would end up with something like a site specific framework.

My current approach is to use a framework and consistent patterns but to try and use as few other dependencies as possible.

Re: Plain Vanilla Web

#175

Post by insin »

rhet0rica wrote: post #150
hdjrudni wrote: post #93

Earlier quoted context omitted.

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.

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.

If I'm just adding sprinkles of interactivity to a statically-rendered page for something that vanilla is good enough for (i.e. minimal-to-no display logic), I use the expando giving an element an `id` adds to `window`:

    
    Copy
    
    copyButton.addEventListener('click', () => {
      navigator.clipboard.writeText(userNotes.value)
      copyButton.innerText = 'Copied'
      setTimeout(() => copyButton.innerText = 'Copy', 1000)
    })

Re: Plain Vanilla Web

#176

Post by MrJohz »

evantbyrne wrote: post #157
hdjrudni wrote: post #108

Earlier quoted context omitted.

C'mon. Even something simple like a date picker. Where are you going to store which month you're looking at? There's state everywhere, and we should not be sending it all back and forth to the server.

Date pickers aren't simple. I would challenge you to explain why you couldn't just store it in a variable or on the element itself.

Could you explain what you mean by "storing it in a variable"? It's perfectly fine to store data in a variable (that's what most frameworks do in the end), but that state needs to be reactive in some way — updating that state needs to trigger the necessary UI changes (and ideally in such a way that the entire component isn't being regenerated every time the state changes). This is what makes state management so hard.

Re: Plain Vanilla Web

#178

Post by whstl »

listenallyall wrote: post #70
panstromek wrote: post #54

Earlier quoted context omitted.

Might be a bit of a selection bias though. I certainly remember a lot of crappy MPAs before SPAs got big. The crappines just moved to SPAs as they became mainstream. Overall I agree that MPAs are better default, though, good SPAs are hard to build.

Part of the complaints about MPAs originally was that navigating all the different pages was slow, because loading new pages was slow. But plenty of today's SPAs deliver content even slower and the user is staring at a spinner for lengthy stretches. The key is quick, efficient server responses, whether using SPA or MPA approaches.

Yeah. In theory SPAs should be faster, but in practice rendering/sending the whole template is not as bad. And as you mention, both can be slow, due to the non-cached API/DB call, so...

Re: Plain Vanilla Web

#179

Post by alwillis »

deepsun wrote: post #112

> Styling. The problem I found is that my full-SSR project doesn't use any Node.js at all, and it works fine for everything but CSS, because in order to use includes and variables I need a CSS compiler. For example, I use a CSS library that defines a very nice style class "alib-link" for all links. I would want to set it for all elements, without adding `class="alib-link"` all the time. It's easy with a CSS-preprocrs…

> I would want to set it for all elements, without adding `class="alib-link"` all the time.

    a {
       /* the code from the alib-link class */
    }
If you need to style anchor links depending on where they point to, you could use an attribute selector:

    a[href*="news.ycombinator.com"] {
       /* more css */
    }
No preprocessing necessary.

Re: Plain Vanilla Web

#180

Post by MrJohz »

mikebelanger wrote: post #171
MrJohz wrote: post #161

Earlier quoted context omitted.

In React, say, I might write and expect the worker instance to be passed as an object to `MyComponent` as a prop. But with webcomponents, I can't do something like that. this.innerHTML = ` ` will just stringify the worker and pass that string to the `my-component`. To get the worker instance to be passed correctly, I'd need to do something like this.innerHTML = ` ` this.firstChild.worker = worker;

So this isn't even a question about web workers, it's a question about how to prop-drill non-string/number data through multiple layers of web-components. Tbh, I'm not sure there's a way for that. But why not just define a method in your target child component and pass the worker in there?

Yeah, I think the original question was a bit weirdly worded which made people focus on web workers rather than complex data in general.

You can use properties (as opposed to attributes) as I demonstrated, and you can use methods like you suggest, but these are both verbose and limited, and add an extra "the component has been created but the props haven't been fully passed" state to the component you're writing. Imagine a component with maybe five different props, all of which are complex objects that need to be passed by property. That's a lot of boilerplate to work with.

Post reply on HN