Comment by microtonal
3 years ago
This drives me crazy, especially because it breaks finding within a page. Eg. if you order food and you already know what you want.
Old days: Cmd + f, type what you want.
New days: first scroll to the end of the page so that all the contents are actually loaded. Cmd + f, type what you want.
Is just a list of dishes, some with small thumbnails, some without any images at all. If you can't load a page with 30 dishes fast enough, you have a serious problem (you could always lazily load the thumbnails if you want to cheat).
Well, the tech stack is insane: Some virtual machine running a web browser process running a virtual machine for a html renderer which consumes a document declaration language incorporating a scripting language to overcome the document limitations trying to build interactive programs.
Actually much worse as Microsoft once did with their COM model, ActiveX based on MFC foundation classes with C++ templates, etc.
And to build those interactive programs somebody is trained to use React, Vue, etc. using their own eco systems of tools. This is operated by a stack of build tools, a stack of distribution tools, kubernetes for hosting and AWS for managing that whole damn thing.
Oh - and do not talk even about Dependency Management, Monitoring, Microservices, Authorization and so on...
But I really wonder - what would be more complex?
Building interactive programs based on HTML or Logo (if anybody does remember)?
Ironically these instant starting NT applications were often using COM.
As much as I hated developing with COM, the application interoperability and OLE automation is a form 90s tech utopianism that I miss.
Indeed.
On one project, I actually shifted quite recently from working on old-school, pre-Windows XP, DCOM-based protocols, to interfacing with REST APIs. Let me tell you this: compared to OpenAPI tooling, DCOM is a paradise.
I have no first clue how anyone does anything with OpenAPI. Just about every tool I tried to turn OpenAPI specs into C or C++ code, or documentation, is horribly broken. And this isn't me "holding it wrong" - in each case, I found GitHub issues about those same failures, submitted months or years ago, and still open, on supposedly widely-used and actively maintained projects...
2 replies →
In some ways COM is pretty optimized. An intra-thread COM call is just a virtual function call - no extra overhead. Otherwise it's a virtual function call to a proxy function that knows exactly how to serialize the parameters for IPC.
1 reply →
I think of the OLE demos every time I shove a google sheet into a google doc and realize it’s only a one way sync.
WinRT is COM under the covers
Well, the way in which we got there is in adding more features to the "obvious" answer: all any given site necessarily has to do, to have the same presentation as today, is place pixels on the screen, change the pixels when the user clicks or types things, and persist data somewhere as the user does things.
Except...there's no model of precisely how text is handled or how to re-encode it for e.g. screen reading...the development model lacks the abstraction to do layout...and so on. So we added a longer pipeline with more things to configure, over and over.
But - the computing environment is also different now. We can say, "aha, but OCR exists, GPT exists" and pursue a completely different way of presenting many of those features, where you leverage a higher grade of computing power to make the architectural line between the presentation layer and the database extremely short and weighted towards "user in control of their data and presentation". That still takes engineering and design, but the order of magnitude goes down, allowing complexity to bottleneck elsewhere.
That's the kind of conceptual leap computing has made a few times over history - at first the idea of having the computer itself compile your program from a textual form to machine instructions ("auto-coding") was novel and complex. Nowadays we expect our compilers to make coffee for us.
And don't forget the UX designers armed with their figmas and alikes. The tech-stack is only one among a number of organizational and cultural issues crippling the field.
Howdoes figma contribute to laggy UI of the end product?
1 reply →
> But I really wonder - what would be more complex?
> Building interactive programs based on HTML or Logo (if anybody does remember)?
Hold my beer: my Github Actions CI scripts use Logo to generate the bash build scripts as images that are then OCRed and executed by a special terminal that exploits the Turing complete nature of Typescript's type system.
Turtles all the way down!
Here's a fun fact, most fonts have a font program written in a font specific instruction set that requires a virtual machine to run. There is no escaping the VMs!
A VM is not a VM. Just because a program’s semantics are defined in-terms of “a” virtual-machine (Java, .NET, etc) - it’s otherwise entirely unrelated to virtualisation.
3 replies →
Virtual machines don't add much overhead.
That may be so, although a VM on AWS is measurably slower than the same program running on my Xeon from 2013 or so.
But, more generally, the problem is that tech stacks are an awful amalgamation of uncountable pieces which, taken by themselves, "don't add much overhead". But when you add them all together, you end up with a terribly laggy affair; see the other commenter's description of a web page with 30 dishes taking forever to load.
8 replies →
That depends how much overhead is in the VM. WASM is designed to be thin. Java is not.
Except for when they do.
And then came WASM...
WASM is designed to cut through all the bullshit and leave only a minimal amount of bullshit, even though it turns out there's still a lot of bullshit in the other parts of the system that WASM doesn't address.
I like websockets for the same reason. Each message has a two byte overhead compared to TCP. Two bytes. Unfortunately messages sent by the client have a whopping four additional bytes to help protect buggy middleboxes.
> New days: first scroll to the end of the page so that all the contents are actually loaded. Cmd + f, type what you want.
Only to discover that 2/3 of the matches are invisible text that's put there for $deity knows what reason, and the rest only gives you the subset of what you want, as the UI truncates the list of ingredients/toppings and you need to click or hover over it to see it in full.
If you think that’s enraging just wait until you get a page that unloads the previous content as you scroll. You can only search the text that’s visible. Maddening.
Or even worse, Cmd + F doesn't work because the page is lazily rendered.
Like GitHub's new code viewer! I have to load the raw text just so I can use Ctrl-F!
Someone should invent a way for a web server to return a representation of the text, complete with styling and formatting that the browser can use to render it.
Twitter does that and I don't understand why. Do they think their js blob can figure out which divs to render faster than the browser engine itself?
I am in no way a front-end person, but my understanding is that it has to do with React and the way it maintains a virtual copy of the DOM.
Having Ctrl-F not work correctly is maddening and I hate it.
3 replies →
I miss typing / to search on pages. Ctrl-W still messes me up at times when using a terminal in a browser.
Firefox allows you to use / to start a conventional search.
As a bonus, in Firefox if you hit the ' key (apostrophe) you get a search that looks only within hyperlinks and ignores all the un-clickable plain text. Give it a try, sometimes it can be very useful
You can search with / on Firefox.
Unless you're on github.com, because it rather inconsiderately takes over `/`.
' will search in URLs, skipping plain text.
Firefox lets you use / for search.
vimium / vimium-ff
>If you can't load a page with 30 dishes fast enough, you have a serious problem
That depends on your scale. If your product is "large enough" it is relatively easy to get into the range of several seconds of response time.
Here are some of the steps you may want to execute before responding a resquest to your user:
- Get all the dishes that have the filters the user selected
- Remove all dishes from restaurants that doen't delivery in the user location
- Remove all dishes from restaurants that aren't open right now
- Get all discount campaigns for the user and apply its effects for every dish
- Reorder the dish list based on the history of the user interactions
Now imagine that for every step in this list you have, at least, a single team of developers. Add some legacy requirements and a little bit of tech debt... That's it, now you have the perfect stage for a request that takes 5-10 seconds.
Dafuq kind of scale could even a service for lots of restaurants have, that that wouldn't be a single query taking milliseconds to execute? I'd maybe split the last bit (user history re-ordering) into another operation, but the rest, nah, not seeing it, one quick query, probably behind a view.
I mean maybe your DB is a single node running on a potato and your load's very high but you're also somehow never hitting cache, but otherwise... no, there's no good reason for that to be slow.
[EDIT] Your last paragraph is the reason, though: it's made extremely poorly. That'll do it.
Recently I stumbled across the online catalog for Segor Electronics (segor.de I think? Google it. Only in German. They're not paying me to post this)
It's extremely fast. Super duper fast. And a quick look at the network debugging tab shows why: it loads the shop's entire catalog data (about 3 megs) upfront, and the entire application runs locally with not a single request until you buy something. Now that's efficiency.
Really. Go to their website, clock on KATALOG and click some random buttons, pick a product at random, add it to your cart, remove it from your cart.
The product images are the only things that aren't pre-loaded.
None of the things you said mentioned should be hard. We did complicated things like that and more in the 1990s.
But it was different...
Yeah. It was. That's exactly my point.
A major problem is the number of places in our code stacks where developers think it's perfectly normal for things to take 50ms or 500ms that aren't. I am not a performance maniac but I'm always keeping a mental budget in my head for how long things should take, and if something that should be 50us takes 50ms I generally at some point dig in and figure out why. If you don't even realize that something should be snappy you'll never dig into why your accidentally quadratic code is as slow as it is.
Another one I think is ever-increasingly to blame is the much celebrated PHP-esque "fully isolated page", where a given request is generated and then everything is thrown away. It was always a performance disaster, but when you go from 1 request to dozens for the simplest page render it becomes extra catastrophic. A lot of my web sites are a lot faster than my fellow developers expect simply because I reject that as a model for page generation. Things are a lot faster if you're only serving what was actually requested and not starting everything up from scratch.
Relatedly, developers really underestimate precomputation, which is very relevant to your point. Your hypothetical page layout is slow because you waited until the user actually clicked "menu" to start generating all that. Why did you do that? You should have computed that all at login time and have it stored right at your fingertips, because it is a reasonable assumption given the sort of page you're talking about that if the user logged in, they are there to make an order, not to look at their credit card settings. Even if it expensive for reasons out of your control (location API, for instance) if you already did the work you can serve the user instantly.
Having precomputed all this data, you might as well shove it all down to the client and let them manipulate it there with zero further network requests. A menu is a trivial amount of information.
It isn't even like precomputation is hard. It's the same code, just running at a different time.
"But what about when that doesn't work?" Well, you do something else. You've got a huge list of options. I haven't even scratched the surface. This isn't a treatise on how to speed up every conceivable website, this is a cri de coeur to stop making excuses for not even trying, and just try a little.
And it is SO MUCH FUN. Those of you who don't try you have no idea what you are missing out on. It is completely normal on a code base no one has ever profiled before to find a 50ms process and improve it to 50us with just a handful of lines tweaked. It is completely normal to examine a DB query taking 3 seconds and find that with a single ALTER TABLE ADD INDEX cut that down to 2us. This is the most fun I have at work. Give it a try. It's addictive!
ALTER TABLE ADD INDEX, in some cases, can create speed increases in multiple orders of magnitude.
I was using a SAST program that used MS SQL Server and was generating reports, and often finding the reports took HOURS to generate, even when the report was only ~50 pages. A report on one specific project took over a DAY to generate a report. I thought it was ludicrous, so I logged onto the SQL server to investigate and found that one query was taking 99% of the time. This query was searching through a table with tens of millions of rows, but not indexed on the specific rows it was checking against, and many variations of the query were being used to generate the report. I added the index (Only took about an hour, IIRC), and what took hours now took a couple minutes.
I was always surprised the software didn't create that index to begin with.
2 replies →
Yeah, your last point is totally spot on, it is so gratifying to make something feel obviously much faster, in a way that few other things in programming are, and there's usually a lot of low hanging fruit.
Also, if you work on a website, the Google crawler seems to allocate a certain amount of wall time (not just CPU time) to crawling your page. If you can get your pages to respond extremely quickly, more of your pages will be indexed, and you're going to match for more keywords. So if for some reason people aren't convinced that speed is an important feature for users wanting to use your site, maybe SEO benefits will help make the case.
I'm a well constructed system, you could probably get this down to one PostGIS query with some joins and spacial indexes that should run in <100ms.