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

221–230 of 715 posts

Re: Plain Vanilla Web

#221

Post by MrJohz »

spankalee wrote: post #207
MrJohz wrote: post #180

Earlier quoted context omitted.

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. Ima…

In what way are properties verbose and limited in your view? You can set them declaratively with a template binding in most template systems.

I showed earlier how it takes multiple lines and some fiddling with DOM to set a simple property with vanilla web components. Sure, if you're using a framework like lit, you have access to template binding, but at that point you might as well use an equivalent framework like SolidJS or Svelte which just skips the web component layer.

Re: Plain Vanilla Web

#222

Post by benatkin »

vaylian wrote: post #163
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…

Web components provide a clean abstraction boundary. You can add additional methods to your own tags which can encapsulate the logic for updating the data in the component.

They let you encapsulate the logic pretty much however you want, same as not using web components.

Re: Plain Vanilla Web

#223

Post by insin »

spankalee wrote: post #202
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;

With any web component you could assign the worker to a property, either imperatively: el.worker = worker Or declaratively: html` ` That's using lit-html syntax, but there are a lot of other rendering libraries that work similarly.

Every time I go back to give Web Components another 5 minutes, I hit this point where using lit or a lit-like would take a lot of the pain of the problems Web Components don't solve and have no planned solution for away.

But once I decide to cross the "no dependencies" line, using something like Preact + htm as a no-build solution would also take the most of the rest of the pain away, and solve many, many other problems Web Components have no solution and no planned solution for.

Re: Plain Vanilla Web

#224

Post by someothherguyy »

austin-cheney wrote: post #201
andrewstuart wrote: post #146

Earlier quoted context omitted.

No user cares about 100K.

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?

Re: Plain Vanilla Web

#225

Post by debugnik »

pjmlp wrote: post #182
debugnik wrote: post #152

Earlier quoted context omitted.

> Many desktop applications are written in .Net so you don't even need to install the runtime because it's preinstalled on the operating system. The last .NET version to be deployed this way has a 10 year old feature set. Nowadays you bundle the parts of .NET you need with the application.

You can still do system wide deployments with .NET Core, or .NET 5+, as you prefer to call it. https://learn.microsoft.com/en-us/dotnet/core/install/window...

Of course. I was strictly refering to .NET preinstalled in Windows as per the comment I replied to, which I believe only applies to Framework 4.8.

Although, on re-read, maybe they meant there's a good chance another application already installed it? This I wouldn't agree with, as applications often insist on installing different versions of the system-wide runtime, even for the same major version.

Re: Plain Vanilla Web

#226

Post by jonahx »

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…

This is the narrative, of course.

In practice, it is sometimes true, and often not.

You can't overstate how often decisions are large orgs are driven by hype, follow-the-herd, or "use popular framework X because I won't get in trouble if I do" mentalities. The added complexity of tools can easily swamp productivity gains, especially with no one tracking these effects. And despite being terrible decisions for the business, they can align with the incentives of individual decision makers and teams. So "people wouldn't do it if it wasn't a net positive" is not an argument that always holds.

Re: Plain Vanilla Web

#227

Post by troupo »

skrebbel wrote: post #120
troupo wrote: post #99

Earlier quoted context omitted.

> it sounds like my perception that Lit is mostly a convenient base class for Web Components is very incorrect. It has custom syntax, custom directives that look like regular JS functions but cannot be used like regular functions, a custom compiler in the works etc. etc. They will keep telling you it just a small library and very vanilla though.

And they're right! IMO Lit is a marvel of engineering. I think the goal they set themselves (make it easier to build an entire app out of web components) is silly, but given that goal, they hit a total homerun. It's fast, the compiler is very optional (not using it just means a bit more boilerplate around attributes etc - it's not like using React without a JSX compiler or something), lit-html is a genius alternative…

> lit-html is a genius alternative to virtual DOMs, etc

It's a haphazard solution that they now fight against with "directives" and even a custom compiler "for when initial render needs to be fast". It's not bad, but it's far from genius. And honestly, the only reason it works is that browsers have spent ungodly amounts of time optimizing working with strings and making innerHtml fast.

Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework.

As for "etc.", I don't even know what etc. stands for. lit is busy re-implementing all the things all other frameworks have had for years. Including signals, SSR etc.

Re: Plain Vanilla Web

#228

Post by sisve »

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…

100% this. The biggest problem I see is understanding the context of what you are building. Even inside a SaaS company. Are you building a feature that is a core part of the service or just a test shot to see if its possible to sell,or maybe you already sold something to a customer that is not your target customer. Yhey still need it and should get it. But maybe its more important to be quick and dirty. if its a core part, Then you need to make sure the architecture is good and maybe even add more test then normal. Context matter so much

Re: Plain Vanilla Web

#229

Post by someothherguyy »

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.

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?

Re: Plain Vanilla Web

#230

Post by coolcase »

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.

My experience circa. 2008/9 was it was fine (used it on a commercial app in lieu of good enough web standards for the featureset). It was fast and reactive for an app-like experience.

Games were made in flash so it can't be that slow.

Maybe slow for time to load. I think we got that down a bit and this wasn't to render content but a utility for a signed up user.

Post reply on HN