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

401–410 of 715 posts

Re: Plain Vanilla Web

#401

Post by [deleted] »

austin-cheney wrote: post #293
lerp-io wrote: post #287

"However, this rich functionality comes at the cost of framework and tooling complexity" this makes not sense, can someone explain how doing stuff in raw DOM is less complex than using react that is doing stuff for you?

Updating content in raw DOM methods is as direct as: 1. Get the desired node. 2. Write the content. That is it. The corresponding code is two lines. But but but... what about state? State is an entirely unrelated issue from writing content. State is also simple though. State is raw MVC plus storage. The way I do it is to have a single state object, the model. I update that model as necessary on user and/or network in…

[deleted]

Re: Plain Vanilla Web

#402

Post by lmm »

Yhippa wrote: post #399
lmm wrote: post #396

Earlier quoted context omitted.

Page refresh between pages is ok. Lag when updating a form based on your inputs isn't. Frontend UI is like a bigger monitor or faster PC - you may not have known what you were missing, but once you've experienced it it's very frustrating to go back to the clunky old thing.

> Lag when updating a form based on your inputs isn't. Why not?

> Why not?

It's really irritating for your users. They might not consciously be able to point it out as the cause of their irritation, but they'll like your app a lot less.

Re: Plain Vanilla Web

#403

Post by Aurornis »

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

> Email and flat files are far more flexible than any web solution.

Some times I feel like I’m taking crazy pills when I read HN lately. Suggesting that we e-mail requests around and have a person on the other end manually do things including merge data into SQL tables is such a bizarre claim to see. Every once in a while I encounter some business that operates like this and it’s inevitably a nightmare, either as a customer or a partner. Not to mention it’s ripe for everything from fraud to the company falling apart because the person who normally reads those e-mails and does the things for 20 years suddenly leaves one day.

This feels like a mix of rose-tinted glasses reminiscing about the old-timey way of doing things combined with a layer of career burnout that makes everything modern feel bad. Dealing with a business that operates this way is not good.

Re: Plain Vanilla Web

#404

Post by sanderjd »

emseetech wrote: post #368
sanderjd wrote: post #301

Earlier quoted context omitted.

You never have a definitive answer. It's always probabilistic. You make the decision that you think has the highest odds of success at every point in time.

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 hyperlinked webpages, and you often know that right away, even when you don't have many details sorted out at all.

Re: Plain Vanilla Web

#405

Post by zelphirkalt »

MyPasswordSucks wrote: post #111
c-linkage wrote: post #87

Earlier quoted context omitted.

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

Even the most friction-free ClickOnce deployment is going to be more of a deployment hassle than "hey, users, you know how you go to https://subdomain.local-intranet/place to add or subtract items from the inventory database? Well, continue doing that". The webapp doesn't care if someone's machine was down overnight or if the paranoid lady in design managed to install some local "antivirus" which blocked the updated…

Some people should probably only be given thin clients, because they are too inept to be allowed to handle anything else.

Not sure yet how to solve this problem on the Internet yet though. How can we prevent uninformed masses from creating incentives for businesses, that turn the web into a dystopia?

Re: Plain Vanilla Web

#406

Post by zelphirkalt »

kgeist wrote: post #271
c-linkage wrote: post #87

Earlier quoted context omitted.

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

We have 2 main products: a SaaS and a desktop app (1mln+ users combined). It's a pain in the ass to support the desktop app: - many people refuse to upgrade for various reasons so we have to support ancient versions (especially for important clients), for stuff like license activations etc. - various misconfigurations (or OS updates) on Windows can make the app suddenly crash and burn - and you waste time investigati…

You could of course also make your desktop app auto update without offering a way to refuse. Or you could make it display an error, if the user accesses it without being at the newest version, and block all further interaction. Those are considered impolite, but it seems you are doing it anyway in your web app already.

Re: Plain Vanilla Web

#407

Post by lerp-io »

austin-cheney wrote: post #316
insin wrote: post #311

Earlier quoted context omitted.

It is simple, and it very quickly becomes un-simple when it comes into contact with increasing app size/complexity (for things which _need_ to be apps, and which have to deal tasks where the size/complexity is essential due to factors which _can't_ be avoided, e.g. an app which deals with Workers' Comp, with laws and requirements which differ by U.S. state in ways which cut across the entire app) and team size/mix of…

Framework people always complain that simplicity doesn't scale. In my nearly 20 years of experience doing this I can firmly say they are entirely wrong. If an application increases in complexity as its features increase the way to restore order is a minor refactor. But really that isn't what this is about. Framework people were always falling back on this fail to scale argument even in the early days of jQuery. The r…

the tools are supposed to make u be able to make products faster and more efficiently and iterate faster on business requirements or whatever problem you are trying to solve. you are treating it like its some toy your supposed to fiddle with or something. there is a reason we aren't coding in binary and use functions to encapsulate and abstract away logic. these frameworks are supposed to provide boilerplate so that you don't have to go through the trouble yourself because somebody already solved it so you can be more productive and build on top.

getting a site up and running with vercel is like 20x faster and more simple than hardcoding .html files man.

Re: Plain Vanilla Web

#408

Post by gotaqmyfriends »

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…

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 not. It's a bit debatable but it makes sense.

Re: Plain Vanilla Web

#409

Post by reassess_blind »

busymom0 wrote: post #88
d_burfoot wrote: post #61

Note that you can make things even simpler than this: just use vanilla JS to compose HTML strings, and plug them into divs using innerHTML = "...". When your state changes due to user input, just rebuild the page using the new data. I've been building many simple apps using this technique, it works fine. I'm sure there is some kind of performance hit; it's almost never an issue. I have never seen any browser compatib…

Make sure to sanitize the content before inserting if you use this approach. > Warning: This is a security risk if the string to be inserted might contain potentially malicious content. When inserting user-supplied data you should always consider using a sanitizer library, in order to sanitize the content before it is inserted. https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...

Anything with user input I just use innerText.

Or a simple escapeHTML function within the innerHTML - but I prefer innerText in a separate pass, as using escapeHTML as a pattern gives an opportunity to forget to use it.

Re: Plain Vanilla Web

#410

Post by KPGv2 »

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.

I might be mistaken, but isn't banking famous for

(1) the long hours (i.e., processes suck), (2) the drudgery of updating said Excel files (i.e., processes suck) (3) horribly expensive to access (i.e., processes suck)

I have never once in my life as a corporate lawyer thought of banking as a model of operational efficiency.

Post reply on HN