Live data from Hacker News

Plain Vanilla Web

plainvanillaweb.com

421–430 of 715 posts

Re: Plain Vanilla Web

#421

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.

I've had the same epiphany when I worked for a fintech startup that interacts with financial institutions. 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.

Re: Plain Vanilla Web

#422

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…

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.

Re: Plain Vanilla Web

#423
post #260

Earlier quoted context omitted.

We created a generation of developers that AIM to over-engineer requirements... and we also came up with extremely pervasive frameworks to go with it... My firm cannot hire people with no React experience... people REALLY only know how to build cruft these days...

As a Rails developer with no desire to work in a React codebase, I'm not qualified for about 50-60% of the Rails jobs postings. My lastest full time was at Shopify where I said over an over that I was Ruby only and not interested in a React position only to be told a few months in I needed to know React to get promoted. It is exhausting.

I have given up on doing frontend work for the time being, because of this crap. I used to do full stack with modern JS, TS, CSS, HTML and whatnot, but then someone made it all go to shit by advertising for NextJS and React, while there was zero interactivity on the whole platform, except for a couple of checkboxes. A few years later, there still isn't much. Some page transitions for when things happen in the backend. I told them in the beginning, that there is not much interactive stuff, but they all got flashed by some one minute low effort Material Design shit, and the idea of the whole thing being "modern" and hiring more React devs. So I stepped away from that while frontend part and let them dig their own hole.

Moving a navigation/menu from one app to another takes 3 people 2-3 weeks by now. Changing the "router" to update the TS version is just as time consuming. Things that would have taken 1 day max. take now 2-3 weeks. That is 1/14th of the productivity and people get paid for that, more than I did. Oh and did I mention the menu responsiveness was broken for months at a certain viewport width? I did report it, but apparently it was so hard to fix, that it could not be done in a quiet hour, so it took months laying around in the queue of things to fix.

Re: Plain Vanilla Web

#424

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…

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 essentially CRUD databases with a bunch of business logic. The business logic is all going to these agents, and these agents are going to be multi repo CRUD, right? So they’re not going to discriminate between what the back end is. They’re going to update multiple databases, and all the logic will be in the AI tier, so to speak. And once the AI tier becomes the place where all the logic is, then people will start replacing the back ends, right?

https://www.windowscentral.com/microsoft/hey-why-do-i-need-e...

Re: Plain Vanilla Web

#426
post #198

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…

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

I agree with Spolsky in theory. But in practice, I've been on one project in the last few decades which I actually think benefited from integrating a web framework. The majority of projects I've worked on absolutely did not need JavaScript, and the rest would have been served by an approach similar to what's described in the OP--a few minimal vanilla JS files to create a few web components.

And yet large teams of very smart people reach for NPM as just part of their initial setup process. It's so ubiquitous that I essentially had to learn to not write this way on my own, by asking myself "can I do this without JS"? Almost every time I asked that question, the answer was "yes", and the non-JS way was much easier. But for a long time I wondered if I was wrong--maybe the framework JS way is easier in some way I don't understand--because everyone around me was doing it the framework JS way. It's taken me years of experimentation to build up a preponderance of evidence to persuade myself that in fact, the framework JS way is just worse, most of the time.

Everybody wants to be Facebook or Google, but the fact is you probably just aren't. You probably don't have their problems and you probably don't need to use their tools.

Re: Plain Vanilla Web

#427
post #340

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…

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

People romanticize businesses like this but there’s a reason you’re not posting the link. It only works when it’s for a small group of people who are in the know and refer trusted buyers.

It’s also trivial to set up any number of different online purchase options that would avoid all of the problems with this for a nearly trivial fee.

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.

Re: Plain Vanilla Web

#428
post #178

Earlier quoted context omitted.

Yeah. In theory SPAs should be faster, but in practice rendering/sending the whole template is not as bad. And as you mention, both can be slow, due to the non-cached API/DB call, so...

Even in theory, producing json is just typically slower than producing HTML. It seems unintuitive, but traversing an object tree using reflection to generate json is just slower than using an HTML template, which is probably a rope data structure.

Rendering the template or JSON response is the last and probably often the least computationally expensive step though.

Re: Plain Vanilla Web

#429
post #340

Earlier quoted context omitted.

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…

How does the woodworking company ensure payment? Does the specialized nature ensure only "real" customers buy? Is there a trusted relationship? A threat of legal action? I know the other way around is basically the norm: how does one know the company, the seller, will actually provide the product after paying. But the prevailing culture, currently, is that companies in this regard are trustworthy and customers are no…

> How does the woodworking company ensure payment? Does the specialized nature ensure only "real" customers buy?

Yes, I believe it does. These are highly specific brass tacks for making oval shaker boxes. There are very few manufactures of a proper #2 brass tack these days, so I would very much want to stay on the good side and any suppliers.

I think they said in their faq that twice they haven't been paid in 20 years or something like that. Their online "store" appears to be down right now–hopefully they are still in business.

edit: It appears John passed in 2023 :( https://blog.lostartpress.com/2023/02/07/john-wilson-1939-20...

Re: Plain Vanilla Web

#430

I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.

The nice thing about the plain "vanilla" approach is it can be used to enhance a more traditional SSR-rendered site. And it doesn't need a complete rewrite in React or whatever. The author of this article blog is describing some more advanced SPA-like scenarios, but those are completely optional

React aficionados will disagree though, and tell you to move your logic into the React framework using code.
Post reply on HN