The point is that we will still need senior level employees, but the way fresh grads get to that level is generally through entry level positions, experience and mentorship. I don't think we can expect the university system to start pumping out senior level graduates.
This happens regardless of which framework is used or even if no framework is used. Plenty of web developers do not understand how the browser or JS work at a deep level.
How does versioning work? After you fork an HTML app, is there a way to update it and get newer features without manual intervention?
I'm thinking about the Kanban board example I saw in the demo video. It looks like column re-ordering wasn't supported yet. What if I fork the app, put time into creating my Kanban, then I want to update to a new version that supports column re-ordering?
> a mishmash of vibe coded stuff you don’t understand.
No, there is a difference between "I wrote this code" and "I understand this code". You don't need to write all the code in a project to understand it. Otherwise writing software in a team would not be a viable undertaking.
Why do you say "JSX"? JSX is an HTML templating language for JavaScript. templ looks like an HTML templating language for Go. Every popular web backend language has an HTML templating language... so that it can produce HTML - is it really that surprising?
Here's the react-table example app with 112,500 records, just like your example. I am not really seeing much of a performance difference (and this is in dev mode - it would be faster if built for production):
This comparison is disingenuous and off-putting. When I read "a React button" I assume you are talking about `<button>` and the React runtime, not some third party libraries.
But logging in and posting don't seem like "undoable" actions to me. That would be similar to undoing a save or undoing a login to Adobe CC in Photoshop. Things definitely get trickier with network requests, but that can be solved with something like CRDT.
> Does the fact that WFH is not a thing mean that in the real world, for most people, coming to the office IS actually more efficient?
I don't think the labor market is efficient to such a degree that we can draw this conclusion. Lots of startups are doing this, but it takes time, capital and luck to achieve the success of the big corporate competitors, which have a huge amount of middle management who hate WFH.
Fair point, but I have seen a lot of shitty software developed with this mantra. Usually because the "iterate" part is forgotten in favor of the next "rapid" development. I agree that the quickest way to learn whether your solution is valid is to ship & experiment. But once you know the solution (which is sometimes not even that complicated) then you should really take the time to produce a solid piece of software before moving on.
But I agree, my original comment is probably a little too critical. There are valid times to rapidly iterate and ship. When it turns into the _only_ way you ship software, I think it becomes a problem.
It's important to note that this is only really relevant advice for a specific type of startup that is still trying to rapidly iterate to find product market fit.
Personally I find it incredibly annoying to work on and with with products that were developed like this. There are so many half baked features that technically "work" but are slow, buggy or difficult to integrate with.
I think this is a fair criticism. You chose to share this on hackernews, which invites feedback (including constructive criticism). I don't see the problem ¯\_(ツ)_/¯ Do you expect people to only voice praise for open source projects?
Do you think this "MetaWindow" is much more attractive? Here's a similar looking transparent sound barrier in a new building area that is already starting to be covered in graffiti: https://youtu.be/e7-Fd1HOw_g?si=OTNn_NyV_W7iJStz&t=265
At least some light will still get through in the gaps between graffiti, but I don't think they will end up looking much different than non-transparent barriers.
I’d argue that the rich nations have an obligation to find a way to structure a less carbon intensive economy. The global south can benefit from the R&D that the west does. It’s not a forgone conclusion that the only way to grow is by burning fossil fuels, but the global south will certainly go that way if there is no known alternative.
Sure, all mega cities have even larger metro areas. I'm not pretending Chicago doesn't have a huge metro area. But my point stands: the European route has much higher catchment than your proposed USA route, even if you include metro areas. Population density is not the only argument, although I think it's pretty clear why the US and EU are not comparable: https://luminocity3d.org/WorldPopDen/#4/38.51/-51.06 Most of the US looks more like Spain and less like Central Europe.
There needs to be local public transportation infrastructure. This is where the US should be focusing efforts, no long-distance high-speed trains. It works in Europe because there are huge catchment areas (see population density) that funnel riders to regional hubs that are then connected with high speed trains. I don't think the first step to making rail work in the US is connecting metropolises with high-speed trains. Until there's a better local public transportation story, it's expensive and impractical once you arrive at your destination.
Oh if we're talking about metro area population, then the EU route is also significantly higher (for example, Paris goes from 2 million to 13 million). I was just looking at city limits in both cases.
Honestly I agree with your sentiment. We should connect all these urban areas with passenger rail. But I don't think that this is the first step. Most American cities have atrocious public transit, which needs to be fixed first. No one will take a train from Chicago to Minneapolis if they just have to rent a car once they get there anyway. It would be a shame to invest billions in connecting cities with high speed rail, only to have low ridership because it still doesn't compete with flying/driving.