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

531–540 of 715 posts

Re: Plain Vanilla Web

#531

Post by tzebco »

sneak wrote: post #520
zzo38computer wrote: post #482

Earlier quoted context omitted.

> The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off. I agree. (This should also include CSS, TLS, cookies, and many other things; I often disable CSS, and it should work just as well if CSS is disabled just as much as if pictures or JavaScripts or cookies are disabled.) However, there are some uses where JavaScripts may be helpful e.g. if a web page h…

No, TLS should always be required. We should be moving away from plaintext anything on the wire, if for no other reason than privacy (but also for integrity, injecting scripts into an HTTP response is a nasty attack surface).

I feel the same way, although I do struggle with excluding people who use older technology. I suppose TLS 1.2 is fairly old at this point ...

Re: Plain Vanilla Web

#532

Post by 6P58r3MXJSLi »

Vinz_ wrote: post #464
hliyan wrote: post #451

Earlier quoted context omitted.

Why? What I would prefer is a "Notify me when the rider is [X] minutes away. Use ringtone [R]" feature. X is the time I need to go downstairs and open the gate. The customer need not have their brains cluttered with logistics details.

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?

Re: Plain Vanilla Web

#533

Post by NewsaHackO »

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…

To me, this line of argument is completely backwards. Are you arguing that when people didn't know better, they used flawed systems, or are you actually saying that having a unified method of interaction between users and systems though a web browser app is worse than dark IT excel sheet macros?

Re: Plain Vanilla Web

#534

Post by staticelf »

I tried to build an app with web components but honestly, the DX is quite bad and I abandoned the shadow DOM for light dom until I abandoned the vanilla tech stack entirely and moved the project to React. It is just so much faster to develop in React in comparison. Also when stuff goes wrong with components they many times just fail silently with no errors given to the console.

You have such a great community with big, very well thought out libraries like Tanstack Query that is pretty nice to work with. I can have backend and front end code in the same repository in a simple way and reuse code.

I also have the project in Phoenix Liveview which is also a much nicer way of using components. The thing is I don't really know which tech stack is gonna win so I made a small prototype in both to see different advantages / disadvantages.

One thing is clear tho, pretty much everything is better than using vanilla components and it's really sad because I really do want to use vanilla components and I want them to be good.

Re: Plain Vanilla Web

#535

Post by austin-cheney »

lerp-io wrote: post #407
austin-cheney wrote: post #316

Earlier quoted context omitted.

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…

If you want to iterate faster then don’t impose unnecessary abstractions. These tools exist so that otherwise unqualified people can participate.

Re: Plain Vanilla Web

#536

Post by owebmaster »

ilaksh wrote: post #167
braden-lk wrote: post #4

Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pretty tedious in vanilla, though!

some people cheat by using web components but with Lit Elements. https://lit.dev/ . I use it with raw JS without any bundling.

Same. Recreating a basic lit framework is like 300 lines of code

Re: Plain Vanilla Web

#537

Post by hahn-kev »

a4isms wrote: post #198
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…

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 think a really good example of this is that lots of times even when making a web app, different people make the web app from the people who made the marketing site for selling the web app.

Re: Plain Vanilla Web

#538

Post by cadamsdotcom »

cube00 wrote: post #480
cadamsdotcom wrote: post #374

This website covers a fair bit of React - in particular, it seems Web Components can be used to create components with both state & props. One can imagine a cross-compiler so you could write React, but have it compiled to React-free javascript - leaving no React dependency in production. Would be a lift, but looks superficially possible. What are the blockers to this?

I suspect that's where the new React Compiler will eventually head where based on your code it will try and remove as much React runtime as possible if it's not needed.

Took a look - after the pain of React memoization, that's a super exciting development.

Thanks for the pointer!

Re: Plain Vanilla Web

#539

Post by motogpjimbo »

Aurornis wrote: post #403
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 m…

Excel files can work surprisingly well in B2B scenarios where there's a high degree of trust. At a retailer I used to work at, we ran an impromptu Christmas gifts team in December each year, where corporate clients could put in a large order of gifts to be sent to their employees. Rather than build a website for it, we just sent them over an Excel file they could fill in with the name and address of each employee, the gift they wanted to receive and a message for the label. They'd send the file back to us and we had a process to validate the data and load it into our system. It sounds primitive, but it was much more time- and cost-efficient than faffing around with a custom application that we would only use for one month per year and which the clients probably wouldn't enjoy using anyway.

Re: Plain Vanilla Web

#540

Post by joshvm »

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…

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

Payment after receipt is very common in Switzerland, but fraud is presumably rare. Your name would probably go on the debtors register and that's the sort of bad credit history you don't want to have. At some point the police/debt collection is involved, they get sent to whatever the address is and so on. For the average person it's not worth burning your name and address for a free spokeshave.

Post reply on HN