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

201–210 of 715 posts

Re: Plain Vanilla Web

#201

Post by austin-cheney »

andrewstuart wrote: post #146
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…

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.

Re: Plain Vanilla Web

#202

Post by spankalee »

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;

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.

Re: Plain Vanilla Web

#203

Post by benatkin »

hdjrudni wrote: post #108
evantbyrne wrote: post #72

Earlier quoted context omitted.

State should really only be kept at rest in the backend, form elements, and the occasional variable. SPA state management is fun to puzzle around with, but gives developers the false impression of productivity and is totally redundant to the browser's built-in capabilities for shuttling data back and forth to a server.

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.

One place to store it is in a data attribute.

Re: Plain Vanilla Web

#204

Post by knuckleheadsmif »

a99c43f2d565504 wrote: post #149
crystal_revenge wrote: post #119

Earlier quoted context omitted.

I'm also from the before times, and still think one of the major issues with all of this is that we've decided to build a global application ecosystem by hacking stuff on top of a document format . HTML was supposed to just a slight markup layer to make it easier to transit and render text documents, likewise that's all HTTP was designed for. The ratio of text-to-markup should be fairly high (I'm sure today it's less…

Are you implying there exists a better way of making UIs that just hasn't taken over the world for some reason? I also don't like the state of the web.

Yes, making UI’s is not a new problem but building on top of the DOM/HTML as the backbone is.

I too am from the before times where I guess we built essentially our own frameworks to handle own unique issues and take security into our own hands (verses have to trust external libraries and external resources….)

I sadly laugh when I hear 20+ years late people are still fighting back button navigation issues. I still see sites that can’t handle double posts correctly or recovery gracefully when post responses fail/timeout.

I’m out of the game now but for all the benefits of the web it’s been haves to death to support stuff the underlying infrastructure was nit designed for.

Re: Plain Vanilla Web

#205

Post by [deleted] »

aidos wrote: post #27
coolhand2120 wrote: post #23

Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely. I run sites that serve hundreds of millions per day a…

At 100s of millions I’m assuming you have something closer to a static site than an application?

[deleted]

Re: Plain Vanilla Web

#206

Post by ntnsndr »

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 love Rest of World! Great work!

Re: Plain Vanilla Web

#207

Post by spankalee »

MrJohz wrote: post #180
mikebelanger wrote: post #171

Earlier quoted context omitted.

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

Re: Plain Vanilla Web

#208

Post by sofixa »

coolcase wrote: post #131
smokel wrote: post #73

Earlier quoted context omitted.

As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly. The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology use…

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.

Re: Plain Vanilla Web

#209

Post by laurentlb »

sn0n wrote: post #58

I missed the part where they show how to do something similar to ejs or PHP HTML includes for things like header.html and footer.html.

That's how I wrote my website a long time ago.

  #include "header.htm"
  Title
  ...
  #include "footer.htm"
I'm still using it, and I wonder when I'll be able to get rid of PHP.

Re: Plain Vanilla Web

#210

Post by wim »

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…

We're building a collaborative IDE for tasks and notes [1] from scratch without frameworks/dependencies.

Not saying frameworks are never the right answer of course, but it's as much a trade-off for complex apps as it is for blogs. Things like performance, bundle size, tooling complexity, easy of debugging and call stack depth, API stability, risk of hitting hard-to-work-around constraints all matter at scale too.

[1] https://thymer.com/

Post reply on HN