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

381–390 of 715 posts

Re: Plain Vanilla Web

#381

Post by eduction »

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…

> It would be nice if we could just … make it clear what kind of software we're talking about when we were opining

Irony here is that OP did precisely this with a link to the precise thing he built. Meanwhile you haven’t offered even a rough description of what you built, much less a link.

Re: Plain Vanilla Web

#382

Post by AdieuToLogic »

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'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 vast majority of the hours I've spent building web sites & applications has been devoted to administrative-style UI/UX wherein we are ultimately giving the admin a way to mutate fields in a database somewhere such that the application behaves to the customer's expectations.

If there is no validation of information given nor system rules enforcement, then I would question the correctness of said sites/applications.

> In many situations, it is clearly 100x faster/easier/less bullshit to send the business a template of the configuration (Excel files) and then load+merge their results directly into the same SQL tables.

This approach obviates the value added by a system enforcing core software engineering concepts such as fitness of purpose, error detection/reporting, business workflows, and/or role-based access control.

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.

Re: Plain Vanilla Web

#383

Post by numbsafari »

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…

As in urns for ashes, not Universal Resource Names.

Re: Plain Vanilla Web

#384

Post by deepriverfish »

my issue with doing web development without frameworks is how to best manage the app state. In react things like redux help with this, but in my experience state management becomes a mess without frameworks, maybe it's a skill issue on my side I don't know.

Re: Plain Vanilla Web

#385

Post by 90s_dev »

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…

> if you squint and look closely you'll find interesting people doing interesting things all around you

Yep :)

Re: Plain Vanilla Web

#387

Post by zelphirkalt »

Swizec wrote: post #192
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…

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 path to rendering a page should be pretty clear. Have some weird JS requiring menu functionality? Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu. Or yes, if you count the menu as part of those pages. Have some video player stuff? Well it is going to affect all pages where there is the video player. Something for forms? All pages where you have such forms. Then there are things like maybe animations or checkbox states. But I fail to come up with examples, where the scope of the change is so unclear, that one can't relatively quickly figure out what will be affected and what not. It must be some WordPress mess or something. Then I can imagine it. But with a site built from ground up? Nope, must be bad design or structure.

Of course you could just have made up that example as a straw man as well.

Re: Plain Vanilla Web

#388

Post by [deleted] »

andrewrn wrote: post #328
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…

I like this framing the most. My personal website is vanilla, and my SPA-like apps are with React. I originally chose vanilla for my personal website bc I thought it'd keep refreshing my fundamentals... but actually its simple enough that vanilla is actually just the correct choice.

[deleted]

Re: Plain Vanilla Web

#389

Post by bob1029 »

AdieuToLogic wrote: post #382
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'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 (ACH) operating rules if you have any doubt that sophisticated business workflows can be built on top of flat files and asynchronous transmission.

https://www.nacha.org/newrules

Post reply on HN