Earlier quoted context omitted.
In what way are properties verbose and limited in your view? You can set them declaratively with a template binding in most template systems.
I showed earlier how it takes multiple lines and some fiddling with DOM to set a simple property with vanilla web components. Sure, if you're using a framework like lit, you have access to template binding, but at that point you might as well use an equivalent framework like SolidJS or Svelte which just skips the web component layer.
Plain Vanilla Web
251–260 of 715 posts
Re: Plain Vanilla Web
#252Earlier quoted context omitted.
You can still do system wide deployments with .NET Core, or .NET 5+, as you prefer to call it. https://learn.microsoft.com/en-us/dotnet/core/install/window...
Of course. I was strictly refering to .NET preinstalled in Windows as per the comment I replied to, which I believe only applies to Framework 4.8. Although, on re-read, maybe they meant there's a good chance another application already installed it? This I wouldn't agree with, as applications often insist on installing different versions of the system-wide runtime, even for the same major version.
To be specific, .NET install is version-aware and would manage those side by side, unless the destination folder is overridden.
Re: Plain Vanilla Web
#253Earlier quoted context omitted.
Sure, that's what we did in the good old days, and there's good reason that most of us, when building more complex components, switched to better state management systems. The main issue is that, typically, if you're storing data directly in the DOM, you're storing redundant data. For example, if you've got an input that should have a green background if the input is one string, and a purple background if the input i…
This is a comical misrepresentation of reality. The actual reason people switched to React was because it was what Facebook was doing and they wanted to imitate one of the wealthiest companies to ever exist, not because the masses had problems with rendering form widgets. This problem was solved twenty years ago. Perhaps the worst part about this slander is that benchmarks have actually shown time and again that vani…
I find your version of history amusing, because the first project that I migrated away from vanilla JS was actually to Angular, because the team found React's JSX syntax too weird. And these weren't even the first wave of frameworks — people had been using state management systems long before then, but they had other flaws that made them difficult to work with in their own right. React became popular very quickly because it had a very simple rendering model, and because it was quick in comparison to a lot of other options at the time. Since then, the field has developed a lot, and at this point I wouldn't recommend React at all.
Re: Plain Vanilla Web
#254I'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…
100kb would never be a considerations for any of the apps I worked on (as a contractor in the corporate world). I mostly work in large teams, sometimes we had mulit-team monorepos with various line-of-buisness apps using React. 100kb are so completely irrelevant, as for LoB or B2B, no-one cares about the initial page load. Your users use the app on a daily basis, so they get all the JS/CSS/static assets served from their browser cache almost all of the time, until we make a new prod deployment (usually weeks). Plus, all users are always on Ethernet or WiFi at least, not some 3G cellular network somewhere in the desert.
If you use some smarter framework like Next.js, you even get smartly chunked js parts on a per-route basis, that are immutable - they contain a sha256 hash of their content in the filename, and we configure the webserver to serve them via `Cache-Control: immutable`. There won't even be a roundtrip to check for newer versions.
Plus Nextjs comes with tons of other stuff, like pre-loading chunks in the background, or when hovering over a link (i.e. using the time between the hover and the click to already load a chunk). Let alone that the initial render is static html and hydration happens completely unnoticed from the user.
Re: Plain Vanilla Web
#255https://plainvanillaweb.com/pages/applications.html This example code does exactly one of those things: update the address bar by setting the fragment identifier. Middle clicking and back/forward buttons work because of that. Error handling (if it were to not just be static content but actually loading something from a server like a real website, which can fail) and loading indicators are not present
Re-implementing browser code in JavaScript is not using the "plain" or "vanilla" web functionality. You're making your own framework at that point
Re: Plain Vanilla Web
#256I'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…
I kind think that if your discussing tech about the web you need to include the scale and your experience.
Re: Plain Vanilla Web
#257I'd like to use lit-html but Jetbrains does not support it - very annoying.
Re: Plain Vanilla Web
#258> The most basic structuring technique is separating CSS into multiple files. We could add all those files in order as \ tags into the index.html but this quickly becomes unworkable if we have multiple HTML pages. Instead it is better to import them into the index.css (via @import) You'll eventually need \ anyway for preloads, especially with web fonts, since that's the only way to prevent FOUC. Personally I lean on…
I don't find this convincing. For one, many sites don't need web fonts to begin with. For two, the sites that do can use `font-display` or, even better, just let the browser figure it out. Browser developers have spent way more time on these problems than any one of us individually ever will and more often than not, the behavior you get out of the box is already pretty fine.
Re: Plain Vanilla Web
#259Earlier quoted context omitted.
Huh? The built-in APIs aren't perfect, but we're talking about something simple as ``` fetch('/my-content').then(async res => { if(res.ok) { document.getElementById('my-element').innerHtml = await res.text(); } }) ``` Something like that. Doesn't get much easier. Gone are the days of browser inconsistencies, at least of you stick to "Baseline Widely available" APIs which is now prominently displayed on MDN.
No-framework web tinkerer here. If I had a nickel for every second of my life I've spent typing document.getElementById, I'd be able to afford new fingers. Should've been renamed to getId() and put in global scope two decades ago, if not three. At least querySelector() is a few characters shorter, but I always feel bad using such an alarmingly overdesigned tool for anything trivial.
Re: Plain Vanilla Web
#260Earlier quoted context omitted.
I have seen more broken SPAs than MPAs, by far. Ironic, considering SPAs are supposed to improve conversion rates and user experience. Even from big companies with no excuse - Reddit is almost unusable on phones, X was straight up broken for a month straight with image loading on mobile. If you’re writing an SPA, and it isn’t Twitter or a content consumption platform, and it isn’t necessary to be API-driven, seriousl…
We created a generation of developers that AIM to over-engineer requirements... and we also came up with extremely pervasive frameworks to go with it... My firm cannot hire people with no React experience... people REALLY only know how to build cruft these days...