Lost me at Web Components. There are many things the web does great, but Web Components is not one of them. Can we move on?
Why do you think web components are not great?
Plain Vanilla Web
511–520 of 715 posts
Re: Plain Vanilla Web
#512Am I the only one who (still) does not feel comfortable seeing JavaScript being intertwined into the so-called "vanilla" web in a way that seems more like a hard dependency and not the progressive enhancement we were taught should be the approach for serious public websites?
The page https://plainvanillaweb.com/pages/sites.html uses custom components for all code examples and embedded content. Without JavaScript, it merely shows "enable scripting to view ../XYZ.html" in place of all code examples and demos. Better than having no fallback at all, I suppose, yet still not "navigable".
The fact that it does not even bother to build these custom components on any native element with a similar purpose—like, say, a link that users could follow to see the text document (*), or a plain old iframe (**)—is grim.
Web components are indeed useful for prototyping and personal testing, but are they really beyond the threshold where it is safe to serve them in the wild, potentially harming some users?
(*) I know, view-source: links and embeds are sadly blocked by browsers nowadays. Makes very little sense to me. Someone likely managed to exploit it for some nasty purposes, so now we are "protected", I suppose.
(**) See? In the olden days even iframes were said to have a link fallback inside, for user agents that did not support them.
Re: Plain Vanilla Web
#513Earlier quoted context omitted.
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…
This is doing the same thing described in the GP of your comment.
If 1/few people are building a site so simple that the menu code is in "menu.js", then sure, separate your code and go about your day. But when 30+ FTEs are building a huge app with lots of tightly interconnected features, then the complexity is there no matter how you architect your code - it's part of the business requirements. Like GGP said, they're different domains, and stuff said about one doesn't necessarily apply to the other.
Re: Plain Vanilla Web
#514I'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…
> You can simply not pay if you choose not to.
It's only a matter of time before this seller falls victim to a scammer - once they're found. I used to work for a book publisher who started doing their own e-commerce, and at the time one of the payment methods was a "pay later" one that predated the internet ("acceptgiro"). It only took a few months (if that) after the first sites went live that someone placed an order for a few hundred euros worth of books and had it delivered at a storage unit address. We scrapped the pay later payment option for orders over a certain amount then, and I'm sure later on the pay later option was removed entirely in favor of pay in advance methods.
There's newer pay later schemes now (Klarna IIRC) but the risk and debt collection falls to this payment provider. Of course, they got in legal trouble recently because they're a loan / credit company but didn't present the user with the right legalese for that.
Re: Plain Vanilla Web
#515Earlier quoted context omitted.
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…
That was one of the most interesting reads I've read in a while, thanks.
So much great and timeless stuff was written in the 2000's, it's great and should be part of everyone's read list. Another one that's still pretty timeless is https://randsinrepose.com/
Re: Plain Vanilla Web
#516Earlier 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…
> You can simply not pay if you choose not to. It's only a matter of time before this seller falls victim to a scammer - once they're found. I used to work for a book publisher who started doing their own e-commerce, and at the time one of the payment methods was a "pay later" one that predated the internet ("acceptgiro"). It only took a few months (if that) after the first sites went live that someone placed an orde…
That's just business, you need to price in disturbances like an important customer going bankrupt or switching suppliers or some customers refusing to pay for other reasons, and do a risk assessment before supplying on large orders.
It's one of the earliest lessons you'll learn from starting a company. Another close one is to not waste time on failed sales and annoying customers, replacing them with new customers is usually more profitable and enjoyable.
Re: Plain Vanilla Web
#517Earlier quoted context omitted.
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 essen…
It sounds like he’s already smoking pot.
Re: Plain Vanilla Web
#518Earlier 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…
> There are so many way to do commerce both on and offline and if you squint and look closely you'll find interesting people doing interesting things all around you. Why do I want "interesting" ways to buy things? I want to be able to buy what I want quickly and reliably. I don't get the benefit of making me try to figure out how to buy something I want
Why wouldn't you want interesting experiences options, from time to time?
Why wouldn't you appreciate getting out of the (often) dull (sometimes) frictionless select-order-pay-receive-use-store-forget-discard purchase experience?
Re: Plain Vanilla Web
#519I'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…
Fantastic website, really happy to be able to finally read interesting stories and news about the tech scene where I work, in Vietnam
Took me off guard too :D I didn't expect to click on a random link on HN and see an article about my home country
Re: Plain Vanilla Web
#520I’m tired of SPAs and webpages that don’t render without JavaScript. The web is supposed to degrade gracefully if you are missing browser features, up to and including images turned off. Now, web developers give you a blank page if you don’t run a megabyte of their shitty code. No thank you.
> 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).