[HN Gopher] A masochist's guide to web development
___________________________________________________________________
A masochist's guide to web development
Author : sebtron
Score : 155 points
Date : 2025-06-06 13:48 UTC (9 hours ago)
(HTM) web link (sebastiano.tronto.net)
(TXT) w3m dump (sebastiano.tronto.net)
| udev4096 wrote:
| What's with the use of port 48 for SSL? Any particular reason?
| sebtron wrote:
| Ah, that's a good question. It's kinda random (except that the
| name of the solver is "H48"). Setting up that web app required
| some extra HTTP headers (I explain that in the post), and the
| easiest way I found to do that without messing up the rest of
| my website was using a different port. https://h48.tronto.net
| redirects there too.
|
| Later I looked into a better way to do this, but I could not
| fully work it out. I use OpenBSD's httpd, which does not
| support setting extra headers, and relayd. At some point I'll
| take a look at this again, or I'll move the tool to another
| domain.
| wmichelin wrote:
| `var myLibraryInstance = away MyLibrary();`
| lerax wrote:
| Masochist? that's much more sane than the js clusterfuck
| ecosystem
| rapind wrote:
| "Clusterfuck" is implicit and may be omitted.
| broken_broken_ wrote:
| Good article, I also have a C program (a compiler) that I would
| like to compile to webassembly to offer a playground web page, so
| that is good information. Thank you!
|
| About the file system stuff: modern browsers ship with SQLite
| which is available to JavaScript (is it available to webassembly?
| No idea) so I would probably use that instead. Ideally you could
| use the sqlite API directly in C and emscripten would bridge the
| calls to the browser SQLite db. Something to investigate.
| lscharen wrote:
| > Notice I have changed the extension from .js to .mjs. Don't
| worry, either extension can be used. _And you are going to run
| into issues with either choice_
|
| As someone that has used module systems from dojo to CommonsJS to
| AMD to ESM with webpack and esbuild and rollup and a few others
| thrown in ... this statement hits hard.
| bubblyworld wrote:
| Yeah, modules in jsland are just trauma... now we have import
| maps in the browser too. Let's see what kinds of fun we can
| have with those.
| ajayvk wrote:
| A recent improvement in import map support in the browser
| https://shopify.engineering/resilient-import-maps
| SCLeo wrote:
| Yeah, the commonjs to esm transition has been the python 2 to
| python 3 transition of JavaScript, except the benefits are
| limited (at least compared to the hassle created).
|
| There are many libraries that have switched to esm only
| (meaning they don't support commonjs), but even today, the best
| way to find the last commonjs version of those libraries is to
| go to the "versions" tab on npm, and find the most downloaded
| version in the last month, and chances are, that will be the
| last commonjs version.
|
| Yes, in a vacuum, esm is objectively a better than commonjs,
| but how tc39 almost intentionally made it incompatible with
| commonjs (via top-level awaits) is just bizarre to me.
| divbzero wrote:
| I always assumed that compiling code to run in the browser would
| be slow, but OP points out that this is not the case. As the
| Emscripten project describes:
|
| > _Thanks to the combination of LLVM, Emscripten, Binaryen, and
| WebAssembly, the output is compact and runs at near-native
| speed._
|
| https://emscripten.org/
| RobRivera wrote:
| Yellow bus syndrom in action for me today.
|
| Last week I never heard of Emscripten.
|
| Integrating SDL for a project, there were CMake callouta for
| APPLE, MSVC, and EMSCRIPTEN.
|
| And here we are seeing it again on hn in a few days.
|
| I should put an afternoon aside for some deep diving on it for
| context.
| scubbo wrote:
| > Yellow bus syndrome in action for me today
|
| There's a certain irony to being able to introduce you to the
| term "Baader-Meinhof Phenomenon" (which is the more-common
| name for what I assume you're referring to, as Google
| searches for "Yellow Bus Syndrome" didn't bring anything up
| for me). Now you know the name, you'll see it everywhere!
| 57473m3n7Fur7h3 wrote:
| The colloquial term they were misremembering is "yellow
| car" effect.
| burningChrome wrote:
| >> the output is compact and runs at near-native speed.
|
| This kind of subjective, no? I wonder what they consider "near
| native speed"? I couldn't find any real numbers in their
| documentation.
| gspencley wrote:
| Not only is it subjective but V8 does so much to optimize
| JavaScript code that I wouldn't be surprised if the benefits
| for most applications were negligible anyway.
|
| Although JavaScript is still an interpreted language, it
| basically gets "compiled" when the browser parses the bundle.
| On the surface, the only thing WebAssembly automatically gets
| you is you get to skip the runtime compilation phase.
|
| I might be talking out of my ass, so take this with a grain
| of salt, but I wouldn't be surprised if once we start
| collecting real data on this stuff, SOME WebAssembly code
| could actually run slower than just using JS code. My
| hypothesis is that if you're starting with non-JavaScript
| code, you might be doing things in that language that would
| be slower to do the same way in JavaScript. I'm thinking of
| things like Array.map(), .filter() etc. ... which are hyper-
| optimized in V8. If you're taking an algorithm from C code or
| something which then gets compiled to WebAssembly, it's not
| an automatic given that it's going to compile to WebAssembly
| that is just as optimized as what V8 would do when it comes
| across those API calls. Again, this is just a hypothesis and
| I could be way off base.
|
| In any case, what we need is real world data. I have no doubt
| that for certain applications you can probably avoid land
| mines by hiring devs who are experienced building certain
| performance-critical things at a lower-level than your
| average JS dev... and their experience in those languages may
| transfer very well to the browser. In this scenario, you're
| not getting huge perf wins from using WebAssembly per-se...
| you're getting huge perf wins for not doing typical stupid,
| lazy, ignorant things that most average JS devs do ... like
| cloning large objects using the spread operator and then
| doing that over and over and over again "because
| immutability."
| aDyslecticCrow wrote:
| WebAssembly is still a flavour of assembly. It's only
| nearly native performance to the real code because the
| interface to JavaScript has overhead. Every action in
| JavaScript incurs overhead due to dynamic types and
| objects, as well as dynamic memory allocation and garbage
| collection. Wasm can theoretically ignore it all and run as
| if it were compiled for the host system, except when it
| needs to interact with the JavaScript environment.
|
| It's astonishing how fast JavaScript has become. But even
| if it were fully compiled, it would still be a language
| with higher overhead.
|
| You can still write bad code, or compile a language with
| high overhead into WASM. This remains valuable for porting
| existing libraries into the browser and reducing bandwidth
| usage. But properly done with a fast compiled language like
| c or rust.... wasm can unlock some magical things into the
| web ecosystem.
| knallfrosch wrote:
| Nice writeup! You definitely chose a pretty hard way, but the
| project setup is always the most complex part. Bonus points for
| immediately running into security/header issues, but my bet would
| have been CORS.
|
| At $WORK, we're also building with emscripten/C++. We'll add
| WebGPU/shaders and WebAudio for bonus pain.
| socalgal2 wrote:
| There is more here that is likely to cause problems in the
| future. One is the author's use of var instead of let or const.
| var continues to work but most JS devs have linters that ban the
| use of var. The issue is, var has function scope, not brace
| scope. Most non-JS devs coming from other languages will
| eventually run into this issue.
|
| Another issue porting native apps is, native apps are compiled
| for a specific platform and hardcoded to that platform's
| conventions. A good example of this is hardcoding Ctrl-C (copy),
| Ctrl-V (paste) at compile time, which maybe works on Linux and
| Windows but doesn't work on Mac.
|
| IIRC the way you're supposed to handle this on the web is listen
| for copy and paste events. AFAIK Unity has this issue. They hard
| coded Ctrl-C, Ctrl-P and so copy and paste don't work on Mac.
| Most games don't need copy and paste but once in a while someone
| does something that does need it, then exports to the web and
| runs into this issue.
___________________________________________________________________
(page generated 2025-06-06 23:00 UTC)