Is it just me, or would "single page applications" fit easily in the "examples" section there? Sounds kind of trollish when I write it out, but honestly, it fits pretty well, right? We threw away all the things the browser gives you for free and re-implement the back button, history, etc in JavaScript. (and it's somewhat fractal, as within the frameworks we use to do this you'll frequently see people re-implementing things the framework already does).
> "Our editor is written in C++ and cross-compiled to JavaScript using the emscripten cross-compiler... Pulling this off was really hard; we've basically ended up building a browser inside a browser."
Now sure, Figma's an exception, but it's an illustrative one. For most single-page apps, it's an interesting question. Is the web browser a monolithic platform where if you reimplement any of its layout engines etc. you're reinventing the wheel? Or, is it a set of libraries that can be chosen from at will, that of course happen to all work together to provide sane defaults, but by no means are required or expected to all be put into use simultaneously?
I tend to think of the web platform as the latter. Just because there's something in the "standard library" so-to-speak doesn't mean I'm forced to use it - the real question is whether it's something stable that won't force me and the team to yak-shave to maintain it. Mature JS/TS libraries are no worse than the browser in this regard!
It was probably the right tradeoff to make between 2007-2017.
Doing anything in HTTP/1 would make you reload your whole page slowly. Then AJAX came along and allowed you to build things that were more interactive and responsive. Gmail was a game-changer.
Since then HTTP/2 came along, and I feel like the industry has blindly continued on the HTTP/1->AJAX trajectory, without stepping back and re-evaluating how much HTTP/2 (and later) can do for us.
I came to that conclusion recently. The prevailing logic was to ask: how can i maximize readability?
This at first had me rip out everything i use to be proud of. Now i have single documents that do only one thing. I put these in folders that like the files have titles that describe what they do.
The whole thing looks like I started coding a week ago.
It all just works. It will continue to work. If something ever breaks it will be only that page. You will be able to see what is wrong instantly. If you paste the page into an llm it will most likely guess correctly what is wrong.
I'd mostly agree. SPAs can do things hard to do with URLs and form inputs; for instance, chess would be harder to program in the browser without JS (though I remember an opening explorer which worked that way). Or if you think about popping up a modal or a toast. But a lot of the functionality is duplicated.
This gets even more extreme now that you can have wasm on a canvas... The language that you're compiling from doesn't understand the semantics of a back button either!
SPAs are an inner platform within an inner platform, given that the web environment already is one. Canvas-based web apps are an inner platform within an inner platform within an inner platform.
It's true that some of the Web platform's downsides, rooted in its split identity between being a document library and being an operating system, are kind of similar to this antipattern, if you squint a bit, although they tend not to be as bad because the outer platform is much more robustly engineered than the average enterprise app.
The key difference is that, in the Web platform's case, there's not actually a better alternative on offer. Even with these awkwardnesses, it's still a better app delivery platform than desktop or mobile OSes, because it's dramatically less fragmented, has a more convenient "installation" story (https://xkcd.com/1367/), and has a better security model (at least compared to desktop OSes). So people need to write rich web apps with arbitrary behavior in it, which requires it to be arbitrarily customizable.
Contrast an enterprise app, where the lesson of the "inner-platform effect" idea is that code changes to the outer platform aren't as costly as you think, compared to unmaintainable configuration that interacts in complex ways with the platform primitives. So it's best to allow only customization simple enough to not pose maintainability challenges, and eat the cost of an outer-platform code change whenever you need anything more complicated. But Web developers don't have the option of getting browsers to add new code every time they want to add a complex new feature to their app, so browsers need to support a rich enough set of primitives that those features are already possible.
The other way to resolve the tension would be to get rid of the document-library features and instead double down on being an operating system, perhaps based on WebAssembly and <canvas> instead of HTML+CSS+JavaScript, like Flutter for Web uses. But of course people are using the document library, and in some cases it's the easiest way to do something, even at the cost of a little bit of redundancy at intermediate levels of customization.
What SPA critics typically want, of course, is for most sites to be satisfied with less feature-richness so as to fit more easily into the document-library model. But the platform has to support everyone's use cases, not just those of people who like HN's minimalist style. (I can't find it now, but there was a great comment on HN awhile ago that said something like: "A lot of HN users basically wish the internet was like how it was in the 90s, except with broadband. But in this respect, we're unusual; most users like features and slick UIs.")
> Web developers don't have the option of getting browsers to add new code every time they want to add a complex new feature to their app
We lack a mechanism for picking sane new features. Browsers add new stuff all the time. Most of it is horrible. [Say] Adding a js assembly has to be the most stuborn way of tollerating new langages. you may do it, as long as the new lang is js!? You can have butter as long as it is yogurt.
I dont like pyton. I wouldn't be upset by <script type="pyton"> add some of the dom tools to it and people will have a ton of fun. Might even be useful.
That makes total sense. I have been tempted to do this in the past. Fortunately time and resources constraints have kept it to costly sane and maintainable, performant configurations until I learned that I would never create the system I wanted and that it was probably better that I didn't anyways. I guess I've been lucky and didn't even know it.
Similar experience here. When I moved to a new place and had to find a dentist, the first one I went to told me I needed two root canals, even though I had been to my original dentist just 6 months before. The waiting room was filled with massage chairs and large flatscreen TVs (which would have been expensive 15 years ago).
Many airlines have had generally available models of tablets (such as iPads) to hand out on their aircraft lacking screens. eg. Hawaiian Airlines when they still had 767s.
The issue is not that tablets can't be used, but there must be ways to communicate safety information to everyone. On planes where tablets are handed out, there will likely be alternatives for the safety aspect, and on planes with non-working in-seat entertainment those alternatives may not exist.
Really depends on the aircraft. It reflects the age/generation of the aircraft and isn’t crappy just because it’s on an aircraft. 747s had, and A330/A380 still have, these issues. Slow CPUs, washed out colors, massive boxes taking up space under every seat. Not because it’s an aircraft but because it’s early 2000s technology.
Any newer aircraft reflects the advances you see in newer consumer electronics: if you’re on a 787 or A350 the screens are large, colorful, highly responsive, with a much larger selection of content, and none of the ugly control boxes taking up space because the screens are basically modern fast and slim Android tablets.
Which aircraft you are on is at best loosely correlated with the quality of in flight entertainment system you will use.
Seats are purchased by the airlines, they are made by separate manufacturers like Recaro or Zodiac and not by the airframe manufacturer (Airbus or Boeing). While the seats obviously need to be compatible with the airframe, there are a wide variety of options and it is common for airlines to refresh old airframes with new seats.
IFE systems are not manufactured by the airframe or the seat manufacturers, they are made by companies like Panasonic. They obviously need to be compatible with the seat, and my understanding is that it is uncommon for airlines to update the IFE system without also replacing seats.
So, while a newer aircraft type typically will have a more up to date IFE system, there are plenty of old aircraft that have new IFE and seats retrofitted.
The interior may be refurbished only 1-2 times during the economic life of the airframe, so the rule generally still holds. 747s are old enough that chances are, even the IFE tech installed during the refurb is outdated. A380s aren’t yet old enough to have had their interior refurbed for the first time, so their IFE tech is similarly outdated.
Here’s one example of why it takes ages — drivers that grab the window handle of a control panel and hack at it to show custom UI. Old example that specifically addresses the Displays and Printers control panels, but similar hacks probably still exist today.
To be fair, software and technology is so magically transformative that even with warranty disclaimers like “this software comes with no warranty, and we limit our liability to the purchase price”, every company in the world still lines up to buy it. Because for them it’s effectively magic, that they cannot replicate themselves.
No individual software developer, nor corporation, is foolish enough to claim their software is free of bugs, that’s why they put the risk on the customer and the customer still signs on the dotted line and accepts the risks anyway. After all, it’s still way more profitable to have the potentially-faulty software than needing an army of clerks with pen and paper instead.
Most software has to be this way or it would be exorbitantly expensive. That’s the bargain between software developers and the companies that buy the software. Customer accepts the risks and gets to pocket the large profits that the software brings (because of the software’s low cost), because it’s better than the software developer balking at the liability, no software being written at all, and having an army of staff every airport writing out boarding passes by hand. There are only a few softwares that aren’t this way - example the software in aircraft or nuclear power plants. That software is correspondingly extremely expensive. Most customers that can, choose to accept the risks so they can have the larger profits.
reply