I'm usually working with Vue but I also learn both React and Vue. They are awesome, those Single Page Application (SPA) framework solve my previous...
For further actions, you may consider blocking this person and/or reporting abuse
Are the users really affected by the couple of seconds that the web page takes a couple seconds longer to load? In worst cases, we are talking about just a couple of seconds and in most cases a second or milliseconds. Is it really that big of an issue though or are developers just stressing over it too much?
If this site provide a service, and me as a potential customer do not care much, I may close the tab before the page even loads. Imagine that there are a team of UX, UI and copy writers done great work to catch your attention to their service. All that may not get noticed, if the page itself took ages to load.
Well, there again as Athaariq mentioned, it depends on the size of connections. If you have a small web application, UX, UI and copywriting teams have done a excellent job, the loading performance really won't be that big of a factor and the content will be shown.
But if it's a bigger site, e.g. as mentioned with 1000+ concurrent connections on a single instance, then it will impact the performance.
So as I've come to a understanding, it depends on multiple factors.
There is a short blog post by Cloudflare on this topic. Fast load times are invaluable when it comes to offering services that involve money.
If it's just some hobby blog or whatever then a mediocre optimised website most likely won't hurt 'cause the people visiting the page are interested in the topic nonetheless. But if you're talking pure business... you want your websites to go fast
It's all about long term thinking. 10-50 visitor won't burden a single server. How about 1000 concurrent connection for a single instance? Yeah too hyperbolic but it's best to prepare than sorry :)
Speaking of performance, I have benchmark reference for you dizzy.zone/2018/01/23/Kestrel-vs-G...
Cheers.
Yes because a couple of seconds is a long time
more on dialup in an developing nation.
Web servers are already serving static assets from memory: the Linux kernel supports filesystem caching, so that any file recently accessed would be in the memory, despite that the web server is accessing them via filesystem API.
Caching can also be configured in nginx and apache, and browsers will also cache.
The main goal is actually prevents disk hit at all cost (for frontend, not backend) in simplest way. Previously I have been fiddling Nginx on my former startup. Sometimes nginx thinks there is a cache miss and add 2-6 seconds of delay with in cached condition as fast as ~600ms. Then I tried to mount ramdisk as Junxiao said. However, it's really hassle to reimplement it on server and ended up messed everything after restart the VPS. So I made a tool (Kuda) to prevent that from happening again and hopefully can be useful for most people.
That's awesome and power to you!
It would be interesting to see some benchmarks of different configurations
Unfortunately, I don't have enough resource to do benchmark (no, I won't burst +1000 connections to my laptop). It's built on top of FastHTTP though, so it's expected to be faster than FastHTTP in term of serving static file.
Available benchmark reference: dizzy.zone/2018/01/23/Kestrel-vs-G...
If anyone did benchmark on sufficient server, please let us know via issue at github repo. Thank you!
On the topic I found these two reads very interesting:
If not SPAs, What?
This talks about the trends that are starting to form (it feels like we're going back full circle in a way)
Second-guessing the modern web
This mentions an aspect that I personally think comes in play in some decision making:
plus it mentions, argumenting them, the reason why the author is skeptic of SPAs (whatever the framework)
I feel like going back full circle is sometimes needed as it can inform better practices/techniques in whatever old way of building sites was being used prior to SPAs
Also a way to appreciate how simpler were things before 👀
Gatsby and Next are fast frameworks for React.
I think I found some kind of “solution” for slow initial load of rich web app. Please have a look to helpzone.me (my little social geo chat app for helping each other). This is React PWA, so about ~4Mb of JS code need to be loaded for map become fully interactive. But if you split to chunks via React.lazy(), first chunk will be just ~1Mb and I just displaying some kind of “onboarding” popup which any new user have to see anyway to understand what is it. And these several seconds which you are reading onboarding (simple sweet alert btw) are perfectly enough to load all remaining code. And service worker will cache all JS for next load :)
Stop using React and Vue. Use Svelte instead.. just kidding but do look into the difference because up until recently all frontend frameworks where the same... Apart from Svelte which takes Vue like mentality and makes it a compiled language which has considerable performance benifits.
Have you tried svelte?
I ever learn a bit. It is one of useful framework, but I rarely got project with svelte.
All I can see is a lot of confusion.
About what's the problem, what's the range of available solutions, but, more importantly, what is the objective.
Do we want to build enterprise-type applications (mostly forms)? Applications with rich UI? Content-centric websites (think a news site)? Almost static web sites with just a bit of interactive contents?
If you need to build an application, you build an SPA. If you need to build an SPA, you use a framework. Pick the one you prefer. End of story.
A long lived application has NOT startup time as one of its priorities, and it shouldn't. It's a nice to have, but that's it.
If you need a content-centric website/app, you have the most choice. While it is true you could take React and build it just like an app, probably you want to make use of a static site generator.
If you need a static website, make one.
When someone clicks a link/an icon/whatever to open our application, a bunch of stuff happens:
1 - you browser calls the server
2 - the server reads (one file at a time, with some parallelism) from disk or cache (every decent server or OS will cache accessed files in memory)
3 - the file(s) are transferred over the wire/WiFi
4 - the page is rendered, in a multi step process. Usually first css+html, then js gets evaluated.
We want to minimize the total time. We cannot do much about 1.
2 it's taken care by our server/proxy. Something like NGINX can be fast, while still being easy enough to setup.
We should minimize the total size of the page+assets, if 3 and 4 are a concern.
Also, using static site generation, 3 and 4 can drastically improve.
This article merges a provocative title with no reasoning and a "solution" which is not related to the "problem".
No, thanks.
Custom frameworks will always be better than react, vue, next, bla bla
Kuda is not framework by the way :)
is it same concept as server side rendering ?
It renders in browser side. Kuda only serves static files like github pages but it came directly from RAM.
(Halo sobat Indo 👋)
thank you for your answer. Its a bit difficult to understand tech definition now days. I cant catch up with latest tech.
(Salken mas 👋)
It's actually easier to find out rather than physics equations 😂 Anyway, thanks for coming! Salam kenal~
phoenixframework.org already did it.
FYI Kuda is web server, not a framework. It serves existing framework's compiled files from RAM.
Is it better than others? like Varnish.
I don't know it exists for what.
So could you tell me about that?