> 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.
You can do very complex stuff without any need for React like approach. I literally said I've written a very sophisticated framework that was exceptionally snappy - that's what should be used for that 1% (not my framework, but the approach). Even better, I could introduce it very gradually and strategically on different SSR pages and then (if I wanted to) I could turn the whole app into an SPA - all without needing to "render" anything with JavaScript, VDOM or other such nonsense.
Is this framework public? I think the same way as you and developed my own framework with/out the things you mentioned and would like to compare my approach with yours. Biggest difference is that I use lit-html for templating, which is quite efficient.
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
CSP tells the browser where scripts and styles can come from (not just inline, but origins/domains, too). Let's pretend that an attacker can inject something into a page directly (like a SQL injection, but HTML). That script can do just about anything, like steal data from any form on the page, like login, address, or payments, or substitute your elements for theirs. If inline resources are forbidden, the damage can be limited or stopped.
with $user being equal to `<script>/* sending your session cookie out, or the value of the tag #credit-card etc. */</script>`
you will be surprised how many template library that supposedly escape things for you are actually vulnerable to this , so the "React escape for me" is not something you should 100% rely on. In a company I was working for the common vulnerably found was
`<h3> {{ 'hello dear <strong>$user</strong>' | translate | unsafe }}` with unsafe deactivating the auto-escape because people wanted the feature to be released, and thinking of a way to translate the string intermixed with html was too time-consuming
for inline style, it may hide elements that may let you input sensitive value in the wrong field , load background image (that will 'ping' a recipient host)
with CSP activated, the vulnerability may exists, but the javascript/style will not be executed/applied so it's a safety net to cover the 0.01 case of "somebody has found an exploit in
What you use as an example has nothing to do with inline/"external" scripts at all, but everything to do with setting DOM contents vs text content. Most popular frameworks/libraries handle that as securely by default as one could (including React) and only when you use specific ways (like React's dangerouslySetInnerHTML or whatever it is called today) are you actually opening yourself up to a hole like that.
If you cannot rely on the escaping of whatever templating engine/library you're using, you're using someone's toy templating library and probably should switch to a proper one that you can trust, ideally after actually reviewing it lives up to whatever expectation you have.
my point is that all your templates are at thend coded by human that make mistakes https://nvd.nist.gov/vuln/detail/CVE-2024-6578 , you may be not using "dangerouslySetInnerHTML" directly but your dependencies may
> What you use as an example has nothing to do with inline/"external" scripts at all, but everything to do with setting DOM contents vs text content.
I fail to understand your point (it's certainly an understanding problem on my side)
What I wanted to express is that:
1. you can with some CSP forbid loading of cross origin script (i.e forbid hacker.ru/toto.js ) to be loaded
2. but even if you do this, you also want to block inline script (or use inline+nonce) because evil script can be executed from within your origin by using a vulnerability somehwere between the code and the final dom
> This would have been the exact same hole regardless if it was put there/read by external/inline JavaScript.
yes we both agree that it's the same vulnerability at the end, i'm just saying that you can arrive there from different path, and these different path are protected by different CSP mechanism
first, at the end the effect is the same (XSS which can be used to extract information), the difference is "how someone can get to it" and "how you protect yourself from it"
1.to be honest you should refrain yourself from loading resource outside of domain you control
2. even if you do, you can protect yourself from somebody replacing jquery.js by something totally different by using <script integrity='the_hash'>
3. if it's a CDN your control it's usually quite hard to inject something into the resource because a potential hacker has no obvious input on it (and you still can protect it by using the above script integrity=
4. so then most people feel safe and forget that inline script can still be dynamically created if you have a hole in your libraries generating DOM code, so this path of attack need to be blocked completly (forbidding inline script at all) or protected (using nonce)
sounds weird to me too, although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script - about the only way I can think of it being bad.
> although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script
Wouldn't even matter, as it's the origin of wherever it ends up being executed that matters, not where the code was loaded from. So JS code loaded from cdn.jquery.com on mywebsite.com would have the origin mywebsite.com, even if loaded with a typical <script> tag.
In short, CORS applies to network requests made by scripts, not to the scripts themselves
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 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...).
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?
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.
> 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.
I mean, these things aren’t static. Python may be the second most popular language (behind JS/TS) today, but what if elixir takes over 10 years from now? There is no need for browsers to implement every language-of-the-day.
Additionally, browser JS adheres to a quite strict backwards compatibility requirements. Python can and does deprecate and remove APIs, and I would imagine the community would not like to lose that flexibility.
WASM is probably the best bet here, in that it provides a well-specified low-level target, such that the door is open for other languages for anyone who is allergic to learning/using javascript.
I design my web components so they emit custom events and provide methods for parents to mutate them/trigger re-renders. This might not scale to huge apps but I don't have any interest in working on something like that.
I understand the benefits of the mental model, but the tooling that delivers that generally have a lot of complexity that isn't trivial to parse and understand. I think the benefit of being able to parse and understand your abstractions (ones you build yourselves or buy off the shelf like a framework) is there are always gaps in the constraints under which they had originally been designed; so you'll always need to understand how it works under the hood.
React's class-based components were simpler because the lifecycle methods were explicit, but the hook-based model is "easier"; however, the component lifecycle is still present. The demo code does look really clean, but in real life you quickly start to face the underlying complexity of the abstractions (e.g., useEffect, memoization, realizing how fine-grained your reactivity is is based on how you've drawn those component boundaries). You can write these optimizations yourself, or wait for the new auto-memoizing React compiler to land, but in all cases, the overall complexity remains the same (or is higher). And this isn't unique to React or other frameworks, and you'll always need to delve a little deeper.
I agree that the DOM APIs could be more declarative (e.g., declarative custom elements proposal [1], declarative shadow DOM, `@scope` CSS as another way to scope styles), and there is activity in that space, both in the W3 Web Components Community Group and the Open UI Community Group. I'm trying to get more involved in those discussions and I'd recommend everyone who cares about the web and how we build for it to participate.
I think the process of standardization for new features (through the proposals phases to finally landing in browsers) is the effort to raise the floor for all to build on top of. I remember when Promises were landing everywhere and feeling a little overwhelmed by what it meant to me because I was using Bluebird. Then the feeling of "maybe I can simplify what I'm doing and lean more on the platform" set in. Frameworks are a testbed for new ideas, and we can go further by trying to see what pieces we can pull out and standardize around (e.g., Signals proposal [2]), so we can go back to testing new ideas on top of that.
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)
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