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

631–640 of 715 posts

Re: Plain Vanilla Web

#631

Post by mixmastamyk »

Swizec wrote: post #192
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…

I work on a site that was built without frameworks with just a sprinkle of jQuery on top of a traditional MVC framework. It worked great but then the business grew and the software became bigger than what fits in 1 engineer’s head. We now have lots of issues that need fixing. A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 secon…

I’d approach this with a wizard-style (step by step) interface and transactions—orthogonal to JS framework.

Re: Plain Vanilla Web

#632

Post by tomgp »

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.

They were resource intensive (though probably less so than yr average React based site these days) but Flash, especially post AS3, was an order of magnitude or two faster than JS + html/svg/canvas at the time. It was years after the death of Flash that standards based tech finally caught up.

Re: Plain Vanilla Web

#633

Post by claytongulick »

andoando wrote: post #342
claytongulick wrote: post #279

Earlier quoted context omitted.

Increasingly, this is actually an argument in favor of vanilla web components. The WC ecosystem has grown a lot, and one of the great things about native web components is that they can be consumed by most major frameworks at this point. There are also many mature component sets you can pick from, like shoelace, etc... you can mix and match components from different offerings, something that's not practical with Reac…

If you use a bunch of libraries for routing, UI, authentication, the only thing thats left is the rendering. And quite frankly I don't see why Id want to reinvent the wheel there. {#each notes as note} {note.content} {/each is exactly what Id want to implement for example if I were writing JS functionality to render a collection. And Svelte for example doesnt restrict you from using vanilla JS whenever you want eithe…

It's not reinventing the wheel, it's more like not putting snow chains on your wheel when it's summer.

Re: Plain Vanilla Web

#634

Post by klabb3 »

_heimdall wrote: post #548
klabb3 wrote: post #304

Earlier quoted context omitted.

> But if I'm being honest post query selector frameworks don't have a strong cost benefit argument To me the killer app in the modern world is reactivity, ie making views that update in response to changes in the data model. To manually create listeners and do differential updates, and manage removal and teardown of event listeners etc, is akin to doing manual memory management. We used to do that with jquery sometim…

Reactivity features are helpful, but in my opinion they're only helpful in a problem that largely shouldn't exist. For a vast majority of websites out there state largely lives on the server. Reactivity is only helpful when the state reacted to is client side, and for that most sites that's only going to happen when we decide to keep a duplicate copy of state in the client rather than rendering on the back end where…

Yes and for those cases it’s kind of already solved decently like with htmx or just plain old forms and post requests. I think those old ways are underrated.

But, for a chat app it isn’t gonna cut it. Or a collaborative app, where changes need to be pushed to the client. Or maps, or similar. Or anything which needs offline working. (I’m working on a desktop app where majority of state is owned by and lives on the client.)

TLDR I agree for passive web pages but the web is often more than that, many times for good reason.

Re: Plain Vanilla Web

#635

Post by lolinder »

evantbyrne wrote: post #617
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…

> I think that this comment is a great example of the total disconnect these conversations always have. If we're being fair, the same could be said of this comment, which goes on to make some assumptions. One guy giving an anecdote that is not a web app does not prove much. I've built award winning web apps with progressive enhancement. It takes less code, less time, the performance is better, and they can be just as…

I think you're reading into my comment implications that I didn't intend to put there. The point is that situations differ and we need to be explicit about what kinds of situations we're talking about when we're sharing our opinions on the suitability of frameworks. I'm not advocating for or against frameworks in any particular situation.

Re: Plain Vanilla Web

#636

Post by kingbob000 »

As I work on personal projects I often have this internal battle: "Do I really need to use react for this small project? Doesn't this make it more bloated than it needs to be?" ...and then I create a vite react app and get up and running quickly while I still have the inspiration for the idea. There's something to be said for having an opinionated framework that just removes a large amount of extraneous decisions that can slow progress. I want a lightweight page but that is secondary to just wanting the thing I'm trying to make.

Re: Plain Vanilla Web

#637

Post by heyheyhouhou »

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…

Just wanted to say that I really like restofworld.org. Thanks to you and your team for building it.

Re: Plain Vanilla Web

#638

Post by TimTheTinker »

chenster wrote: post #379
braden-lk wrote: post #4

Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pretty tedious in vanilla, though!

Microsoft solved this with VIEWSTATE in ASP.NET it's perfect, then industry went with everything Ajax and other over engineered frameworks.

You don't know how much easier it was at that time (at least for web developers with little prior ASP experience) to:

- write a simple web service in C# on top of ASP.NET MVC v1

- build a web frontend on top of it using Prototype.js (or jQuery) and a library of components like ExtJS

Re: Plain Vanilla Web

#639

Post by TimTheTinker »

klaushougesen1 wrote: post #491

Personally have had great experience in high throughput, complex paas / saas webapps by rigourously only adding things when it was clearly needed. Recommend you try to start with webcomponents + a well thought out design system -> move on from there and you're pretty sure to have a solid base from which you can always add react, lit, vue or whatever else cooks your noodle. the other way around is near impossible

Yeah, vanilla HTML is a difficult approach when a corporate design system and component library is thrown into the mix of requirements.

From where I sit, Lit looks like one of the best ways forward. Here's an awesome design system someone built using Lit: https://nordhealth.design/

Re: Plain Vanilla Web

#640

Post by evantbyrne »

lolinder wrote: post #635
evantbyrne wrote: post #617

Earlier quoted context omitted.

> I think that this comment is a great example of the total disconnect these conversations always have. If we're being fair, the same could be said of this comment, which goes on to make some assumptions. One guy giving an anecdote that is not a web app does not prove much. I've built award winning web apps with progressive enhancement. It takes less code, less time, the performance is better, and they can be just as…

I think you're reading into my comment implications that I didn't intend to put there. The point is that situations differ and we need to be explicit about what kinds of situations we're talking about when we're sharing our opinions on the suitability of frameworks. I'm not advocating for or against frameworks in any particular situation.

That seems like a good take to me
Post reply on HN