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

181–190 of 715 posts

Re: Plain Vanilla Web

#181

Post by eviks »

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…

Not sure if it's no-framework related, but navigation back/forth is sometimes broken: the url changes immediately, but the page doesn't update and stays on the same article.

Also infinite scroll breaks the most basic usability issue - you can't track where in the article you're with the scrollbar positioning

Re: Plain Vanilla Web

#182

Post by pjmlp »

debugnik wrote: post #152
c-linkage wrote: post #87

Earlier quoted context omitted.

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

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

Re: Plain Vanilla Web

#183

Post by Dwedit »

When you include "No tools" in your requirements, you're locking yourself out of WebAssembly. WebAssembly still requires that you have a C compiler that can target WebAssembly binary format. Zig works well as a compiler for this purpose, even if it's just building C code.

WebAssembly doesn't need to be bloated, I've written a C program that imports nothing, and the resulting WASM file is under 3KB in size, and there's under 10 lines of code to load it up.

Re: Plain Vanilla Web

#184

Post by atoav »

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…

Maybe there is this disconnect, but half of the react developers I personally met used react: "because it is good on resumes and I don't understand how to work without a framework". So I am not entirely sure we have the whole picture here.

I also write more complex webapps using vanilla webtech (with a strong server-side solution like flask, django or similar). I checked out react it just hasn't clicked yet for me in combination with my serverside style.

Re: Plain Vanilla Web

#185

Post by evantbyrne »

MrJohz wrote: post #176
evantbyrne wrote: post #157

Earlier quoted context omitted.

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.

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 with unnecessary renders because that's rarely (perhaps never?) the easiest way to patch changes to it, unlike in React where useMemo is prevalent.

Re: Plain Vanilla Web

#186

Post by mikebelanger »

pawelduda wrote: post #11

Other than for learning purposes or very lean projects, you'll de-framework yourself just so that you have to spend extra time rebuilding it instead of focusing on the essence of your project

I really wish web components weren't promoted as a "framework alternative" and more of a standardization of custom display components. Frameworks like enhance.dev and lit.dev are good examples of this.

Re: Plain Vanilla Web

#187

Post by RyanOD »

This is the approach I took for my side project website. The idea of installing a framework and dealing with hosting and whatnot just did not interest me.

More importantly, the needs of the site are drop-dead simple so no need to install a Ferrari when all I need is a bicycle.

Plain vanilla site served from Github FTW!

Re: Plain Vanilla Web

#188

Post by spankalee »

mmcnl wrote: post #44

This guide assumes web components is a viable alternative for frameworks like React or Vue. That's a very superficial assumption. React and Vue render the UI as declarative function of state, with the help of components. That's why we use those frameworks. Web components don't solve the state management problem.

Web components only solve the interoperable, encapsulated component problem.

Rendering libraries like Lit handle declarative templates, and there are many state management solutions, the same ones you can use with React, etc.

Re: Plain Vanilla Web

#189

Post by MrJohz »

CharlesW wrote: post #43
skrebbel wrote: post #22

I support the general idea here but just because something is in a browser doesn't mean it's a good formalism. Notably, Web Components. They're fantastic for distributing components - after all, a Web Component will work in every framework (even React, the IE of frameworks, finally added support), or even in vanilla HTML. So you can build a component once and everybody can use it. It's fantastic. But for internally c…

I haven't started using Web Components, but I was under the impression that libraries like Lit address most of the issues you mentioned for devs who don't want to write their own minimal base class, no?

Based on the JS Framework Benchmarks (so caveats apply), an app built with lit-html (i.e. just the HTML templating part, as I understand it) is about the same size as SolidJS, and an app built with lit (i.e. the full framework) is about the same size as Svelte or Preact, and at a similar order of magnitude to Vue or Mithril.

So at least in terms of minimal bases, all of these frameworks are much of a muchness.

Re: Plain Vanilla Web

#190

Post by austin-cheney »

lolinder wrote: post #173
dorfsmay wrote: post #168

Earlier quoted context omitted.

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

The primary use case for these large frameworks is hiring.
Post reply on HN