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

281–290 of 715 posts

Re: Plain Vanilla Web

#281

Post by lolinder »

littlecranky67 wrote: post #254
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've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code 100kb would never be a considerations for any of the apps I worked on (as a contractor in the corporate world). I mostly work in large teams, sometimes we had mulit-team monorepos with various line-of-buisness apps using React. 100kb are so completely irrelevant, as for LoB or B2B, no-one cares about the…

This is spot on. Load times do not matter for the kinds of apps that:

* Are exclusively loaded on high speed internet in corporate networks.

* Have a high hours-of-work-per-page-load count.

* Update infrequently.

We're engineers, or at least we like to call ourselves that. Engineering is the process of gathering requirements and building a system that meets those requirements on time and under budget. If your requirements include being able to serve users on 3G networks or users who only load your site in order to read a single piece of content per day, yeah, optimize your load times. But don't attack other engineers for failing to live up to your app's requirements.

Re: Plain Vanilla Web

#282

Post by [deleted] »

someothherguyy wrote: post #229
rhet0rica wrote: post #150

Earlier quoted context omitted.

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?

[deleted]

Re: Plain Vanilla Web

#283

Post by kmoser »

ArinaS wrote: post #45

I wouldn't call a website automatically loading 7 scripts on your single visit "vanilla web" though.

Why? The first line of the site explains:

> An explainer for doing web development using only vanilla techniques. No tools, no frameworks — just HTML, CSS, and JavaScript.

You're thinking of a lightweight site, which this isn't claiming to be.

Re: Plain Vanilla Web

#284

Post by emseetech »

sanderjd wrote: post #277
emseetech wrote: post #191

Earlier quoted context omitted.

Not just some people. There are a wildly unnecessary amount of marketing pages and pages with basic forms that are built using React. Every time I've been at a company and suggested moving to vanilla css+html or a static generator, the reaction is like I brought up rewriting in assembly. There needs to be a significant push for simplification of the default toolchain. I understand using React, but reaching for it by…

There is significant path dependency in either direction. A sibling comment to yours described it very well. There really isn't a good substitute for understanding early on whether you're going to be making a website or an application.

Until you have a definitive answer, err on the side of simplicity.

Re: Plain Vanilla Web

#285

Post by worldhistory »

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…

what? that is impossible

Re: Plain Vanilla Web

#286

Post by aucisson_masque »

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…

> how your frameworkless design handles a dozen different features that their use case absolutely requires

Would you mind sharing one or two kind of feature that are required by these development team ?

Re: Plain Vanilla Web

#287

Post by lerp-io »

"However, this rich functionality comes at the cost of framework and tooling complexity" this makes not sense, can someone explain how doing stuff in raw DOM is less complex than using react that is doing stuff for you?

Re: Plain Vanilla Web

#288

Post by Swizec »

sanderjd wrote: post #274
Swizec wrote: post #192

Earlier quoted context omitted.

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…

Nailed it. And a lot of people who say "this sounds like an application, let's pick an application framework to use" from the start are people who have experienced what you're currently experiencing. But it's very hard to describe in a compelling way to someone who has never had the same experience.

Oh I was hired because I’ve been here before and know what to do. It’s fast becoming a career specialty lol

Re: Plain Vanilla Web

#289

Post by kybernetikos »

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…

> On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+.

Photopea is a full-featured web app, not website, written without frameworks by a single individual. It is absolutely possible to build feature rich applications without the framework du jour.

Re: Plain Vanilla Web

#290

Post by intalentive »

lerp-io wrote: post #287

"However, this rich functionality comes at the cost of framework and tooling complexity" this makes not sense, can someone explain how doing stuff in raw DOM is less complex than using react that is doing stuff for you?

It’s less complex in the sense that you only need an editor and a browser. You don’t need to install npm or Vite.
Post reply on HN