Live data from Hacker News

Plain Vanilla Web

plainvanillaweb.com

541–550 of 715 posts

Re: Plain Vanilla Web

#541
post #208

Earlier quoted context omitted.

Nothing wrong with Flash and Silverlight except each being controlled by a single company. I liked those technologies. Adobe Flex was very nice to program in and use for it's time.

Both were absurdly slow and resource intensive.

The flash player leaked memory. The longer-running the app, the more noticeable it was. I believe this is why Adobe Air (flash player packaged as deliverable) failed.

As for the speed of the flash player itself it was quite good.

Re: Plain Vanilla Web

#542
post #464

Earlier quoted context omitted.

Because in a lot of cases, the driver isn’t in the correct place, and so if you have their location you can easily tell them how to get to you. I’ve had multiple deliveries where the Uber Eats app just could not tell the driver the correct location for my address, and I wouldn’t have been able to tell the driver how to get there by just them telling me where they were.

> so if you have their location you can easily tell them how to get to you. So you work in logistics support, but you pay to do it?

Yes. I’m happy to do whatever makes the most sense in any given situation. I have never in my life thought to myself “I could easily help solve this problem and make everyone better off, but I will refuse because problem-solving is work and work is only for employees.”

Re: Plain Vanilla Web

#543

Earlier quoted context omitted.

> I understand your sentiment but it was perfectly normal to pump gas before paying in the U.S. for a very long time and still is in many places. I had a friend who worked at a gas station in high school. Filing police reports for people who filled up and left without paying was a standard part of operations. This was in a nice area, too. Often people just forgot and drove away. They had recourse because they had sec…

> You can’t have a pay-later business without an amount of non-payment, which has to be compensated by higher prices (which other customers shoulder). People who never experienced high-trust and customs societies cannot grasp why and how it works infinitely better than low-trust ones. But granted, all it takes is a few determined bad faith actors to break high-trust, when they are not vehemently and swiftly rejected…

For this to work, you need society as a whole to participate in enforcement.

But we have created an environment where this kind of thing is unthinkable, not even because people won't do it, but because they will only create legal trouble for themselves if they try. So the modus operandi for your average citizen in Western societies in general and US in particular is to not get involved and leave it all to law enforcement.

Re: Plain Vanilla Web

#544

When it comes to reducing complexity—especially for Java developers—it’s worth checking out Vaadin. It lets you build full web UIs without touching HTML, CSS, or JavaScript, entirely in Java. The UI logic runs on the server, meaning: no API design, no JSON mapping, no Redux — just a Java object model. Vaadin follows a true full-stack approach, where frontend and backend live in a single codebase. Combined with Spring…

This still of programming does not adhere to MVC though, you can't ever swap out the frontend because it's basically merged to the backend and I suspect complex to debug simmilar to JSF.

So a pattern is not mandatory with Vaadin, but you can make the UI “simple” changeable with a corresponding pattern of your choice. MVP and MVVM would be good examples of this.

Debugging in the frontend is not trivial, but can still be done with the appropriate setting in the properties (https://vaadin.com/docs/latest/flow/configuration/developmen...)

Re: Plain Vanilla Web

#545
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…

Not sure about the US, but in my country that's how mail order used to work for decades, and it's still pretty common to offer that payment option, though usually with some restrictions (e.g. not for your first order).

Most people are not scammers and will pay simply because it's the right thing to do.If your margins are decent, you can just eat the loss to some scammers as the cost of doing business. Especially if there's no real resale market for your product.

Re: Plain Vanilla Web

#546

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…

> >

Well, sometimes it was DBF files (of dBase / FoxPro / Clipper fame). The first app I ever wrote for money was a thing that prompted you to insert a floppy with a .dbf consisting of a list of recalled products and append it into a local database (another .dbf!) that would let the user query the whole thing. The floppies were obtained by means of a person walking to the local office of the corresponding government entity where they would hand a blank floppy and receive it back with the copy of the most recent updates. That was late 90s.

This evolved through multiple iterations as the government end of it did. At one point you no longer had to walk there physically; instead, there was a dial-up endpoint running UUCP that could be used to fetch the file. Then they found out about Internet, and it became a website with the file, now .mdb (MS Access) rather than .dbf. I rewrote the app in .NET/WinForms, since it was much easier to do all those things from it than to try bolting it onto an old TUI DOS app.

But it was still basically the same table with the same schema by mid-10s, and my app was still chugging along. I wonder sometimes if some iteration of it is still in use today; wouldn't be surprised if it were.

Re: Plain Vanilla Web

#547
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…

Shrink-wrap is still very much a thing, even if distribution is entirely digital in most cases. It's dominated by internal line-of-business apps, sure, but that was true back then also.

Re: Plain Vanilla Web

#548
post #304

Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely. I run sites that serve hundreds of millions per day a…

> But if I'm being honest post query selector frameworks don't have a strong cost benefit argument To me the killer app in the modern world is reactivity, ie making views that update in response to changes in the data model. To manually create listeners and do differential updates, and manage removal and teardown of event listeners etc, is akin to doing manual memory management. We used to do that with jquery sometim…

Reactivity features are helpful, but in my opinion they're only helpful in a problem that largely shouldn't exist.

For a vast majority of websites out there state largely lives on the server. Reactivity is only helpful when the state reacted to is client side, and for that most sites that's only going to happen when we decide to keep a duplicate copy of state in the client rather than rendering on the back end where the state lives.

I get the desire for smooth transitions, optimistic rendering, etc. Those goals lead to endless complexity and bugs when the actual source of truth lives elsewhere.

How a site is build becomes way more simple when we stick to keeping HTML rendering where the state lives even if that means making UX tradeoffs.

Re: Plain Vanilla Web

#549
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…

My problem with all this vanilla showcases is they are dead ass simple pages with the most basic layouts and user interaction. Shit just show me how long it takes you to create a nice reactive table with search or a form with proper labels, user interaction, validation, errors, etc Why would I implement that all from scratch when I can install svelte install a UI library and add a couple lines of code, all with a 25k…

Does your "nice reactive table with search" retain its current state (including scrolling!) if I click on a link that opens another page, and then back out?

Does it let me link to page N of results?

As a user, I find that, in practice, it's these kinds of things that frustrate me far more than the lack of instant reactivity, whereas simple form with a submit button and a paginated table below works just fine.

Re: Plain Vanilla Web

#550
post #400

Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely. I run sites that serve hundreds of millions per day a…

But you don't have to learn "framework after framework". Realistically, at a well-organised organisation you learn React and that's it. You don't worry about the compilation and minification and what have you, because you have a working build system that does the build and does the source maps, and you have a culture that fixes these things if they break or become flaky. As someone who stepped away from web for a whi…

Why would a language meant to focus only on styling need to be Turing complete?
Post reply on HN