141–150 of 715 posts
Earlier quoted context omitted.
Web Components can have properties too, and in fact this is the norm.
Can't put those in templates though. It's a serious pain and completely unnecessary.
Here's a lit-html template that sets a property:
html``I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.
The main reason is I want direct control of the DOM and despite having 10 years or more react experience, it is too frustrating to deal with the react abstractions when you want direct dom control.
The interesting thing is that it’s the LLM/AI that makes this possible for me. LLMs are incredibly good at plain JavaScript.
With an LLM as capable as Gemini you rarely even need libraries - whatever your goal the LLM can often directly implement it for you, so you end up with few of no dependencies.
Earlier quoted context omitted.
One of the nice things about this is that back and forwards in history is snappy as hell. I’m so used to going back on my iPhone and the entire page reloading.
SPAs are supposed to be more efficient by only loading the data needed to update, but somehow back/forward are 100x more responsive on static pages or static sprinkled with JS, and they don't break the back button either. SPAs always have a kind of sluggish feel to them.
Earlier quoted context omitted.
It actually is kind of about performance. For me it's mostly about de-tooling your project. For example - I have a fairly complex app, at least for a side project, but so far I managed to keep everything without a single external dependecy nor any build tool. Now I have to convert it all to react and I'm not very happy about that, I will have to add a ton of tooling, and what's most important for me, I won't be able…
Why do you have to convert it to react?
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…
Earlier quoted context omitted.
As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly. The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology use…
> 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…
Weylus gives you a URL that you can visit on the device and instantly use it. Try doing that with native apps. They'd need native apps for Windows, Linux, Mac, iOS, Android... get them on the app stores too, support all the different Linux distros... or just a single URL that works instantly anywhere.
Steam works for the same reason the App Store works, it targets mostly a single platform (Windows) and all dependencies are bundled in. The Steam client itself is a web app running on the chrome engine, though.
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…
Blazing fast. Wow!
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…
I'm also from the before times, and still think one of the major issues with all of this is that we've decided to build a global application ecosystem by hacking stuff on top of a document format . HTML was supposed to just a slight markup layer to make it easier to transit and render text documents, likewise that's all HTTP was designed for. The ratio of text-to-markup should be fairly high (I'm sure today it's less…
I also don't like the state of the web.
Earlier quoted context omitted.
Sure, but the runtime is not exactly designed to guide you to the best way to do this. Hence the prevalence of frameworks to paper over the runtime. I openly admit that I'd rather learn a new framework than touch anything to do with figuring out how the browser is intended to behave in practice. What an abomination and insult to humanity. Edit: holy shit y'all do not like the earnest approach to technology
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.