Was happy for a time, then I realized I only listen to the same playlists (generated playlists don't work for me as I need some time to appreciate new music). Now I use YouTube/SoundCloud to check out artists' releases, and then get the whole album if it's interesting.
I have a decently sized library with my favorite albums and that's been sufficient for some time now. Every once in a while, I track new releases and explore new genres, then add the few that picked my interest to my library.
Intentionally is great for enjoying art (and YouTube is more than enough for mood music)
I used SMB before with Infuse, but switched to selfhosting Jellyfin as scanning takes too much time over the network (the files are on HDDs attached via USB). I still play with Infuse, but it uses Jellyfin's database.
Because the tedious parts was done long ago while learning the tech. For any platform/library/framework you've been using for a while, you have some old projects laying around that you can extract the scaffolding from. And for new $THING you're learning, you have to take the slow approach anyway to get its semantic.
Everything old is new again, and I'm not even that old to know that you can return HTML fragments from AJAX call. But this is worse from any architectural point view. Why?
The old way was to return HTML fragments and add them to the DOM. There was still a separation of concern as the presentation layer on the server didn't care about the interface presented on the client. It was just data generally composed by a template library. The advent of SPA makes it so that we can reunite the presentation layer (with the template library) on the frontend and just send the data to be composed down with the request's response.
The issue with this approach is to again split the frontend, but now you have two template libraries to take care of (in this case one, but on the two sides). The main advantages of having a boundary is that you can have the best representation of data for each side's logic, converting only when needs. And the conversion layer needs to be simple enough to not introduce complexity of its own. JSON is fine as it's easy to audit a parser and HTML is fine, because it's mostly used as is on the other layer. We also have binary representation, but they also have strong arguments for their use.
With JSX on the server side, it's abstraction when there's no need to be. And in the wrong place to boot.
>JSON is fine [..] With JSX on the server side, it's abstraction when there's no need to be. And in the wrong place to boot.
I really don't know what you mean; the transport literally is JSON. We're not literally sending JSX anywhere. That's also in the article. The JSON output is shown about a dozen times throughout, especially in the third part. You can search for "JSON" on the page. It appears 97 times.
Replacing innerHTML wasn’t working out particularly well—especially for the highly interative Ads product—which made an engineer (who was not me, by the way) wonder whether it’s possible to run an XHP-style “tags render other tags” paradigm directly on the client computer without losing state between the re-renders.
HTML is still a document format, and while there's a lot of features added to browsers over the year, we still have this as the core of any web page. It's always a given that state don't survive renders. In desktop software, the process is alive while the UI is shown, so that's great for having state, but web pages started as documents, and the API reflects that. So saying that it's an issue, it's the same as saying a fork is not great for cutting.
React is an abstraction over the DOM for having a better API when you're trying not to re-render. And you can then simplify the format for transferring data between server and client. Net win on both side.
But the technique described in the article is like having an hammer and seeing nails everywhere. I don't see the advantages of having JSX representation of JSON objects on the server side.
>I don't see the advantages of having JSX representation of JSON objects on the server side.
That's not what we're building towards. I'm just using "breaking JSON apart" as a narrative device to show that Server Components componentize the UI-specific parts of the API logic (which previously lived in ad-hoc ViewModel-like parts of REST responses, or in the client codebase where REST responses get massaged).
I'm pointing out that this particular pattern (Server Components) is engendering more complexity than necessary.
If you have a full blown SPA on the client side, you shouldn't use ViewModels as that will ties your backend API to the client. If you go for a mixed approach, then your presentation layer is on the server and it's not an API.
HTMX is cognizant of this fact. What it adds are useful and nice abstractions on the basis that the interface is constructed on one end and used on the other. RSC is a complex solution for a simple problem.
Note “instead of replacing your existing REST API, you can add…”. It’s a thing people do these days! Recognizing the need for this layer has plenty of benefits.
As for HTMX, I know you might disagree, but I think it’s actually very similar in spirit to RSC. I do like it. Directives are like very limited Client components, server partials of your choice are like very limited Server components. It’s a good way to get a feel for the model.
If it is new to the DOM it will get added. If it is present in the DOM (based on id and other attributes when the id is not present) it will not get recreated. It may be left alone or it may have its attributes merged. There are a ton of edge cases though, which is why there is no native DOM diffing yet.
it happens because people really want to participate in the conversation, and that participation is more important to them than making a meaningful point.
I don't think it would do justice to the article. If I could write a good tldr, I wouldn't need to write a long article in the first place. I don't think it's important to optimize the article for a Hacker News discussion.
That said, I did include recaps of the three major sections at their end:
Look, it's your article Dan, but it would be in your best interest to provide a tldr with the general points. It would help so that people don't misjudge your article (this has already happened). It could maybe make the article more interesting to people that initially discarded reading something so long too. And providing some kind of initial framework might help following along the article too for those that are actually reading it.
That is not a good reason to make the content unnecessarily difficult for its target audience. Being smart also means being able to communicate with those who aren't as brilliant (or just don't have the time).
Yet because of that the issue they were concerned about was shown to the thread readers without having to read 75 pages of text.
Quite often people read the form thread first before wasting their life on some large corpus of text that might be crap. High quality discussions can point out poor quality (or at least fundamentally incorrect) posts and the reasons behind them enlightening the rest of the readers.
> The main advantages of having a boundary is that you can have the best representation of data for each side's logic, converting only when needs.
RSC doesn't impede this. In fact it improves it. Instead of having your ORM's objects, to be converted to JSON, sent, parsed, and finally manipulated to your UIs needs, you skip the whole "convert to JSON" part. You can go straight from your ORM objects (best for data operations) to UI (best for rendering) and skip having to think about how the heck you'll serialize this to be serialized over the wire.
> With JSX on the server side, it's abstraction when there's no need to be. And in the wrong place to boot.
JSX is syntactic sugar for a specific format of JavaScript object. It's a pretty simple format really. From ReactJSXElement.js, L242 [1]:
element = {
// This tag allows us to uniquely identify this as a React Element
$$typeof: REACT_ELEMENT_TYPE,
// Built-in properties that belong on the element
type,
key,
ref,
props,
};
As far as I'm aware, TC39 hasn't yet specified which shape of literal is "ok" and which one is "wrong" to run on a computer, depending on wether that computer has a screen or not. I imagine this is why V8, JSC and SpiderMonkey, etc let you create objects of any shape you want on any environment. I don't understand what's wrong about using this shape on the server.
> Instead of having your ORM's objects, to be converted to JSON, sent, parsed, and finally manipulated to your UIs needs, you skip the whole "convert to JSON" part. You can go straight from your ORM objects (best for data operations) to UI (best for rendering) and skip having to think about how the heck you'll serialize this to be serialized over the wire.
I can't let go of the fact that you get the exact same thing if you just render html on the server. It's driving me crazy. We've really gone full circle, and I'm not sure for what benefit.
> The old way was to return HTML fragments and add them to the DOM. There was still a separation of concern as the presentation layer on the server didn't care about the interface presented on the client.
I doubt there were many systems where the server-generated HTML fragments were generic enough that the server and client HTML documents didn't need to know anything about each other's HTML. It's conceivable to build such a system, particularly if it's intended for a screen-reader or an extremely thinly-styled web page, but in either of those cases HTML injection over AJAX would have been an unlikely architectural choice.
In practice, all these systems that did HTML injection over AJAX were tightly coupled. The server made strong assumptions about the HTML documents that would be requesting HTML fragments, and the HTML documents made strong assumptions about the shape of the HTML fragments the server would give it.
> where the server-generated HTML fragments were generic enough that the server and client HTML documents didn't need to know anything about each other's HTML.
> all these systems that did HTML injection over AJAX were tightly coupled
That's because the presentation layer originated on the server. What the server didn't care about was the transformation that alters the display of the HTML on the client. So you can add add an extension to your browser that translate the text to another language and it wouldn't matter to the server. Or inject your own styles. Even when you do an AJAX request, you can add JS code that discards the response.
An age ago I took interest in KnockoutJS based on Model-View-ViewModel and found it pragmatic and easy to use. It was however at the beginning of the mad javascript framework-hopping marathon, so it was considered 'obsolete' after a few months. I just peeked, Knockout still exists.
Knockout was a huge leap in developer experience at the time. It's worth noting that Ryan Carniato, the creator of SolidJS, was a huge fan of Knockout. It's a major influence of SolidJS.
As long as WhatsApp have a strong backer like Meta, then using the term competition is meaningless. In many countries, WA is the de facto IM platform, but I can bet that it hasn't received a dim from those users. So how do they pay their developers, infrastructure, and surrounding resources?
As you say, it's not public as in public road (and even that has police to enforce proper behavior), but more like publicly accessible but on private properties.
When it's my server and I'm paying for it, then banning resources wasters is the right move.
My approach since I was in High School and started programming has always stayed the same.
It's actually very rare to have to innovate, starting from scratch. So whatever problems I need to solve, my first step is always looking for information. And more often than not, the solution is right there.
I don't spend much time at the keyboard. Most of my time is spent perusing books, articles, blog posts, and source code. Or talking to a domain expert. That's what will gave me the system design/architecture for what I want to build. Once that's done, it's pretty much a straight line, or better a spiral iteratively building and testing, going deep only when things matters.
This approach clashes with AI (at least from my POV), because they can't give you a coherent overview of a domain. It's always piecewise elements that are probably wrong in the problem's context, or just plain wrong.
I much prefer to go from general/introductory materials to very specific/advanced ones that matters with sources I trust.
As for the code, it's starting small, get it to work well, and then start on the next iteration. And thanks to the kindness of people, there's so many opensource code from which to learn from.
Mostly deep diving in startup projects as well as helping entrepreneurs getting their MVP out. I'm a freelancer, so often there's a very short period between learning the tools/framework/codebase and helping out with issues and features.
You can’t eliminate formalism in programming. You can only abstract it away by creating a metaprogramming layer for the current one. And prompt isn’t that. Prompting is a blind shot hoping to hit something good.
Python is not exactly a hard language to learn. But the truth is that people generally don’t like to devote time to what they deem unimportant even if the end result would be useful. I’ve seen smart people go though dense mathematics and physics books, but refuses to take an introductory course in programming.
I have a decently sized library with my favorite albums and that's been sufficient for some time now. Every once in a while, I track new releases and explore new genres, then add the few that picked my interest to my library.
Intentionally is great for enjoying art (and YouTube is more than enough for mood music)
reply