Normalising running arbitrary code delivered over the internet (in the form of JavaScript and WASM), as a necessary condition for accessing most web pages may not have been one of the best decisions we have made.
That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap sandbox feature is really inspiring! It's really wild that (as far as I can understand this issue) someone is able to bypass it.
(Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.)
It's easy to be safer, as long as performance can be sacrificed for it.
Complaining about a relatively small performance price for Fil-C in that context honestly feels like that one famous newspaper photo of a smoking pregnant woman drinking a beer with a caption saying she's wbrried about the effects of the loud construction noises next door on her unborn child.
Except even that is wrong, because at least she had a point about the construction noises, while this is more of a "refusing to eat your vegetables" kind of situation.
It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.
It’s only very heavy calculations that see a boost in performance. But, realistically, how many websites require this or currently use this today? <1%? Maybe <.1%?
This is pretty typical across JIT engines, too. PHP also sees only a slight increase in performance from the JIT. Because of the nature of PHP applications, most time is spend on the network and database. Only very CPU-heavy code sees a significant speed up.
That’s even the case for C#, which is why the dotnet runtime only conditionally JIT compiles code. Only hot path code is eligible for JIT compilation.
It still uses a WKWebView today, even in the EU, despite Apple now allowing alternative browser engines in the EU as of 2 years ago.
I'm sure Chrome will eventually ship Blink+V8 in the EU. It will take some time
In synthetic benchmarks, there was a 40-80% reduction in performance when disabling the JIT. But in a simulated test on YouTube.com, the performance delta was only 6%.
This isn’t the best source as it’s a bit old, and it wasn’t just JIT that was disabled. But the core idea is the same: calculation-heavy code can see an improvement, but most code won’t. Why this matters is how people actually use JS on the web. It’s not for cryptography and such, it’s to manipulate the DOM.
Microsoft also has some benchmarks here: https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...
For PHP the RFC analyzes it: https://wiki.php.net/rfc/jit
We see a similar pattern: in synthetic benchmarks, the performance gain is large. But Wordpress, by far the largest PHP deployment in the wild, only saw ~3% performance gain. It again comes down to how PHP is used. It’s mostly HTML construction and database calls, neither of which will see any performance gain from a JIT. And, PHP has extensions, where most heavy code is moved to. Things like cryptography are done in PHP extensions, in C, where the JIT doesn’t matter. I’m more familiar with PHP, so I’ve known about the history of PHP not shipping a JIT due to the lackluster performance.
The only .NET implementations that interpret CIL were the .NET Compact and Micro frameworks due to hardware limitations, nowadays mostly gone as .NET workloads, and alternative implementations like Mono.
Yes, if your JavaScript engine is written in C++, it’s going to be very hard to avoid very gross bugs. We have better options now.
The ability of adversaries to find and exploit very gross bugs in C++ codebases should have already compelled the industry to move to memory safety. Now that AI has democratized the ability to scour C++ codebases for really gross and exploitable bugs, I should think that our hands are at last being forced. I’m not impressed by what I’ve seen in the industry with respect to taking memory safety seriously.
I also cringe at projects that "compile C to WASM" and then believe that it is immediately "memory-safe". (It really is not.)
The only exception for C/C++ projects is Fil-C which that is memory-safe. New projects at this point should just consider using Rust instead.
Sir, do you happen to have instructions for doing this? We who benefit from your philanthropy salute you.
Which is why I have NoScript in my Firefox and have gotten used to manually enabling javascript for select pages. Small price to pay.
Unfortunately the web is full of trivial websites that have no business running javascript. Recently wanted to read the famed post on Gates Notes. But for some reason Bill requires javascript to render text and images. Which reminded me Bill is not a person with good judgement on matters of IT and policy. Time saved.
They get emotional (usually angry) when you tell them you disable javascript- as if every site that serves any kind of content has an automatic entitlement to run arbitrary code on your computer.
There not a lot of reason to not have at least a fallback to serve your text-only content without JS.
This might oversell the agency that practicioners have.
Sandboxed zero-install delivery will outcompete anything with more frictionful installs.
It's probably not the right model for a pacemaker though.
Web/JS has been a double-edged sword for FOSS: sure, I can run a free OS, but if most of my "apps" happen to be JS that I can't practically control, then I have won a battle and lost a war.
There's also the problem of most free apps not doing a good job of providing license info and a link to source code, but this could be sidestepped by a trusted repository which provides license info itself.
I don't get it! The way JS is typically used, it doesn't even benefit from JIT all that much. Making ajax requests, doing stuff with strings, and moving DOM elements around doesn't need every CPU clock cycle to be used as optimally as possible. It's exceedingly rare for websites to actually be doing something that needs raw performance. And SPAs will be slow no matter what.
See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stuff, JIT wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like V8 and Node appeared, JS became ubiquitous. Pandora's container, if you will.
See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like compilers and standard libraries appeared, C became ubiquitous. Pandora's container, if you will.
Cute, but no, not even close to a good metaphor. The C example is abstracting away fundamental complexity in a new platform. The other is completely re-writing -- in duplicate and slightly broken -- what the platform gives you for free. There's nothing about implementing form controls or URL management in JS that is more abstract. It's just different; a downstream bad decision that branches off a long tree of other bad decisions.
The equivalent level of idiocy in a C-related metaphor would be...I dunno...if you decided that you didn't like the way that header files worked, and decided to keep the C compiler, but build an external header-file management system in Fortran [1] that calls the C compiler for you. Or even closer to the JS metaphor, you shipped a special C compiler that had an embedded interpreted language that only activated at compile time, and you then used that language to allow any user to fundamentally change the syntax of C.
(It hopefully shouldn't be lost on you that this exact approach to language features has been repeatedly tried in the javascript world, including right now, with package management. But see also: typescript, coffeescript before that, Dart, etc. Javascript is a mess, and history repeats itself with regularity about every 5 years.)
[1] ...and then you re-write that about sixty times, each time being slightly incompatible with the last, and all having different fundamental incompatibilities with C headers.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.
With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser developers. HTML/CSS/JS is a very powerful system, but it's also complex and can cost a lot of compute. When you understand this, then the reasons for React and other front-end frameworks become easier to accept.
I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalculated, potentially going up the tree as necessary. The only exception is if your script tries to get any layout-related property, e.g. offsetWidth. Then, as if as part of the getter of such a property, the layout recalculation will run immediately.
That is to say, if you need to make a lot of changes to the DOM, you should make them within one JS invocation so only one layout pass happens sometime after you're done.
The principle argument in favor of React today are developer ergonomics. People don't have to manually alter individual elements anymore -- they just describe state, and React takes care of the UI change set. On top of that, you have components, etc., that are debatably more pleasant to work with, and at the least create an ecosystem advantage for users of the framework. One can certainly see the argument for something like facebook, where there are probably dozens of different things changing independently at any given time.
But that said, one really has to question whether React makes sense anymore, given LLMs. Back when the alternative was that someone had to bespoke code every UI component, it might have been worth taking the hit of having to adopt the entire React ecosystem. But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
[1] Though sadly, many front-end devs don't know this.
[2] https://rossenahuh.netlify.app/React/react-concept-1---virtu...
> But now that LLMs are writing the code
Hopefully that's a temporary state of affairs and everyone will eventually go back to writing code by hand. I've never even considered using an LLM to get my job done, the whole idea is as alien to me as are these types of UI frameworks. To me, the best language to describe what you want from a computer isn't English, it's a programming language.
The popular coding AIs go down all the time. Last week all of them were down at the same time. If there's a bug causing losses of thousands or millions of dollars per minute, do we really want to let the LLM write incomprehensible code?
It's so that you have the page reflecting your data at all times.
The browsers should have been written this way, instead of having byzantine update functions with all forms and a pair of *Text to rule them all. But creating it in Javascript is a really bad idea.
One of my problems was that I wanted to show data in the browser. It is a convenient delivery platform, after all. However, Chrome (and Chrome in particular) has tremendous trouble displaying large pages. A 400x400 table takes a long time to render. I could solve that in JavaScript. I had to, really.
So, as practically always, the problems stem from a combination of factors, and bad programming definitely is one of them.
Sites are slow because with all that excess performance they do more tracking, instead of keeping the website as-is.
Because that's the only thing business managers can come up with in that situation. It's a misaligned goal of users vs businesses.
In my opinion the "user agent" behavior of browsers is long gone, because they're not acting on behalf of their users anymore. They're acting on behalf of businesses.
Uh…no?
You’re presumably talking about specific terrible prebuilt frameworks - not someone building a nice vanilla SPA.
Please stop changing the definitions of explicit words and phrases - to anyone reading this!
For example, a search function. For a MPA, each search query would be a new page. For a SPA, each query is a new logical page, served on the same real page.
Technically yes, a SPA may have minimal client side rendering. But then it’s not doing much of anything at all - it’s just a site. When people say SPA, they typically mean an application with client side rendering.
sigh
…does someone else want to finish this up?
To expand on what I mean, if the implication isn’t obvious: a SPA with no client side rendering is just a single HTML page. It’s a document, not an application.
So SPA naturally implies client side rendering.
The difference between a SPA and MPA isn’t the amount of pages, they both have about the same amount of logic pages. It’s about where those pages are rendered. Dynamically on the front end, or on the back end.
EDIT: okay okay to expand, my website has a contact form. With JS enabled, the form submit displays a little box that says “thank you for submitting”. With JS disabled, it navigates you to a “thank you for submitting” page.
Both are the same logic page, they have the same function. One page is just rendered client side, and one server side. Most websites or applications are hybrids. There’s very few true single page applications, and very few true multi page applications. Most SPAs have multiple real pages for different things. Most MPAs combine multiple logic pages into one real page.
> Most websites or applications are hybrids.
and some are emphatically not.
But…where were you going with that?
As soon as you, say, use JS to update the DOM or a canvas, I consider that client-side rendering. That you can do, and that would be a SPA.
But I’m curious, what are some examples, even hypothetical, of applications consisting of one HTML page? I don’t think I’ve ever seen it.
CSS (.css) JavaScript (.js) Plain Text (.txt) HTML (.html) SVG (.svg) Raster Images (.png, .jpg, .jpeg, .gif, .webp, .bmp) Audio (.mp3, .wav, .ogg) Video (.mp4, .webm) JSON (.json) PDF (.pdf)
plus bring in other source resources as needed.
To answer your question:
The installer for GrapheneOS / Google Pixel phones is an “SPA” (or “webapp”).
I’ve seen bespoke fitness trackers of all kinds,
appliance control apps,
budget and pace-tracking stuff,
basically all of what computer programs used to do - before we started dynamically loading a ton of extra stuff onto the screen that nobody needed to do the task they came to do.
So, they are truly inseparable IMO. You can’t have a SPA without some amount of client side rendering, your example demonstrates that. So, what makes a SPA a SPA is the rendering. A SPA is “single page”, but only in literal meaning. Logically, every SPA is many pages, you just render them purely client-side.
and none of this seems to have anything to do with the frontend being a single page.
Could you point out where you think the gotcha is? I can taste the tone.
Just because a bunch of engineers applied implicit meaning that didn’t exist to a very literal phrase for a few years doesn’t make it correct.
Doesn’t make webapps inherently bad.
Doesn’t make SPAs bad.
At this point, app pretty much implies React - ask an LLM for an app and see if that’s not what you get.
especially when you’re writing your own stuff,
that’s when you know from the start that scaling doesn’t matter! =]
Related, and more powerful than my comments in this thread are going to be:
So you have to guarantee that your product will stay low users and low features forever or spend a very high effort to try to partially overcome that block when you change your mind.
And guaranteeing that it will stay low features is much harder than low users I think.
In exchange for that you get a better talent pool for recruiting but does that matter if your product has to stay low scale anyways?
It can work for some SaaS but if you stay low employee count, low users and you have a core feature used everywhere in the whole product and nothing else
Feels like a glaring omission =]
> Is it being used even sort-of in the right place / way?
It's a SaaS where users are mostly always logged-in, kind of an app so you would think it should work from the outside.
I think these are the full requirements I would put for a good SPA experience:
- low users
- low number of features / or a single main feature reused in different ways
- low number of employees
- it's an app and not a website
- you don't have any users living in remote places / poor internet connection
- users are all using modern browsers and can be asked to switch to another one if needed
And I think in my company we only have one of this list, making it painful.
at any point,
I’ll be checking back around later!
Until then: just talk smack about React!
None of these things you listed are critiques of single-page apps (SPA).
I'm sure counter examples of well managed SPAs do exist somewhere, it's just that it seems much easier to do the wrong thing compared to a traditional stack. This is why I'd not advise for it unless you have a very good reason.
The good stacks should make the good choices the natural way to do things, again my opinion.
We need simpler protocols and formats, especially those that are used over the internet. I want everyone to really start fighting for this.
I always use a browser that doesn't run any scripts (w3m) for both this reason and others. It hurts when I see websites that don't work without js. A bit funny though that this page is one of them so I was not able to read it.
But we do! It doesn't get much simpler than HTML/CSS/JS. It's just abused to make apps instead of web documents.
Wikipedia is basically the most popular application of all time and it doesn't rely on javascript. People just generally don't give a shit about where their money goes.
The whole biosphere is over there in the corner, weeping.
(I keep WASM and WebGL disabled in Firefox settings, too. Yes, I had another post ITT questioning why those things are any less secure than the JavaScript, given that they're supposed to be in a sandbox. But you know, defense in depth. It's insane that we're expected to put up with these grossly unnecessary risks all the time. Just like how it's insane that frontier models are being tested in environments that are physically capable of connecting to the Internet at large.)
I am decidedly uninterested in those features for most web pages I visit. Should they be able to spin up my CPU fan just for that I would consider it a misfeature. Just like a movie on high volume would be.
If anyone familiar with Firefox could implement that or point in the right direction, that would be most welcome.
Do you remember what the alternative was? Flash, Java, ActiveX. No thank you.
Sure security is difficult but vulnerabilities of this magnitude are rare. If anything the lesson is don't write highly security sensitive software in C/C++.
Like cellphones, javascript became necessary if you want to use webmail, access your bank's website, or whatever.
It's the classic thing. Across every gdmf metric, excluding with "true empathy", no one *gives a fuck* until it affects them, or someone within (1-3) degrees of separatation. And having broad empathy is generally a good way to get yourself labeled/astrocized: both about as obvious "compriate" and obvious "adversary".
astrocized - banished to outer space.
I do know how to spell ostracized ? I'm not sure if that's what I meant? Truly a mess.
It's not the Bonzi-buddy and driveby-installed IE toolbars wild west of the early 00s.
Can you please provide a link to a page where a “toolbar drive-by install” occurs?
In the early 2010s you had to have JS enabled for many sites to work at all. The cost:benefit equation had became entirely different.
The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?
You can prove that your code terminates (or rather responds to events in a finite time, even if the event loop itself runs forever.) Or you can even prove that your code reacts quickly, ie within some time limit. You can also prove memory limits.
> The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?
Defense in depth. And you can have competing implementations relatively easily for this, and another way to find and report bugs. Especially if the verifier is open source.
The verifier itself can be pretty simple: it's the prover that's complicated and needs smarts, but that's being run on the author's computer, not in the user's browser.
As a practical counterexample, the Linux kernel has a verifier for eBPF code that is loaded by untrusted users. That is a much more constrained environment than JS, but they still constantly have verifier bugs. It's so bad that distros almost universally distrust the verifier and instead set things up s.t. only root can load any eBPF code.
The security implications are just the cherry on top.
But, anyone who thinks we need JS for a functional internet is fucking retarded