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

441–450 of 715 posts

Re: Plain Vanilla Web

#441

Post by Aurornis »

bob1029 wrote: post #389
AdieuToLogic wrote: post #382

Earlier quoted context omitted.

> 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. Enabling customer self administration/configuration of a "B2B SaaS" system mandates some form of interaction. I would be surprised at how many would not expect "touching a browser" to do so. > A vas…

> In short, while letting customers send Excel files "and then load+merge their results directly into the same SQL tables" might sound nice, this does not scale and will certainly result in a failure state at some point. Much of US banking operates almost entirely on this premise and has done so forever. > error detection/reporting, business workflows, and/or role-based access control. I'd take a look at the Nacha (A…

> Much of US banking operates almost entirely on this premise and has done so forever.

Not literally. Banks have a lot of automations. The reasons they’re not real-time has more to do with various regulations and technicalities of recourse, not because it’s someone doing semi-manual processing of everything at each bank.

Re: Plain Vanilla Web

#442

Post by Jaygles »

pests wrote: post #249
someothherguyy wrote: post #238

Earlier quoted context omitted.

> You don’t have to call getElementById or querySelector on document. You do have to call `getElementById` on a document. There can be many documents in a window.

Ah yes correct on getElementById, especially as every id must be unique.

> especially as every id must be unique.

Although a very consistent convention, there are no guardrails put in place to prevent something from setting the same id on two or more elements.

getElementById will return the first element that it finds with the id, but you can't know for sure if it is the only one without additional checks

Re: Plain Vanilla Web

#443

Post by patrickmcnamara »

hliyan wrote: post #439
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…

I think of something similar every time I use the Uber Eats 'track order' screen. All I need is a simple textual history: 7:40 - Bob was delayed by 5 minutes. ETA 7.45 7:35 - Bob is heading your way. ETA 7:40 7:20 - Bob has picked up your order from Pizza place

Having a live location of the delivery person makes total sense here though.

Re: Plain Vanilla Web

#444

Post by moron4hire »

The section on Web Components is... teeechnically correct. Unfortunately, it's missing a lot of information on hidden pitfalls of doing things in certain ways

As an example, the examples on `connectedCallback()` don't guard against the fact that this callback gets called every time the element gets inserted into the DOM tree. This could happen because you've removed it to hide it and then added it later to show it again, or it could happen because you've moved it to a new location in the tree (different parent, or re-ordering with respect to its siblings). Or maybe you're not manipulating this object at all! Maybe someone else is moving around a parent element of your custom element. Whatever the case, if you're element's ancestor path in any way gets disconnected and then reconnected from `documentElement`, `connectedCallback()` gets called again.

That means that you have to spend extra effort to make sure anything you do in `connectedCallback()` either gets completely undone in `disconnectedCallback()`, or has some way of checking to make sure it doesn't redo work that has already been done.

There are some other pitfalls involving attributes, child elements, styling, behavior with bundling, etc., that they never really get into. And generally speaking, you're probably only going to find out about them from experience. I don't think I've seen anywhere that goes into Web Component best practices.

Which is a shame, because they are incredibly powerful and I enjoy using them quite a bit. Now that my company has decided to go all in on React, I think they've only really seen the beginner path on both. Web Components as a beginner look harder than React as a beginner. Once you start actually building apps, I find they actually end up having to do largely the same level of manual shenanigans. But I find that I'm doing manual shenanigans to work around React, whereas with Web Components there isn't any magic to work around, but there also isn't a lot of "help" that you'd end up ignoring in most cases anyway.

Re: Plain Vanilla Web

#445

Post by cortesoft »

bradly wrote: post #340
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…

I sell urns online and my website just has an email link. No shopping cart. A brick-and-mortor urn shop would never have a shopping cart, so why would a virtual one? I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to. There are so many way to do commerce both on and offline…

> There are so many way to do commerce both on and offline and if you squint and look closely you'll find interesting people doing interesting things all around you.

Why do I want "interesting" ways to buy things? I want to be able to buy what I want quickly and reliably. I don't get the benefit of making me try to figure out how to buy something I want

Re: Plain Vanilla Web

#446

Post by beezlewax »

jonathanlb wrote: post #424
lerp-io wrote: post #422

Earlier quoted context omitted.

no no no.....what you people really need is just an ai chatbot that simply generates your crud app/interface/store/whatever on the fly, so you don't even need excel or anything at all and the internet is just one big open vector database big brain. b2b, saas, excel, admin roles?? haha whats that?? and then we just relax outside in the grass hugging trees and smoking pot or whatever like in the 80s.

Weirdly this is something similar to what Satya Nadella said. > Yeah, I mean, it’s a it’s a very, very, very important question, the SaaS applications, or biz apps. So let me just speak of our own dynamics. The approach at least we’re taking is, I think, the notion that business applications exist, that’s probably where they’ll all collapse, right in the agent era, because if you think about it, right, they are essen…

Except this is pure fantasy and AI is uniquely unreliable and error prone.

Re: Plain Vanilla Web

#447

Post by bbkane »

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…

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 colleagues also use this daily).

Re: Plain Vanilla Web

#448

Post by Swizec »

zelphirkalt wrote: post #387
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…

I think I will never understand, how people write their code in such a messy unorganized way, that it becomes unclear, whether touching some piece of code changes the behavior on 50 other pages. To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file. Especially for websites, the…

> To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file

Yes and that’s normal. Big ball of mud is the worlds most popular software architecture.

Original: http://www.laputan.org/mud/

My modern take based on the original: https://swizec.com/blog/big-ball-of-mud-the-worlds-most-popu...

> Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu

MVC frameworks, used traditionally, don’t support this super well. If you want some dynamic value in the menu supplied by the backend, every view has to make sure it passes that value into the template layer. Change the menu, gotta go around changing every view to supply that new value.

Re: Plain Vanilla Web

#449

Post by Joeri »

gcau wrote: post #359

If you do this with no build step, how can you have cache busting of your component files? or is there an alternative solution that doesn't sacrifice on performance (but also doesn't serve stale files or an inconsistent version between files)?

There’s an article explaining the options on the blog section: https://plainvanillaweb.com/blog/articles/2024-12-16-caching...

Re: Plain Vanilla Web

#450

Post by creata »

MrJohz wrote: post #253
evantbyrne wrote: post #231

Earlier quoted context omitted.

This is a comical misrepresentation of reality. The actual reason people switched to React was because it was what Facebook was doing and they wanted to imitate one of the wealthiest companies to ever exist, not because the masses had problems with rendering form widgets. This problem was solved twenty years ago. Perhaps the worst part about this slander is that benchmarks have actually shown time and again that vani…

Of course vanilla JS is superior to any framework in terms of performance. Anything you can do in a framework, you can do directly in vanilla JS. But performance isn't the only issue here, otherwise we'd all be writing a lot more assembly code. I find your version of history amusing, because the first project that I migrated away from vanilla JS was actually to Angular, because the team found React's JSX syntax too w…

> at this point I wouldn't recommend React at all.

Out of curiosity, what would you recommend?

Post reply on HN