This is my concern as well. IMO, one of the great aspects of HN is the semi-anonymity (no profile pics, names are just strings that you probably don't memorize unless you see the same name often, no visible upvotes, etc.). This makes us take the comments and submissions at face value, evaluating the content rather than relying on past experiences with the author, or other people's evaluation of it (upvotes).
I feel that any system which injects opinions into comments/submissions before you read and process it, work against the principles of Hacker News. A system like this might be great for a community full of trolls, but another one of Hacker News' strengths is it's heavy moderation. I see maybe <5% troll/bad-taste comments, and most of those are already flagged and [dead].
> The result, vinext (pronounced "vee-next"), is a drop-in replacement for Next.js
"Drop-in" in my mind means I can swap the next dependency for the vinext dependency and my app will function the same. If the reality is that I have to spend hours or days debugging obscure edge cases that appear in vinext, I wouldn't exactly call that a drop-in replacement. I understand that this is an early version and that it doesn't have parity yet, but why state that it is a non-goal? For many of us, that makes vinext a non-choice, unless we choose to develop for vinext from the beginning.
Furthermore, if you're making a tool that looks almost like a well-known and well-documented tool, but not quite, how is gen AI going to be able to deal with the edge cases and vinext-specific quirks?
Changing the definition of drop-in definitely has me concerned and makes me not take this any seriously than other projects open-sourced by Cloudflare, particularly the ones focused on more critical parts of their systems – e.g. pingora and ecdysis.
It seems most people learn git only through necessity. I've heard people say "I just want to code, I don't care about the peripherals". JIT learning is a good way to acquire capabilities with real-world application, but there is not JIT pull that forces people to learn about bisect, git objects, git logging, etc. These things can only be learnt either through setting off time to read documentation or by being taught through a course.
I think this is a good argument for teaching git, and being thorough in doing so, as many people are likely to never take that initiative themselves, while the benefits to being good at git are so obvious.
I think most people learn git through the particular processes that are established at their workplace, as every company uses git or VCS in general differently somehow.
>It seems most people learn git only through necessity. I've heard people say "I just want to code, I don't care about the peripherals"
I'm sure there's an element of (intellectual) laziness too, but I think people tend to only learn git by necessity because git is simply unpleasant to use.
A lot of us have Stockholm syndrome because git is less bad than what came before it, but git is not good.
I see this enough that I don’t bother ranting about it. There’s the free “Pro Git” (on the git homepage) that will teach you most of what you”ll need in a lifetime. But you tell people about rebase and the reflog and their eyes glaze over.
You lost me at Typescript. Typescript is great not because it abstracts away any javascript functionality (it doesn't), but because it allows IDE integrations (mainly LSP) to better understand your code, enabling go-to-definition, hover docs, autocomplete, semantic highlighting, code actions, inline error messages, etc.
But I agree many people are jumping on the javascript hate train without really understanding the modern web landscape.
I don't think anyone in this thread is arguing that inheritance or specificity is hard to understand.
My issue with cascading style sheets is mainly that namespace pollution (as every selector is defined in the same global namespace) means that short selectors (.separator, .highlight, .button) are likely to collide with completely unrelated parts of the application. BEM and tailwind are popular because they localize styles to specific components, preventing namespace issues. Today, most web frameworks deal with components, so it makes a lot of sense to localize the styles to the components. Scoped css in vue/svelte allows you to write short selectors, and have them only apply to the component they are written in, without needing to prefix them with a component name.
It clicked for me once I realized you can ctrl+shift+C to copy the diagram to text, and paste in my editor! But I wonder if it would be possible to make ctrl+C copy to clipboard as ASCII? I see that ctrl+C copies the json representation of the selected objects, but surely it would be possible to maintain an internal model of copied objects, while the clipboard is always filled with usable ASCII? I think I've seen some applications do this before
Vue should be a bit faster due to signals (updating state doesn't cause whole components to rerender), or at least require a bit less work to optimize (not as much need for useMemo, useEffect, etc. if everything uses signals). Other than that, it's mostly up to personal preference. SFC, directives, etc. are all just developer ergonomics, and people tend to prefer whatever they're most used to.
Also, vue interops better with webcomponents and non-framework code than React in my experience. Most non-React libraries need a React wrapper to work in a React project.
Sorry for being off-topic, but isn't a11y a rather ironic term for accessibility? It uses a very uncommon abbreviation type -- numeronym, and doesn't mean anything to the reader unless they look it up (or already know what it means).
I feel that any system which injects opinions into comments/submissions before you read and process it, work against the principles of Hacker News. A system like this might be great for a community full of trolls, but another one of Hacker News' strengths is it's heavy moderation. I see maybe <5% troll/bad-taste comments, and most of those are already flagged and [dead].