431–440 of 521 posts
Earlier quoted context omitted.
Other standard DOM methods like what? getElementById and getElementsByClassName?
I also want to know this.
For a practical example try this: https://github.com/prettydiff/semanticText
Earlier quoted context omitted.
Instead of this I use explicitly named variables and functions. Instead of addEventListener I assign event handlers directly to the event property of the DOM: button.onclick = whatever . This forces simplicity and cleaner code management because only one function can be assigned to any given property. Instead of querySelectors I use other standard DOM methods.
Other standard DOM methods like what? getElementById and getElementsByClassName?
For a practical example try this: https://github.com/prettydiff/semanticText
Earlier quoted context omitted.
This is a silly list. What? You really think document.getElementById is going to be faster than querySelector("#foo")? You really think there is a meaningful difference between other methods of adding event handlers, other than it being way hackier to add more than one with the other methods? I have no idea what your objection to "this" is. Object Oriented code can be bad sometimes but so can procedural code.
This person has a weird unjustified objection to querySelector. I remembered this same conversation from 8 months ago where I pointed out that parsing something like '#foo' is NOT slow, he argued against it, 5 people pointed out the same thing, and he was not receptive to that feedback, etc. https://news.ycombinator.com/item?id=24054745 Performance is hard; optimizing the wrong thing is also a problem ...
If jsPerf is down try http://jsbench.github.io/
What upsets and concerns me the most is when I see poorly developed SPA on really important sites. For example, government service application websites. If reddit or nytimes has a bloated, intermittently failing SPA site, that's an annoyance. When it's a form to apply for unemployment, ACA health care, DMV, or other critical services, it's a critical failure. Especially since these services are most often used by exa…
Yeah what's weird is that there's is an entire generation of developers who think of SPA as the default. They think that server side is slower because you have to send down more data, or you have to wait for the server to generate HTML. Quite the contrary, it's slower to send down 1 MB or 10 MB of JavaScript to render a page, than to simply send down a 100 KB HTML page. Even if you need some JS also, browsers know ho…
> Quite the contrary, it's slower to send down 1 MB or 10 MB of JavaScript to render a page, than to simply send down a 100 KB HTML page. Even if you need some JS also, browsers know how to render concurrently with downloads, as long as you provide enough HTML.
The argument I remember from years ago used "slower" as a bad simplification. What it actually meant was, doing the rendering server-side wasted CPU the server could be using to respond to another request. Instead, just send the data and distribute some of this processing to all your users by way of client-side rendering.
Also, back then bundling was a lot rarer than it is now, so the large libraries that made of most of those 10 MB javascript files would be separate files the browser can keep cached.
Earlier quoted context omitted.
Take away React, Vue, Angular, or similar away from most current front end developers and there is panic. When I say panic I mean full insanity panic like abandoning the profession or completely going postal. —— A simple checklist to provide superior front end applications: * Don’t use this . You (general hypothetical you) probably don’t realize how easily you can live without it only because you have never tried. Do…
Your opening sentence is weirdly derogatory... And I think these are all pretty far from the main performance issues with common apps FWIW. These are more low level coding issues, whereas the real slowness (e.g. 10x or 100x issues) comes from architecture, dependencies, network usage, data structures, reflows, etc.
That is tech debt and complexity. If you start from a simplicity first perspective most of what you list evaporates as a matter of habit.
What upsets and concerns me the most is when I see poorly developed SPA on really important sites. For example, government service application websites. If reddit or nytimes has a bloated, intermittently failing SPA site, that's an annoyance. When it's a form to apply for unemployment, ACA health care, DMV, or other critical services, it's a critical failure. Especially since these services are most often used by exa…
Why do these things even need to be an SPA? What function does that serve when the standardized and infinitely more compatible form-with-a-bit-of-javascript approach works just as well if not better? I work on one such project and it absolutely drives me nuts -- it's a rails app, but the customer front-end (which is literally just a form to fill out) is a React SPA. There is nothing there that couldn't be done with T…
Earlier quoted context omitted.
I love modern frontend development. I can build apps that scale easily to hundreds of thousands of users. They are fast where they need to be fast, and building components means complexity lives only where it's needed. Static parts are rendered statically, dynamic parts are rendered dynamically. I can write all code for the entire stack in Javascript. The entire workflow is streamlined in a simple way (webpack really…
There are many reasons why having SPA and rendering your site on the client is a bad idea. First, you are basically breaking the concept of the web, a collection of documents, not a collection of code that must be executed to get a document. That has many bad effects. Browsing is slower, you have to download the code of the whole application and wait for it to execute other API calls to the server before the page is…
2G is being phased out (at least where I live), it no longer works here. Chromium browsers have a slow-3g network effect to test your code/sites. I use it frequently. Sometimes it reveals problems, other times it's a shrug. Some features just require bandwidth and there is no reasonable way to avoid it. I do try to reduce page weight as much as I reasonably can.
Lots of features of the modern browser will leak finger-printable information. The JS engine is hardly the only problem piece. I guess your general complaint here is to indicate the world is insane. I tend to agree, but I don't think this is the principle reason why :)
Screen readers are notoriously difficult to make work correctly. In my experience, this is a universal issue with the web generally and isn't unique to SPAs. If we're serious about audio accessibility we need an actual standard instead of this guesswork.
Breaking navigation is a pet peeve of mine too, poorly behaved front-end routers are terrible. I always target working urls into any part of the app as refreshing the page is a common operation. And I must have a properly functioning back/forward for my own sanity in development if nothing else.
I will beg to differ on the point of failure. SPAs can also be apps, paired with a service worker and a local data set they can continue to function even if you are completely offline, or the server is completely offline. Obviously if your web app is just broken, yeah, nothing's going to work. But in the case of SSR, that's also true if your network is down (locally or remotely), or the server is down/broken.
A well built offline-first SPA will reduce the total number of single point failures that kill all functionality. Also, offline-first SPAs have the side effect of masking some of the latency over a slow 3G link - which can improve the user experience significantly.
What upsets and concerns me the most is when I see poorly developed SPA on really important sites. For example, government service application websites. If reddit or nytimes has a bloated, intermittently failing SPA site, that's an annoyance. When it's a form to apply for unemployment, ACA health care, DMV, or other critical services, it's a critical failure. Especially since these services are most often used by exa…
Government services were slow and unreliable before computers. The problems aren’t technological.
1. it is standard to send json from server to client, a format that takes up more space on the wire, and takes more cpu power to serialize and deserialize than various binary options, all because nobody can be bothered to build tooling around debugging a binary format on the wire and a serialization library that is efficient into the browser
2. We require two separate text markup languages to define a ui (html and css) rather than compiling that down to an efficient binary format
3. We rely on a dynamic language built in 9 days to write client side code, rather than a byte code that any language could target and choose to be dynamic or not as the domain demands (wasm may one day finally change this)
Then rather than a trend of fixing these problems, we instead let these problems spread, as electron brought the html+css+javascript model to desktop apps, nodejs brought javascript to the server so you could use one language for your web app, and on and on.
There is hope though, wasm at the forefront. Today only non garbage collected languages are viable for wasm without adding the overhead of downloading a large runtime, but that is an engineering problem that could be solved.
There are so many trivial inefficiencies that can be trimmed away. But perhaps the biggest obstacle to a nice web experience is intentionally user hostile design. The modal popups, the cookie warnings. These waste more time than parsing and fat downloads for most of us. I'm not sure how to solve that problem. People give you blank stares when you complain about it.