Pull down designs via Framelink, optionally enrich with PNG exports of nodes added as image uploads to the prompt, write out the components, test/verify via Playwright MCP.
Gemini has a 1M context size now, so this applies to large mature codebases as well as greenfield. The key thing here is the coding agent being really clever about maintaining its' context; you don't need to fit an entire codebase into a single prompt in the same way that you don't need to fit the entire codebase into your head to make a change, you just need enough context on the structure and form to maintain the correct patterns.
Using triggers + history tables (aka audit tables) is the right answer 98% of the time. Just do it. If you're not already doing it, start today. It is a proven technique, in use for _over 30 years_.
It's great if you can store immutable data. Really, really great. But you _probably_ have a ton of mutable data in your database and you are _probably_ forgetting a ton of it every day. Stop forgetting things! Use history tables.
Do not use Papertrail or similar application-space history tracking libraries/techniques. They are slow, error-prone, and incapable of capturing any DB changes that bypass your app stack (which you probably have, and should). Worth remembering that _any_ attempt to capture an "updated" timestamp from your app is fundamentally incorrect, because each of your webheads has its own clock. Use the database clock! It's the only one that's correct!
> Average webdev tomorrow writes Python for a reasonably fast Python interpreter implemented in the browser with WASM
Python is just as hand-wavy as Javascript, so I fail to see the win here. At least C/C++/Rust/Go give you some neat guarantees, but you lose all the velocity JS gives you. I mean, pyscript doesn't even support hot reloading out of the box, but yeah, I'm sure it's definitely the future. Besides, you could probably just write the interpreter in vanilla JS and it would be comparably fast (at least in Chrome), so WASM is completely superfluous.
Games like League of Legends and most physical sports are red-herrings when it comes to thoughtful strategy, because frequently you can win these games by simply outperforming your opponent in raw strength or agility, even if they have the theoretically superior strategy. Among these games, it is relatively uncommon to have perfectly matched opponents where strategy determines the victor.
A strategic culture based on these games might think that brute force is always the best "strategy". Sound familiar?
I think the best game to teach the essence of strategy is Roshambo, or "Rock-Paper-Scissors". According to game theory, the optimal strategy (Nash Equilibrium) is to pick your move at uniform random, in which case you will "not lose" 66% of the time. But in face-to-face practice, a skilled Roshambo player will outright win more than 33% of games. How? Because humans are not robots and aren't good at RNG. Fundamentally, strategy is not about studying game rules and theory! It is about understanding your opponent's perspective and thus forecasting their next move. RPS provides an excellent platform for understanding strategy in this context, especially when done in real-time, face-to-face.
Even in the domain of robots, RPS offers insight into how a simple but nontrivial game can lead to complex metagames of composite strategies. See how Python bots can achieve 80% winrate against a field of lesser bots [1].
SPAs are the "Google-scale" of frontend tech. YAGNI unless you are Big (or trying to fleece VCs).
SPAs are useful where the latency and overall UX of a button press can be translated to some tiny % increase in a KPI through A/B testing, etc. Where you want to track user behavior down to a pixel & microsecond, and wrapping every element in JS is the only way to get there. This is frankly irrelevant to 99% of projects and companies.
SPAs are not designed for developer productivity, they are designed by BigCo that can spend 0.01% of their revenue to hire multiple teams/ICs to squeeze out a +0.1% increase in revenue. It's comparable to doing microarchitecture-specific optimizations for your clientside website code. Totally irrelevant to your side project or startup.
Pick a productive stack/framework and build out your product with a solid foundation. You can always bolt on websocket-based features as required. Maybe rewrite your frontend in a SPA framework once you hit $100mm revenue.
I was being provocative -- finance will not totally disappear, but it will play a greatly diminished role in human economies. Successful national economies will adopt a tech-driven, centralized approach to economics. The global, eternally-fungible USD, and all the problems it brings, will cease to exist.
Non-transferable, expiring, digital currencies may be employed in limited domains, for example "food credits" or "fuel credits". This means that free markets will still exist much like today, you can shop for whatever food you want, but you now can't use your "food money" for e.g. financial speculation or buying a new car. This unlocks UBI as a practical solution to many societal problems. You can give everyone $250 foodbucks a week with 1 month expiration and not worry about massive financial fraud & waste. Price mechanism still works, food industry is still competing for your foodbucks which would be converted into some other representation of economic value upon purchase.
Libertarians will lose their minds at this, but frankly the nations that adopt a centralized tech-driven economy will vastly outperform those still based on legacy financial systems. In fact, they already are beginning to. There is so much waste in the current American economy and yet most Americans are still struggling to pay rent and put food on the table.
The alternative future is the one described by DeFi/web3 crowd, which is essentially based on a deep misunderstanding of what finance and money is about and how they relate to the actual economy. They tend to view economics as a subset of finance ("fix the money, fix the world") when really it's the other way around, and finance itself is nonessential.
The author touches on some of the weaknesses of true decentralization but does not directly address the fundamental paradox.
True decentralization is a natural but ephemeral quality of networks with relatively few nodes. That is, scales where each individual node has enough internal resources to accurately represent the entire network. Human networks are parameterized _very roughly_ by Dunbar's Number (100-250), while modern computer networks are much more capable.
As a small network scales up, decentralization becomes unnatural; nodes and links require too many resources to accurately model and communicate the network state. It becomes net energy efficient to introduce layers of dedicated networking nodes, routing protocols, and entire subnets. It is not a fluke that "Web3.0/DeFi" technologies so far are either a) tremendously inefficient or b) end up centralized.
If you want to preserve true decentralization at this scale, you need to enforce it. Prohibit centralization in any form. No more central networking/control nodes. Perhaps there are clever schemes where you can e.g. shard the entire network uniformly across its nodes, but the bottom line--the paradox--is that some central authority must decide on and enforce the sharding/decentralization policies and actively prevent centralization from emerging.
Frankly, decentralization at almost any meaningful scale in our modern global society is a myth. It's a myth tightly coupled to the American origin story and its philosophical roots in the classical liberalism of Locke et al. and Western/Reformation Christianity.
From a hard scientific perspective, it makes no sense why to sacrifice the welfare of a system for the sake of maximizing the welfare of an arbitrary component that depends on the welfare of the system. Especially when we are confronted with systemic I/O imbalances on a global scale. To arrive at the myth of decentralization, you need the ingredient of (hyper)individualist ideology.
- They claim full open source but for several years they did not release the server.
- They claim federation is impossible… yet matrix has it.
- They claim openness but are actively hostile to linux distributions and f-droid.
- Related, getting signal from an app store is no more secure than getting any random proprietary app.
- There's a lot of allegations that they don't need VCs because they have backing from the USA army.