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

671–680 of 715 posts

Re: Plain Vanilla Web

#671

Post by listenallyall »

panstromek wrote: post #486
listenallyall wrote: post #70

Earlier quoted context omitted.

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

great article!

Re: Plain Vanilla Web

#672

Post by AdieuToLogic »

immibis wrote: post #628
AdieuToLogic wrote: post #436

Earlier quoted context omitted.

> Having a website just isn't necessary for some of the day-to-day operations vs just sending CSV/Excel files back and forth for reconciliation, settlement, accounting purposes. This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support.

It kind of does. You still have all the same backend logic, but now it doesn't have to run concurrently with a user interface. You can take a queue of operations, process operations off the queue and send their results back. Isn't that a pretty reasonable way for a system to behave? More than a few systems do this internally, with some kind of central message queue.

>>> Having a website just isn't necessary for some of the day-to-day operations vs just sending CSV/Excel files back and forth for reconciliation, settlement, accounting purposes.

>> This doesn't end well when there are hundreds of thousands of "reconciliation, settlement, accounting purposes" to support.

> It kind of does. You still have all the same backend logic, but now it doesn't have to run concurrently with a user interface.

Problem is, there is no self-administration capability when a feed file is the sole transaction mechanism. This can work when the volume is relatively small, say a few dozen customers, or if the Merchant is known to be sophisticated enough.

> You can take a queue of operations, process operations off the queue and send their results back. Isn't that a pretty reasonable way for a system to behave?

Not when there are capability requirements beyond batch processing, such as independent transaction research and/or manual corrections. Both are very common needs with Merchants lacking a dedicated system development department.

EDIT:

Consider a local bar or food truck which accepts credit/debit/gift card payments.

Even if they use host capture and a canonical credit card terminal, the Merchant will certainly want to reconcile their receipts with the end-of-day settlement.

This is not functionality "CSV/Excel" files and batch processing interfaces can provide.

Re: Plain Vanilla Web

#673

Post by nswest23 »

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…

this is a troll, right?

Re: Plain Vanilla Web

#675

Post by lmm »

_heimdall wrote: post #660
lmm wrote: post #609

Earlier quoted context omitted.

It doesn't necessarily need to be Turing complete, but CSS in its current form is harder to understand, debug or make sense of than most Turing-complete languages.

Do you mean because of how its designed to cascade, and all the details of priority that requires? Or something else? Personally I've never found the language itself hard to understand other than issues where a style somewhere else bleeds in and I have to hope browser dev tools can point me in the right direction.

> Do you mean because of how its designed to cascade, and all the details of priority that requires? Or something else?

Mainly that. But there are other parts that feel clunkier than they need to be too, e.g. media queries force you to repeat yourself a lot when most of the time you just want to write an expression, before/after gives you a whole new way to write elements that's only used for this one niche thing. The language has these weirdly powerful individual features but weak general features and no overall cohesion.

> issues where a style somewhere else bleeds in and I have to hope browser dev tools can point me in the right direction.

The converse part is even worse IMO. There's no way to do any kind of "find usages", so you can never tell whether a given style is used or not. With the result that people never refactor or delete anything, and the codebase gets worse and worse.

Re: Plain Vanilla Web

#677

Post by okaram »

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's so many different people, and it's hard to know if that's made you lose customers.

I would immediately discard any website that makes me send an email to order.

Re: Plain Vanilla Web

#678

Post by ern »

doc_manhat wrote: post #6

Question - why would you do this in current year ? Is it that much more performant? I might be ignorant but frameworks seem to be the lingua franca for a reason - they make your life much easier to manage once set up!

Frameworks can help in many cases, especially for complex or high-scale apps. But in simple CRUD apps, particularly in consulting environments, they often add more complexity than value.

I've seen this play out repeatedly. A company needs a basic CRUD system. Consultancy A brings in designers who produce “wireframes” (usually full-featured eye candy) and UX-centric “journeys.” To justify its bloated fees, the consultancy builds something super-slick using frameworks to match the designs. But once the budget runs out, the customer struggles to maintain it. Eventually, the app becomes unmanageable.

So the consultancy sends in a designer again to produce new mockups and “journeys.” The cycle repeats, this time with another framework.

Re: Plain Vanilla Web

#679

Post by owebmaster »

edoceo wrote: post #62
jjcm wrote: post #36

A solid overview with some great tips. One recommendation is to change the mental model here. In my eyes it isn’t “don’t use a framework”, it’s “build the framework you need”. It’s tremendously easy to set up an extension of HTMLElement that has 90% of the functionality you’d want out of react. My SPA non.io is built like this - one master component that has class functions I want, and one script for generic function…

Get the first 90% easy, the next 90% is much harder.

so hard that React is still working on that final 90% after 10 years with 90% more to go now that they think a compiler is the solution for the current mess.

Re: Plain Vanilla Web

#680

Post by owebmaster »

pajamasam wrote: post #64
phoronixrly wrote: post #52

Man, the example web components seem to work great if you wish to hide data from scraping and search indexing... And if you try to work around this, you end up with something very very similar to https://stimulus.hotwired.dev/ .

> the example web components seem to work great if you wish to hide data from scraping and search indexing Interesting. Why do web components have this effect, but some JS frameworks apparently do not? Or do they all?

ShadowDOM makes it quite difficult to parse the whole document as one thing as each ShadowDOM is traversed separately
Post reply on HN