athanagor2

How did you conduct this rewrite? Did you hand the AI some specs, some tests, the existing code?

I feel like AI has dramatically changed how complete rewrites can be considered, especially for long-lived, legacy projects.

> You’d realise how bad this is when I tell you the benchmarks for the native WhatsApp for comparison. I tested the old/native WhatsApp, and it uses just 190MB most of the time, dropping to less than 100MB when it’s completely idle. At worst, it would reach 300MB, which can happen only when the chat is really active.

Well sounds like a lot of useless work was being done then, how does it gobble 100MB when idle? Are the protocols that complex?

Just do as I do and open web.whatsapp.com in your favorite browser

> In the very worst case they used next.js to write a second backend that sat between my existing Django backend (which had been done earlier) and the front end.

That's hilarious.

Casey Muratori truly is right when he says to "non-pessimize" software (= make it do what it should do and not more), before optimizing it.

> React and React-like frameworks (includes Vue and Svelte I believe)

Putting React with those two is a wild take.

> 99% percent of websites would work a lot better with SSR and a few lines of JavaScript here and there and there is zero reason to bring anything like React to the table.

Probably but as soon as you have a modicum of logic in your page the primitives of the web are a pain to use.

Also, I must be able to build stuff in the 1% space. I actually did it before: I built an app that's entirely client-side, with Vue, and "serverless" in the sense that it's distributed in the form of one single HTML file. Although we changed that in the last few months to host it on a proper server.

The level of psychological trauma that some back-end devs seem to endure is hilarious though. Like I get it, software sucks and it's sad but no need to be dramatic about it.

And btw, re forbidding stuff: no library, no process, no method can ever substitute to actually knowing what you're doing.

Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol

The fact it could be compiled in WASM is a good thing, given the Chrome team was considering removing libxml and XSLT support a few years back. The reasons cited were mostly about security (and share of users).

It's another proof that working on fundamental tools is a good thing.

This reminds me of the time I did a fait accompli.

Due to changes in the input data, a simulator was crashing completely and very early in the simulation, making it unusable. We had to solve this quickly. The underlying module that was crashing had been written by a non-software engineer, and it showed. The project manager was trying to understand it and do the most minimal fix to it as possible. My solution was to rewrite the module from the ground up; this solved the bug, the whole thing is going 2x faster than the previous version and is much simpler. This day I should have been working on a bullshit, internal politics-driven license module, and thus I disobeyed the manager. I couldn't think of anything else anyway, the code has to "get out".

A few days after, I showed my thing and the client royally ignored it, preferring to continue with fixing the older, shittier solution. After 10 or 20 minutes they finally caved and accepted to merge my thing. I don't understand the initial reaction at all.

The other things I wrote about are also non-issues (in practice). They are just ignorant. I could also write about the result of `parseInt(0.0000005)`, which could be more of a real problem.

> You can dismiss their objections as childish, but people are gonna write in the language they want to (or are paid to) write in. If there's a large body of existing python code they'd have to rewrite in JavaScript, or use some python in the browser route for their purposes, why should we force other people to use typescript because some of us think it's better?

An existing codebase can certainly be an obstacle in adopting a PL but I don't think that's the main motivation in practice.

> of course, LLMs, with their nascent ability to translate code into different languages, makes the question of rewriting something in a different language more tractable, but it's still a hike.

Entirely agree. In my current company there's quite a bit of reluctance to spend some bucks to have good tools and I resent it. Rewriting (quickly!) some Python into say, C++, would be absolutely great.

> The only reason to do something like this is if you only know Python and refuse to use anything else.

The ignorance and prejudice of most developers are staggering. They simply think "Javascript is shit", and all their arguments boil down to jokes about NaN and the weird behavior of ==. JS is (by far) not a jewel of a PL but it's telling that those people don't know anything about the real cursed and weird parts of JS (such as: eval does not behave the same depending on how you call it...).

As far as I know there's no simple and performant way to have the DOM be a function of the state with existing standards

Yeah I thought of this too. Wrapping this with Tauri should not be too hard, and quite space-efficient

Possibly a result of labor division? The more a business grows the more there are parasitic positions opening (see Parkison's law). Thus the selection of people whose work matches the intellectual mediocrity of their superiors (graphic designers in lieu of competent programmers)

Interesting take. One could argue that by adding async functions on top of classic and generator ones we now have three different colors for the functions instead of just tw.

Handling user inputs. Each time the generator yields you wait for a user input, and when you receive it you next() the generator with the input. It’s less verbose than using a bunch of methods, or the closest alternative I saw which is a switch/case on the index of the current operation. By using generators you just reuse the standard structures of the language.

Vue 3 follows a similar approach to Vue 2 (reactivity on objects, translates automatically to DOM updates). Although there have been some syntactic changes (such as the composition API).

Job-wise React is probably the better option, in terms of number of job offers you might get.

Vue’s smaller ecosystem has not proven to be difficult in practice. I think we could benefit form importing less dependencies in our projects anyway :)

React seems hard to use, ever-changing and generally not a good option on a technical level. I haven’t used it professionally but that’s the impression it’s given me

> Mathematics, especially, seems to have a strong tacit component.

It’s quantifiers, and bound and free variables.

The toolchain complexity problem was already present with Vue 2 (and anyway it was usable as a dependency pulled into a classic web page). It definitely could be better, and it seems to be on the way of being improved.

I feel like a lot of criticism toward Vue 3 is based on feelings and vibes. What exactly are your complaints toward v3?

Isn’t this inevitable if the user allocates each time a struct/array is created, rather than allocating upfront?

This is exactly what Justine Tunney's redbean does.

I used generators in the way you described in your last paragraph. And I added the possibility to "replay" the generators with the previous inputs except the last one. It provides a cheap way to have a kind of multi-step input process with cancellation.

What's the point of the empty string literal "" ?

But is it true that "clean code" makes the adaptation to changing requirements easier? I saw a few testimonies saying otherwise.

The performance difference is truly savage.

But I think there is a reason for the existence of "clean code" practices: it makes devs easier to replace. Plus it may create a market to try to optimize intrinsically slow programs!

I used a very similar pattern in a web app, in which the user creates objects by clicking in different places. There is a state built by each click, and it is convenient to just go back one or several steps behind sometimes. So you have something like

  const input1 = yield
  // arbitrary side effects, UI updates etc.
  const input2 = yield
  // ...

Each time the user makes an input, it is accumulated in a list, and sent back to the generator function. When the user decides to cancel the last step, a generator is recreated and rerun, with each yield sending back the user input that was stored in the list, except the last one. This requires writing the generator function in a particular way (you have to avoid setting "external" state), but it works and is more flexible than automata, I think.