Writing compilers for old CPUs has some real magic in it. It helps you see how processors really work and brings back the old days when hardware was simple and easy to understand. I miss that time. I once wrote a small C compiler in TypeScript for the Intel 8086 and 8087 ([1]), and I have huge respect for the people who coded for those chips. It’s super hard but also very rewarding.
I think writing lexers and parsers is just fun, code generation I have not done; which is next level imo. I guess the next level after that is doing the lexing parsing and code generation on the chip. Then the need for multi pass compilation would become apparent quickly I presume!
> It helps you see how processors really work and brings back the old days when hardware was simple and easy to understand. I miss that time.
Just FWIW, you can still find Z80s listed for sale all over the usual e-merchants and people absolutely still design around them. It wasn't discontinued until last June, and there's an updated eZ80 design still made and sold by Zilog.
The Z-80 was one of the best compiler targets of that age, but the 8086 was even better. Everyone was amazed at the very fast Turbo Pascal compiler for the Z-80 that got ported to 8086. I had an 80286 computer and Turbo Pascal was my favorite programming language because the compiler was fast, execution was fast, and the language was extended enough that you could do most systems and applications programming in Pascal -- you could easily link assembly language procedures such as replacements for the stdlib zero and copy routines that took advantage of new instructions and wider paths to 2x those functions.
8086 was a cakewalk compared to some of the weirder old chips. 6502 is a notoriously bad compiler target but things like the Signetics 2650 or RCA 1802 had a completely different set of challenges.
I implemented CKEditor integrations for Rails, Livewire, Phoenix, and React. I think the best developer experience was with Phoenix - at every step I was surprised by how well thought-out the framework is and how easy it is to build integrations for it. I definitely can’t say the same about Rails or, especially, React with the awful Next.js. For anyone curious: https://github.com/Mati365/ckeditor5-phoenix
As for Livewire - it feels like a simplified copy of Phoenix. In my opinion, it’s less advanced and less intuitive. For example, Livewire components don’t support slots, while Phoenix components handle them without any issues. Slots are critical for clean component composition - without them, you end up with messy, repetitive templates and a lot of unnecessary logic in the components themselves.
When it comes to Next.js, constant router changes and questionable decisions have become a daily routine. There’s no point integrating with something that gets rewritten every week and can’t be trusted to stay stable.
PHP (Laravel) + JQuery still works for me in 2025, but I would never use Livewire.
Using Node.js would hurt productivity but it's more powerful if needed. It may be needed because it has async/await and it has socket.io. It's also possible to use Typescript.
Next.js can be useful if you need everything (good SEO + highly interactive) but let's be honest how many websites need good SEO and websockets? LinkedIn maybe.
I'm not so sure Next.js is as SEO-friendly as people claim. The JavaScript bundles are pretty heavy, and the page still needs to hydrate before it becomes fully interactive. There are attempts to speed this up with React Server Components, but the developer experience there is already worse than with Phoenix components.
Next.js server performance isn’t great either - honestly, it’s pretty bad. Pages don’t feel that fast for users despite all the tricks and optimizations. In my opinion, metrics like LCP and others are much easier to optimize in older, more traditional frameworks. Unless you’re building a full-blown web application, a classic web page will almost always be faster and simpler to deliver without all the Next.js complexity.
I think if you're going to push closer to the server in a client+server app, I'd probably look towards either HTMX integration options with a preferred backend (there's some cool C# integrations from Jetbrains as an example) or Astro over Next.js ...
That said, I'm not necessarily a big fan of mixed environments since IMO most web apps can be mostly client side and most websites can be mostly server driven. Either is simpler than the mingling tends to get. That's just my take though.
I don't understand the 'Nextjs is good for SEO' hype. I think it's better to frame it as Nextjs isn't bad for SEO. Whether a site loads without client side rendering is a pretty binary thing.
If you're using Nextjs to get a high level of rich interactivity then your SEO issues aren't about CSR vs SSR anyway though. As you point it it's just bundle size and site speed, and URL structure that end up causing a negative impact. Nextjs doesn't fix that.
Next is all about that server rendering for seo which i remember doing for a spa wedding website a decade ago. Eg, if a crawler, server render otherwise spa style.
Nextjs with pages router was pretty good for me but app router is where it got complicated
The main issues were related to how JavaScript is integrated and distributed within Rails. In older versions, you have to deal with Sprockets and dependency bundling, which is tricky if you want your integration to work across a wide range of Rails versions.
In newer versions, import maps are recommended instead. The problem is that import maps enforce ESM, while Sprockets (as far as I know) doesn’t support ESM at all. On top of that, there are compatibility issues with Turbo links, various form libraries, and the limited extensibility of the import map library itself - adding extra dependencies is just painful.
Installing CKEditor wasn’t straightforward either, so I ended up creating a small DSL to simplify it. But then came another challenge: providing support for custom plugins in a way that would work with every Rails version, even without a bundler.
All of this is made even harder by the fact that CKEditor is distributed in both cloud and NPM versions, which complicates integration paths further.
In contrast, Phoenix makes things much simpler. From what I remember, the standard setup uses esbuild, which automatically pulls NPM dependencies from the deps directory - the same place where Elixir libraries are installed. This means you can distribute a package that includes both the Elixir and NPM parts of the editor, without having to manually modify package.json or worry about dependency conflicts.
It looks like a lot of these issues are due to the fact that Rails has been around for a long time, has lots of versions, and you wanted to support many versions (Which is commendable, by the way). If you only had to support the latest Rails version, how much harder would it have been than doing the same for Phoenix?
In the latest Rails versions, it’s probably just as easy as in Phoenix. The question is whether, after years of churn in the Rails frontend ecosystem, the core team hasn’t already driven away most developers who might have cared. At this point, few people would use a library that targets the newest Rails versions when most teams treat Rails purely as a backend and handle the frontend with something else.
While Rails indeed tries to support old versions for a while I found that many devs are eager to stay on top of upgrades (which also has been less painful the last few years and definitely when done incrementally)
Fair there will be some old never updated backend only services, but that seems like a stretch that those will need a FE library all of a sudden
As a fan of both, the LiveView DX is simpler than Hotwire's (though of course there are trade-offs both ways). With Hotwire you have the think about frames whereas LiveView is more like React where you just change the state and the appropriate diff is patched in without having to think about much else. This is not to say that Hotwire's frames are complex, LiveView is just that much simpler in that regard.
Yep, that's the whole thing, these technologies have strengths and weaknesses for different application. But of course most people just want to learn only one (and I don't blame them).
I am not sure you can say Livewire is a copy. The name suggests that is the case but both projects were started at similar time Livewire is afaik even older project than Liveview (Hotwire is youngest - in a way). They both take different approaches because PHP/Elixir have very different characteristics.
I think Livewire is still pretty great. Since PHP can't do websockets easily they focus on http and in most cases thats just fine. Liveview websockets can be an overkill.
It makes me sad that today you cannot say react without nextjs in the same sentence.
React used to be the leader in how to make ui reasonable in the generic client sense. Having done java swing, android, swift ui, and custom game dev ui work with all the forms of state management, react was on to something…
until the ssr fad attacked. Now it is all but nextjs in disguise.
There really isn't any need to conflate React with Next. React has its issues — notably more after exposing its internals in hooks —, but Next should be seen as something on its own.
I don't mind picking up a contract for maintaining React code, but never again am I touching anything built by Vercel; unless I specifically crave the “automagically different every release” quicksand masochism of their tools. I'm sorry to the people working on, say, Next; these are qualified and talented individuals. But the DX over time, gods…
React is still a reasonable view library, although not a top choice at all (for me). Insisting on using it for SSR via Next is self-inflicted pain down the road.
Don't preemptively give up on React with Next.js because some posters turn their frustration with it into contempt. Many of us use React 19 and Next App Router to great effect, and enjoy it, although there was certainly a learning curve.
NextJS app router/server components is incredible. By focusing on server-component-compatible patterns for interactivity, my rather complex web app retains like 90% of its functionality even with client side js disabled. I think the hate it gets really might be a skill issue.
It’s not about frustration, unwillingness to learn, or dismissing the tool altogether. My point is about trust. I just can’t imagine a Next.js app being as easily maintainable 10 years down the road as a Rails one. Honestly, I can’t even picture upgrading to a new major version without breaking something, because the pace of changes is just too fast. Sure, it’s great for small, simple projects. But building a business on it and risking breakages or dropped support? Not for me.
This isn't accurate. Most Next shops continue to use Page Router with no problems. We have an internal tool that uses both Page Router with React 13 and App Router with React 19, all seamlessly supported OOB, including frontend composition. So, again, I have to assume most of the FUD is rooted in inexperience.
Yeah Xilinx’s pricing curve is incredibly steep. Probably makes sense since they’re used in things like defence (radar, electronic warfare) so they can sell them in low quantities for huge prices and people will still buy them.
But with decent volume they get pretty cheap - for example there are video converters they have FPGAs in them that you can buy for less than you can buy the FPGA part in single qty - which means the manufacturer of the device is getting the FPGA for 5-10% of list price.
Wanted to buy a GOWIN FPGA recently, like on Sipeed's dev boards. Mouser wanted $37 for it, more than twice what the whole devkit costs.
Meanwhile the list price from the manufacturer is $3, but it's completely impossible to order anything as an individual. Not sure why they designed a hobbyist beginner-friendly dev board around a part from a company that makes all their products impossible to buy...
So people are going to desolder the chip? This doesn't seem very hobbyist-doable. Are there people out there who build products based on scrapped FPGAs from ebay?
There’s zero cloud service in the article, only physical boards decommissioned by a hyperscaler. Asking about cloud services tells me you only read the title.
Cloud should have been title-cased (they make this mistake almost every time in the article), they bought an FPGA decommissioned by Alibaba Cloud, the subsidiary.
That's messed up, because now he's working for the employer for free, hoping the company will somehow replace the social connections it made him lose in the first place. It's definitely not something to look up to - it's just sad.
Agree that it's messed up, but it's _not_ working for free:
> I was laid off in May, and per Danish law, as an employee of over nine years, I have a six-month notice period. I've been relieved of my duties, but I am still officially an employee until the end of November. I'm also entitled to three months of severance pay after my notice.
As someone currently living and employed in Denmark, I can confirm that this is how it works as per Funktionærloven § 2 s. 2-3. Once you've worked somewhere for 6 months, the employer has to give you 3 months notice when terminating your employment. Every 3 years, that notice period increases by 1 month.
Depending on circumstances, other regulatory requirements, etc. employees let go might be placed on garden leave: they get paid for the notice + severance period, but aren't expected to come in.
On the other hand: he mentions working 60 hour work weeks. That is _very_ unusual in Denmark, mostly because in many cases it's illegal by the 48-hour rule (see e.g. https://english.ida.dk/working-hours).
He hints that he was taking work home on the weekends and I'm guessing for no extra pay. I used to do stuff like that when I was much younger. Cannot imagine it at his age.
> I was laid off in May, and per Danish law, as an employee of over nine years, I have a six-month notice period. I've been relieved of my duties, but I am still officially an employee until the end of November. I'm also entitled to three months of severance pay after my notice.
No, he has a six month notice period, so officially he's still employed until November. I'm surprised they let him keep his badge, that's a huge risk after firing someone.
Nice! I’ve been using a similar approach for years with my own setup: https://github.com/Mati365/hetzner-podman-bunjs-deploy. It’s built around Podman and systemd, and honestly, nothing has broken in all that time. Super stable, super simple. Just drop your units and go. Rock solid.
Gyn, Aga and reviewers like Xusheng and others do really a great job! They are responsive, helpful and pleasant to work with. If you think about writing a piece, it’s definitely worth your time
