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

191–200 of 715 posts

Re: Plain Vanilla Web

#191

Post by emseetech »

dorfsmay wrote: post #168
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…

On the third hand, some people use React and some framework to write static web page...

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 default at the beginning should be seen as unnecessary complication.

Especially because it's 100x easier to move from html+css to a framework than it is to move from a framework to literally anything else.

Re: Plain Vanilla Web

#192

Post by Swizec »

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…

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 seconds to go through but there is no UI feedback so you press the button a few more times because maybe it didn’t work? Then you get an error because the first action worked but the subsequent actions failed due to uniqueness constraints. Now as a user you’re confused: did you place the order or not? You got an error but the order also showed up in your history. Hmmm

As engineers we have issues understanding what is and isn’t in scope. Will this javascript file you touched affect only the feature you wanted, or another 50 pages you didn’t even know about? When you add a new thing in a template, how many N+1 issues across how many pages did you just cause? Where does the data even get loaded?? The query lives so far away from where you use the data that it’s really hard to track down. Etc

We started putting new things in React, especially the more interactive areas of the site. It’s pretty nice in comparison. Not perfect, but the framework pushing you to think in components helps a lot. I’m slowly introducing this mentality to other parts but the framework really wants to fight you on it so it’s gonna take a while.

Re: Plain Vanilla Web

#193

Post by insin »

atoav wrote: post #100
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…

As a fellow vanilla-fan: If this shows anything, it shows how bloated modern web development has become. Your page is snappy as hell.

Modern static content web development is in some of the best health it's ever been in with the likes of Astro.

You get your lovely developer experience with components, with the same component API enabling layouts for the repeatable outer structure, easy composition of reusable parts of your content, ease of passing data around between these and implementing any logic you need before rendering or inside what you're rendering.

The user gets a snappy, static website.

Re: Plain Vanilla Web

#194

Post by Waterluvian »

RyanOD wrote: post #187

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!

That’s exactly what I do. The projects are small enough that it’s perfect. But it reminds me how insane it would be if it was one of my professional projects.

Re: Plain Vanilla Web

#195

Post by spankalee »

MrJohz wrote: post #170
spankalee wrote: post #141

Earlier quoted context omitted.

You absolutely can put properties in templates. Web component authors do this all the time. Here's a lit-html template that sets a property: html` `

That's not web components, though that's lit-html. That's an additional library you need to pull in to manage your web components. Which kind of ruins a lot of the stated benefits of web components. If I need a framework to write my web components, why not just pull in a different framework that skips the web component level completely and just outputs HTML/CSS directly? What is this intermediate step actually bringi…

How does using a library ruin the goals of the components at all?

The goal of web components is to enable interoperable, encapsulated, reusable components, where how they're built is an implementation detail.

You can use a web component that used lit-html without knowing anything about lit-html, it even that the component uses it.

Re: Plain Vanilla Web

#196

Post by bl_valance »

I've been recently going this route, everything is static. If I can't host them on an S3 bucket, then I'm building it wrong.

Sites are way too bloated nowadays, a lot of the content being served can be static and cached.

Re: Plain Vanilla Web

#197

Post by spankalee »

90s_dev wrote: post #165
spankalee wrote: post #141

Earlier quoted context omitted.

You absolutely can put properties in templates. Web component authors do this all the time. Here's a lit-html template that sets a property: html` `

At that point you're not using HTML anymore, you're just calling html() in a fancy way, and that's the whole point of the complaint, that custom-elements are not good at being plain HTML even though that's like its whole thing .

Being plain HTML is important for the user of the element.

That the element may use a library for its implementation is basically irrelevant.

Re: Plain Vanilla Web

#198

Post by a4isms »

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…

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; Games; and Throwaway. Shrink-wrap is no longer a thing for most developers, and we can probably name some others today that didn't exist then. But the basic advice he gave then matches what you're saying today:

We need to anchor arguments about tooling in a statement about the type of development we're trying to address, and we need to appreciate that the needs of each world are different.

Re: Plain Vanilla Web

#199

Post by dismalaf »

dorfsmay wrote: post #168
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…

On the third hand, some people use React and some framework to write static web page...

There's a shocking amount of people who don't know that vanilla JS is a thing... They only know React...

Re: Plain Vanilla Web

#200

Post by bluefirebrand »

pests wrote: post #159
MyPasswordSucks wrote: post #111

Earlier quoted context omitted.

Even the most friction-free ClickOnce deployment is going to be more of a deployment hassle than "hey, users, you know how you go to https://subdomain.local-intranet/place to add or subtract items from the inventory database? Well, continue doing that". The webapp doesn't care if someone's machine was down overnight or if the paranoid lady in design managed to install some local "antivirus" which blocked the updated…

The web browser is not some magic tool that is always guaranteed to work. Group policy alone can wreck total havoc on web apps on all the major browsers.

This would be noticed immediately when all of the workers under the group policy try to access their email in the morning
Post reply on HN