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

481–490 of 715 posts

Re: Plain Vanilla Web

#481

Post by gampleman »

invaliduser wrote: post #454
bbkane wrote: post #447

Earlier quoted context omitted.

In fact, I've gone the opposite way- my work has an internal cafe with a menu website that takes a lot of clicks to see everything. I originally planned to scrape the data and make my own website with better (imo) controls, but v0 turned into pumping the data into a Google sheet. I've never needed v1. The Google sheets "UI" solves filtering (i.e., breakfast vs lunch), access control, and basic analytics (~7 other col…

I have a similar experience with providing users with excel files, but would also like to add that in a lot of business, the number 1 competition for a web application is the good old excel file (or its modern cloud version), and it's sometimes a challenge to beat.

Yeah, I've spent 2 years in a job trying to build a UI to beat an Excel file. Did not succeed.

Re: Plain Vanilla Web

#482

Post by zzo38computer »

sneak wrote: post #459

I’m tired of SPAs and webpages that don’t render without JavaScript. The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off. Now, web developers give you a blank page if you don’t run a megabyte of their shitty code. No thank you.

> The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off.

I agree. (This should also include CSS, TLS, cookies, and many other things; I often disable CSS, and it should work just as well if CSS is disabled just as much as if pictures or JavaScripts or cookies are disabled.)

However, there are some uses where JavaScripts may be helpful e.g. if a web page has a calculations or something like that implemented by JavaScripts; but that is not an excuse to prevent the documentation from being displayed if JavaScripts are disabled. They should really make documentation and as much other stuff to work even if JavaScripts are disabled (and, depending on what it does, may provide a description of the calculation or of the rules of the game being implemented, or a link to API documentation, or something else like that).

Pictures also might be useful in some articles (but are often overused); but even then, if the picture is not displayed you could use an external program to display them. However, if it can be explained in the text, then it should be explained in the text if possible so that even if you do not have a suitable program to display that picture (or do not want to display that picture, e.g. the file size is too big; or maybe you are using text to speech or a braille display or something else like that) then it will still work.

TLS also should not always be mandatory, either. For things that require user authentication, and for writing, it can be useful to be mandatory (especially if you are using X.509 client authentication; this will be better than using cookies or other methods for authentication, anyways); but for read-only access to public data, TLS should be optional (but the server should still allow it in case the client wants to use TLS for read-only access to public data too).

Re: Plain Vanilla Web

#483

Post by vaylian »

benatkin wrote: post #222
vaylian wrote: post #163

Earlier quoted context omitted.

Web components provide a clean abstraction boundary. You can add additional methods to your own tags which can encapsulate the logic for updating the data in the component.

They let you encapsulate the logic pretty much however you want, same as not using web components.

When you call document.querySelector("something") in the main HTML document, it will not find "something" inside the internal HTML of a web component.

Re: Plain Vanilla Web

#484

Post by Juliate »

Aurornis wrote: post #438
bradly wrote: post #433

Earlier quoted context omitted.

> People romanticize businesses like this but there’s a reason you’re not posting the link You are correct that I was a worried about an HN hug of orders for brass tacks. > I guess I’ve spent enough time dealing with things like non-payment or doing work for trades that never arrive that I just don’t romanticize this stuff any more. In this case there isn't much of a choice. When the last manufacture of brass tacks c…

> I understand your sentiment but it was perfectly normal to pump gas before paying in the U.S. for a very long time and still is in many places. I had a friend who worked at a gas station in high school. Filing police reports for people who filled up and left without paying was a standard part of operations. This was in a nice area, too. Often people just forgot and drove away. They had recourse because they had sec…

> You can’t have a pay-later business without an amount of non-payment, which has to be compensated by higher prices (which other customers shoulder).

People who never experienced high-trust and customs societies cannot grasp why and how it works infinitely better than low-trust ones.

But granted, all it takes is a few determined bad faith actors to break high-trust, when they are not vehemently and swiftly rejected…

Re: Plain Vanilla Web

#485

Post by hliyan »

Vinz_ wrote: post #464
hliyan wrote: post #451

Earlier quoted context omitted.

Why? What I would prefer is a "Notify me when the rider is [X] minutes away. Use ringtone [R]" feature. X is the time I need to go downstairs and open the gate. The customer need not have their brains cluttered with logistics details.

Because in a lot of cases, the driver isn’t in the correct place, and so if you have their location you can easily tell them how to get to you. I’ve had multiple deliveries where the Uber Eats app just could not tell the driver the correct location for my address, and I wouldn’t have been able to tell the driver how to get there by just them telling me where they were.

For that, I would propose a feature where I can mark the directions to my home from a well known checkpoint on a map, one time. If the rider deviates in the last mile, they get notification. If they continue to deviate, I get a notification. The solution is not for me not constantly monitor the rider's location.

Re: Plain Vanilla Web

#486

Post by panstromek »

listenallyall wrote: post #70
panstromek wrote: post #54

Earlier quoted context omitted.

Might be a bit of a selection bias though. I certainly remember a lot of crappy MPAs before SPAs got big. The crappines just moved to SPAs as they became mainstream. Overall I agree that MPAs are better default, though, good SPAs are hard to build.

Part of the complaints about MPAs originally was that navigating all the different pages was slow, because loading new pages was slow. But plenty of today's SPAs deliver content even slower and the user is staring at a spinner for lengthy stretches. The key is quick, efficient server responses, whether using SPA or MPA approaches.

Oh, totally. I myself have written on how GitHub manages to make client side navigation 2x slower than full page reload: https://yoyo-code.com/why-is-github-ui-getting-so-much-slowe...

Re: Plain Vanilla Web

#487

Post by larodi »

bob1029 wrote: post #291

I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?". I've discovered that when you start getting really cynical about the actual need for a web application - especially in B2B SaaS - you may become surprised at how far you can take the business without touching a browser. A vast majority of the hours I've spent building web sites & applications has been devoted to admini…

Lets first not forget: 1) people been doing business with these "ugly" green textmode screens, long before web; 2) the web existed in a very reasonable form pre-www as FIDO, GOPHER, and of course IRC & EMAIL.

The fact that this all got hyperlinked is a superb. convenient, but also a challenge from tech perspective, and what FAANG did in the 30 years to come (after 1992) led to this horror of entangled and super-complex technologies we have today. Even vanilla web is quite complex if you take into consideration all the W3 standardization.

Security or not, you can have an appliance run much simpler software given longer product lifetimes,... My only hope is now with llm-assisted coding this vanilla approach comes back, as the boilerplate pain becomes more bearable (how I really hated html at some point...). Besides, it is much more pleasant to prompt yourself a website, rather than try to position some image on stupid fb/insta pages/events, which is one major reason to step back and own your content again.

Re: Plain Vanilla Web

#488

Post by zarzavat »

emseetech wrote: post #191
dorfsmay wrote: post #168

Earlier quoted context omitted.

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…

Why not use React for that? If I use React for everything then I don’t have to decide, I don’t have to use two different tools. Consistency is fantastic, if you only use nails then you only need to carry a hammer.

Why use two incompatible languages (JSX and HTML) for different types of web pages, when you could just always use JSX? React can statically render to HTML if your page is really static.

I think what you’re really complaining about is that people use React for static content and don’t statically render it first. That is sloppy, I agree. But it’s not React itself that’s the problem but rather the developers who don’t care what they are doing.

Re: Plain Vanilla Web

#489

Post by littlecranky67 »

zelphirkalt wrote: post #337
littlecranky67 wrote: post #254

Earlier quoted context omitted.

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

That's assuming quite a few things though about the user's browser. Like cache not being cleared on shutdown. And on the project side, that there are not so many changes, that need to be received by the user agent now, instead of whenever the cache expires. That updates can be applied later on the user side. Of course when updates only happen every few weeks, then it might work... but only if that cache is not delete…

It is NOT a big if, because by default, caches are not deleted on shutdown. Plus, in a corporate environment, the windows installations are centrally managed and won't be configure to do so. But coming back to the original argument: If there is no caching, your SSR is never going to be fast too.

Re: Plain Vanilla Web

#490

Post by xigoi »

sanderjd wrote: post #404
emseetech wrote: post #368

Earlier quoted context omitted.

Success for the current requirements? Or success for an imagined future?

For an imagined future. If you're building something with specifications, then what are we even talking about? You know what you need to build so just build that. But this thread is about what to do when you don't know. "Start the simplest way" is not always the right answer, because you have some information about what you plan or want or hope to build, so you can use that information. Not everything is a set of hyp…

> A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work.

—John Gall

Post reply on HN