Whether we use React or Vue or Angular, we will regret it. Instead let’s solve the problem then choose the technology
Interested in UI/UX, design thinking and data visualization
It started with InstantClick, but we've made enough adjustments that it's hard to say we still use the library itself. The InstantClick code was copied into our filesystem and hacked on one change at a time. I guess that gets into the philosophical question of how much you can change some software while still referring to the original state by name.
A while back I reached out to the InstantClick author and he hadn't really been keeping up with the project and wasn't really supporting it per se, but I just visited it and it looks like it is getting more support now. Maybe my publicizing it a bit helped kick that into gear.
The CDN is pretty critical to everything for us. CDNs are common practice for rendering static assets, but less so for dynamic pages. For us, though, it's a big part of our caching stack. Fastly provides some really sensible defaults and abstractions but also lets you dive into the Varnish Configuration Languge for customization.
Whether we use React or Vue or Angular, we will regret it. Instead let’s solve the problem then choose the technology
Interested in UI/UX, design thinking and data visualization
I am not so familiar with CDN and I wonder how you are managing how Fastly caches your resources.
By using HTTP headers described here (I only see cache-control:public, no-cache in your response header)?
How do you refresh relevant caches when a content is updated?
Hello! I'm @roperzh. Functional programming, JavaScript, Elixir, and Ruby makes me excited. I like to contribute to OSS and write about programming and life. Simplicity is my motto.
Yes, that is something I wish would improve. As a web dev shop, this is not something we have a lot of control over, but I will try to invoke influence on CDN providers to improve the situation. Mostly asking questions about their current state of things and why it is that way.
For us, as I mentioned, we can treat this as an abstraction layer so as coverage improves at the infrastructure layer, it will improve for us.
Many web experiences serve all their traffic from an origin server, so any attempt at distribution is a good thing. We could, in the future, serve more of the origin server traffic from different distributed apps, but that would take replica databases also be distributed and orchestrate eventual consistency down at the data layer, which is a layer of complexity we're not ready to take on yet.
Yeah, it strikes me as incredibly short-sited to not serve this region better (or at all!). There's a lot of ignorance and short-sitedness abound, but it still doesn't explain enough why nobody is doing it right.
For what it's worth, I don't think it's totally out of our control. Me and my team are pretty influential, connected, and crazy enough to try things. I would love to have conversations about some of the issues on dev.to and welcome you to start discussion threads or write about any of it. It would really help me orient myself around the unknown unknowns that do make things "out of my control" for the moment.
I love dev.to . It loads amazingly fast and lightweight on browser . No special effects and animations adds extra points and many small articles are very informative .
I'd bet one could make a webpack module (or whatever they're called, I don't use it day-to-day) to inline images. I wonder if it would be faster... Intuition says faster for small images, slower for large ones.
Senior DevOps Engineer with 11+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
Junior Developer | Tech Enthusiast | Freelance Web Developer | Front-end Developer at PayPorte | Freelance Android Developer
Taking life one step at a time..
I love the way dev.to loads...its amazingly fast...instantclick(i hope am not wrong)
Looks like i have to read up on how CDN boost up rendering speed
It started with InstantClick, but we've made enough adjustments that it's hard to say we still use the library itself. The InstantClick code was copied into our filesystem and hacked on one change at a time. I guess that gets into the philosophical question of how much you can change some software while still referring to the original state by name.
A while back I reached out to the InstantClick author and he hadn't really been keeping up with the project and wasn't really supporting it per se, but I just visited it and it looks like it is getting more support now. Maybe my publicizing it a bit helped kick that into gear.
The CDN is pretty critical to everything for us. CDNs are common practice for rendering static assets, but less so for dynamic pages. For us, though, it's a big part of our caching stack. Fastly provides some really sensible defaults and abstractions but also lets you dive into the Varnish Configuration Languge for customization.
Deep dive into varnish. Thanks for the explanation.
A: You put your money where your mouth is: This site loads crazy fast!
B: Thank you for the easy github auth!
C: Wow!
Thanks for sharing.
I am not so familiar with CDN and I wonder how you are managing how Fastly caches your resources.
By using HTTP headers described here (I only see
cache-control:public, no-cachein your response header)?How do you refresh relevant caches when a content is updated?
Indeed, the performance of dev.to is remarkable. Thanks for sharing!
When you're in Nigeria. The HTML request comes from Egypt or SA. They're thousands of miles away. Why Nigeria? Why? :(
But dev.to is still fast enough though :)
Yes, that is something I wish would improve. As a web dev shop, this is not something we have a lot of control over, but I will try to invoke influence on CDN providers to improve the situation. Mostly asking questions about their current state of things and why it is that way.
For us, as I mentioned, we can treat this as an abstraction layer so as coverage improves at the infrastructure layer, it will improve for us.
Many web experiences serve all their traffic from an origin server, so any attempt at distribution is a good thing. We could, in the future, serve more of the origin server traffic from different distributed apps, but that would take replica databases also be distributed and orchestrate eventual consistency down at the data layer, which is a layer of complexity we're not ready to take on yet.
Yes i know it's something that's out of your control.
I'm just wondering why so many "internet-based" companies ignore the traffic in this region.
Nigeria has the largest number of internet users in Africa (More than South Africa and Egypt combined).
Like i said earlier dev.to is fast enough here. So no worries at all :)
Yeah, it strikes me as incredibly short-sited to not serve this region better (or at all!). There's a lot of ignorance and short-sitedness abound, but it still doesn't explain enough why nobody is doing it right.
For what it's worth, I don't think it's totally out of our control. Me and my team are pretty influential, connected, and crazy enough to try things. I would love to have conversations about some of the issues on dev.to and welcome you to start discussion threads or write about any of it. It would really help me orient myself around the unknown unknowns that do make things "out of my control" for the moment.
Maybe you can both contact Andela - andela.com/ ?
I've heard they are pretty connected in Nigeria, Kenya and Uganda, maybe they know someone that can point you in the right direction.
I love dev.to . It loads amazingly fast and lightweight on browser . No special effects and animations adds extra points and many small articles are very informative .
Simply Superb
Yeah, the images are also served via CDN and optimized like crazy.
I'd bet one could make a webpack module (or whatever they're called, I don't use it day-to-day) to inline images. I wonder if it would be faster... Intuition says faster for small images, slower for large ones.
dev.to is amazingly fast and speed is one of the best features a product could have.
I would like to know where you are hosted and what stack/frameworks you use.
dev.to/ben/the-devto-tech-stack
Comprehensive article explaining the nitty gritty of making Dev.to instantaneous, Ben!
Could you shed some light on whether you use containers & orchestration (or plan to) from an infra point of view?
😬
Inline styles aka the style attribute on HTML tags? Does having a CSS file makes the website slower, on websites like DEV? ✋
Awesome Read