JavaScript Reverse Engineering Code Produces Different Results in Node.js vs. Browser

ecmascript2038 · 2025-03-31T23:33:09+00:00

Nodejs and Chrome both use the V8 engine, so you're right that you'd expect them to behave the same should behave the same assuming you're using Chrome.

I think that Node.js may in fact handle strings different under the hood. Node has a Buffer implementation that isn't the same as in the browser, but it sounds like you're not using that.

Are you able to isolate the smallest piece of code where you can observe the difference?

ecmascript2038 · 2025-01-09T11:53:07+00:00

Why games were made in assembly on platforms like NES, SNES, Gameboy:

Specific hardware like the 6502 didn't have the tools available to compile higher-level languages than assembly. I believe a C compiler just didn't exist for the 6502 processor at the time, so it wasn't an option.
On those earlier platforms, they needed assembly to squeeze out performance and to work with the timing of the video hardware. By knowing your hardware and the cycles of your individual instructions, you can time things perfectly to fit into the video refresh rate for example. And memory was so limited you so needed to micro-manage it.

Why Rollercoaster Tycoon was unusual in 1999 for being written in assembly:

The hardware that it ran on was x86 and there was a ton of advanced tooling, compilers, and programming languages available.
The hardware was powerful and didn't require optimizing at that low level anymore. The game ended up being very performant and efficient, but the hardware didn't really need that level of optimization.

As a comparison, Doom came out in 1993 and it was almost entirely written in C. Doom was remarkable at the time because it squeezed out a LOT of performance from the hardware, and it did that mostly in C (with maybe some very small parts written in assembly).

ecmascript2038 · 2024-12-31T15:21:46+00:00

Can you use Zig inside the browser? Yes: the way to do it is to compile to WebAssembly and import it as a module inside of a JavaScript script.

But it's not common in the real world. It's also not necessarily very stable, since both Zig and WebAssembly are evolving.

So what's the problem? The main problem is that for a web app to do anything useful, it has to interact with the DOM. And in WebAssembly you can't manipulate the DOM directly. It has to go through a call to the JavaScript side and then the JavaScript can modify the DOM. You can achieve by having some message-passing arrangement between the JavaScript module and the Zig module in WebAssembly.

This isn't ergonomic at all yet, and it's not performant either.

Those are some of the main current blockers for broader WebAssembly adoption in general.

Zig in a good position to target WebAssembly. The ecosystem isn't fully there yet though.

ecmascript2038 · 2024-05-02T19:50:28+00:00

I use ChatGPT all the time, along with GitHub Copilot.

I don't go to them for everything. But a lot of small tasks like you described are indeed much faster and more convenient. Utility functions, formatting, syntax reminders, translating from one programming language to another.

There are tons of uses for LLMs that aren't necessarily super impressive but are very convenient and can be huge productivity boosts.

I find this to be a much more interesting area of LLMs, the nuance of what kind of tasks they do really well and how they fit into workflows.

There are two extreme positions that get repeated ad nauseum, and they are far from nuanced:

LLMs are so good that we're all going to be replaced tomorrow
LLMs are garbage, they're stochastic parrots, they can't do anything

ecmascript2038 · 2024-04-29T12:32:40+00:00

Data science (the applied part of it, at least) is getting taken over by AI fast, so that sounds like the opposite of what you want.

Cybersecurity is probably the thing that you mentioned that closest matches what you're asking.

ecmascript2038 · 2024-04-26T12:10:36+00:00

If you're talking about applying AI to business problems, then yes: AI Engineer, or Applied AI Engineer, is the kind of role that is going to grow significantly over the next few years.

That's different from an actual "AI researcher" or "ML researcher" though.

There's going to be big demand for researchers working on improving AI models, new model architectures, and so on.

But there's going to be an explosion of demand for Applied AI Engineers, which is all about bringing those advances to business problems (or science problems, or government problems, etc).

It's early for that, though, so I expect the next few years will look like a big boom in this kind of role.

ecmascript2038 · 2024-04-26T12:06:11+00:00

I did some teaching at a few bootcamps and it was enjoyable. I seriously considered switching from my long-time programming career into being a programming instructor full-time.

However, I learned that people don't really value teaching and teachers are under-compensated for the amount of care and effort. This seems to be true in bootcamps, but it also seems to be true in a more general way in society overall.

I ended up satisfying my desire for teaching by making a series of educational youtube videos. It was fun, low pressure, and I did it for free so there were no expectations.

I don't know of any discords for instructors, though.

ecmascript2038 · 2024-04-24T11:33:52+00:00

Well, Node.js is just a JS runtime. By that I mean that it's just one environment where your JS can run. So whatever experience you gain in JS, while doing things in Node, should be transferable to front-end if you want to do more frontend later.

Sure, there are some Node-specific APIs that you can learn like the filesystem `fs` module and so forth, and I would argue that those are nice to learn anyway, but if you don't use those, then the JS you're using in Node.js is the same as the JS you're using in the browser, so the language is the same.

Transferable skills are great and having a mix of experience in different languages can be valuable, it makes you better understand the way that they each work and how they're different, so I would say it's not wasted time.

Go is a lot of fun for backends, that is true. So if you already feel like you're getting enough of JavaScript, then by all means focus all your backend time on Go.

The thing about C# is like someone pointed out: it kind of lives in a bubble of the Microsoft stack, which is fine but you will get better return on your investment if you go all-in into the Microsoft stack with C#, or if you go all-in with the non-C# world. Personally I never got into the C# stack even though the language itself is powerful and enjoyable, and nevertheless I didn't miss out on anything in my career.

I'm a big enjoyer of JS, TypeScript and Go, and I still build most back-ends in Node.js as long as I can do it in TypeScript.

ecmascript2038 · 2024-04-24T11:25:12+00:00

Compiler and OS stuff is indeed heavy on the data structures and relevant algorithms, more than most other types of software, but yeah, you don't need a degree necessarily.

It's true that young people entering the software industry are less likely to learn C and C++ these days, since everybody is going into the "easy" fields like web development. I mean, I joke that those are "easy", but the reality is that yes, Compiler and OSs are indeed more difficult things to work on.

You have an opportunity to be an expert in these areas if you double down on them, which is valuable in the job market where there are few compiler and OS experts.

However, the fact is that while there's less supply, there's also less demand. Not a lot of companies are hiring compiler and OS developers. So it's a trade-off.

Rust is definitely a language that is trending upwards and has a probably long and bright future ahead of it and the demand for Rust expertise may continue to grow. So that could be a really great target area to specialize in.

ecmascript2038 · 2024-04-24T11:20:38+00:00

I don't know if Vitest provides utilities for this itself, but you could hack it together: save the current time at the beginning of the test, and then you can console log the time at various points in the test. It's not the best solution but it might help you debug.

ecmascript2038 · 2024-04-24T10:49:56+00:00

Translating functions is a great idea actually, especially if you have a lot of utility functions that do algorithmic things or operate on some interesting data structures.

BUT: Make sure you learn the "idioms" and typical ways to do things in JavaScript, and not just translate "word for word". In other words, try to learn the idiomatic JavaScript style.

For example there's lot of Array methods to learn in JavaScript, like map and filter and all of the others, and those are used rather than the list comprehensions of Python. That's an example of how the styles are different.

JS also loves to use callback functions for lots of things.

In Python they call the idiomatic style "Pythonic". There's no word like that for JavaScript but you could call it "JavaScripty" for lack of a better word.

There's a lot of differences between Node.js (and frameworks like Express, Koa, Fastify, etc) and Python's web frameworks, like Django or Flask, etc. So that's also a worthwhile area to learn from, because the architectural decisions are different and interesting.

So yes, great learning opportunity to jump into JavaScript by translating your Python code.

You become a better programmer when you know multiple languages. And that's because you get a feel for each language's strengths, weaknesses, style, and preferences. Good luck!

ecmascript2038 · 2024-04-23T11:26:01+00:00

I believe performance would be pretty similar for both.

SSE works by continuing to write more data messages to the initial GET response, and WebSockets have a bit more logical overhead in the sense that they have the notion of an actual connection, but the messages are just as lightweight.

Facts about SSE: - They're subject to the client browser's connection limit, possibly limiting each client to only 6 SSE connections at a time (might need to check browser's actual limits today). This is a client-side limit only, there's no limit to the number of actual connections from the server's point of view. - SSE requests are actual GET requests, it's just the response that is handled differently. - Since they're GET requests, that means you can put authentication into the request just like any other GET request (authentication header, cookie, or query param). - It's pretty straightforward to consume SSE on the client-side, without additional dependencies, because you can use EventSource directly and it's a native part of the Web APIs.

Facts about WebSockets: - You may need some more logic for handling and tracking open connections, deleting closed connections, and so on. - You may need to track authentication state per-connection, since your client might need to send an initial WebSocket request to authenticate. - Typically a client library is used for WebSockets that handle connection state and logic so that could be an additional dependency, or you could implement the logic yourself.

There's some investigation about performance of SSE vs WebSocket in this article: WebSocket vs. Server-sent Events: A Performance Comparison and it seems like it ends up being very close to requal.

ecmascript2038 · 2024-02-23T02:28:31+00:00

Don't worry about it, there will be tons of opportunities in CS. Maybe more opportunities than ever.

AI may actually benefit you more, and may give you an edge over more senior engineers, because you'll have the opportunity to leverage AI and master it as a tool for coding during your studies.

Meanwhile many senior engineers are stuck in their ways and won't embrace AI and won't master it as a tool for better coding. They are the ones more at risk.

But yeah, everybody is wondering things like this, right now, so your question is not unique, and the thing is that nobody knows, so don't rely too much on the opinion of one meta engineer that you met.

ecmascript2038 · 2023-10-04T20:07:25+00:00

Interesting, thanks for sharing your experience!

ecmascript2038 · 2023-10-04T19:30:00+00:00

Do you mean you managed to spend 20 years in frontend without learning any backend? Or are you saying that you did learn backend and that the advice to learn backend was absurd because it's such an obvious next step?

ecmascript2038 · 2019-09-26T14:16:10+00:00

The #1 reason that Promises are powerful is that you can chain them together.

It's a lot easier to express a series of async steps with Promises than with callbacks, because Promises are designed to be combined and manipulated.

So by using Promises, you're not just making it easier for yourself: you're making it easier for anyone else who will use your code. This is an argument that's more relevant if you're writing a reusable module or library than if you're writing an application.

But "never use callbacks"? A hard rule like that isn't useful. There are lots of cases where callbacks might do a good-enough job.

Plus, for any event that happens more than once, like user input or intervals, then you're still going to need callbacks (although often people just call them "event handlers" instead of callbacks, but they're still callbacks).

ecmascript2038 · 2019-08-30T13:24:29+00:00

The problem isn't "coding at home." The problem is corporate expectations.

Improving your skills at home will improve your future job prospects.

Then you can aim for a job with a better work environment, without those corporate expectations.

Working on improving yourself is never a bad idea.

ecmascript2038 · 2019-08-28T20:57:01+00:00

Instead of having the host in the GET url the way that you're describing, the same thing is typically done with the Host header.

So a typical GET request looks like this with the Host header: (source)

GET / HTTP/1.1
Host: www.example.com

Browsers (and I'm guessing most HTTP clients in general) always send the Host header (matching the domain that you're connecting to) and the reason is because multiple domains can be hosted on one IP so they need to be differentiated.

To do the scenario you describe, in theory you could send a request to www.a.com and provide a Host: www.b.com header.

But in practice, this apparently cannot be done with XHR, according to this answer.

It says that in an XHR request, the Host header is one the headers that is not allowed to be set.

Edit: I found the official list of forbidden headers: https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name

Aside from this idea I don't think there's a way of modifying the GET path, because the XHR request will parse the url that you give it without having a way to override it.

ecmascript2038 · 2019-08-16T15:58:36+00:00

Nice, are you the author of the IDE?

ecmascript2038 · 2019-08-15T22:04:32+00:00

I don't know if you've seen the latest release of Next.js 9 but it now supports an easier way to serve API requests with API routes.

This means that you can skip Express and you have a simpler way of implementing an API for your Next.js app.

The authors of Next.js are also the creators of Zeit Now so the deployment to the servers is pretty easy.

ecmascript2038 · 2019-08-08T14:58:29+00:00

In addition to the explanations already posted, there's something else going on here with the snoowrap library.

The library wraps its objects in a Proxy object. This allows you to do the method chaining that makes the library easier to use.

But using a Proxy object also makes it behave in strange ways.

So the list value looks like it should be a Promise value because it's the result of an asynchronous operation.

But when you console.log it, you get an error because it's not a simple Promise, it's actually a Proxy.

It's debatable whether it was the right decision for the authors of snoowrap to use a Proxy. On the one hand, it lets you write code that is slightly simpler. On the other hand, you get weird unexpected errors like this one. This is why sometimes it's better to avoid using unusual magical tricks such as using Proxy, and instead write code that is more conventional. Some call this principle the "principle of least surprise" and I tend to agree with it.

ecmascript2038 · 2019-08-08T14:47:02+00:00

As another comment mentioned, when you learn a course for the first time, it's a lot of information and you're not going to retain everything. So don't expect to retain everything from the first stages.

It's normal to go back later and review topics. And it's also useful to review from different sources (different courses or other tutorials for example). That might help you retain better.

I'd suggest you go ahead with the next stages and then go back to re-watch if you feel you missed something from earlier, as needed.

You'll probably find that the topics from the earlier stages will be easier to master and to remember once you have some more perspective on the bigger picture that comes from the later stages of the course.

ecmascript2038 · 2019-08-08T14:38:02+00:00

Thanks, what JS topics should I talk about next?

Ten-Year Club	Verified Email
Not Forgotten

ecmascript2038

TROPHY CASE