Why so much hate for infinite scrolls? What if your content is "infinite". I can't see a better way to handle that.
Advice to Young Web Developers
21–30 of 328 posts
Re: Advice to Young Web Developers
#22> Browsers change. Relying on browser-specific behavior means you’re relying on that one browser at that one point in time. Code to the standard, and test everywhere. I wish this was listed at the top of the list, in the middle, and at the end. It’s super annoying when a site or application isn’t “supported” because it wasn’t tested in a separate browser (i.e. non-Chrome browsers). I know it’s not always easy with a…
Nothing pisses me off like getting a message that some website only supports Chrome in 2020
Re: Advice to Young Web Developers
#23Anyone knows of some easy to learn example of such DOM replacement?
Re: Advice to Young Web Developers
#24Why so much hate for infinite scrolls? What if your content is "infinite". I can't see a better way to handle that.
My take is just because you can doesn't mean you should. It seems like there is no such thing as infinite content, and if you feel like you are in a case where there is adding constraints will probably improve your product/ux
Re: Advice to Young Web Developers
#25> Always validate your data server-side; anything that comes from the client is suspect.
At least sanitize in a way that won't break the server but will throw an error. For internal applications and side projects it's ok to just respond with a 40X or a 50X and move on.
> To the developer, “isomorphic” code breaks down the barrier between client and server.
"Breaks down the barrier" sounds great, but it's actually has been rather detrimental. "Isomorphic" is confusing even to the senior developers. Having a very clear delimiter of what runs in the server and what runs in the client is essential, and it makes your application much simpler to reason about. Take `isomorphic-fetch` for example... a request from a server to another API server has very different requirements and nuances than a request from a browser to a server.
Re: Advice to Young Web Developers
#26Advocating accessibility is nice though, so do try.
Re: Advice to Young Web Developers
#27Seems like a list of every web development ideal that gets upvoted on Hacker News. Still, I think the list can pretty much condensed down to one point: Use whatever technology is appropriate for this site or web app. Because a lot of developers seem to have a 'when all you have is a hammer' attitude towards web development. They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build w…
Re: Advice to Young Web Developers
#28Re: Advice to Young Web Developers
#29Earlier quoted context omitted.
SPAs are an anti-pattern. Let's rebuild html rendering, navigation history, forms, etc, all with Javascript, because it's the hip thing to do.
You're not using that word correctly, since this is not a pattern it's an architecture. Please don't misuse words, especially in a negative context to mean "something I don't like", it cheapens the word in legitimate cases. No comment on whether SPAs are worth anything though, I reserve my opinion.
Re: Advice to Young Web Developers
#30Earlier quoted context omitted.
SPAs are an anti-pattern. Let's rebuild html rendering, navigation history, forms, etc, all with Javascript, because it's the hip thing to do.
There are very clear reasons for SPAs to exist. 1) Prevent reloading of the page every time the user clicks a link, reducing the overhead of fetching common content between pages multiple times (headers, menus, etc) and providing a more seamless experience to the user. 2) Better emulate the feel of mobile applications, for users who spend most of their time on their phones and don't often or have never interacted wit…
You don't need a SPA for that. And page load/render times are much shorter when html is delivered straight to browser fr most applications
> Better emulate the feel of mobile applications,
That's pretty weak defense.
> Once the browser downloads and caches the bundle on initial load, the user can revisit the page
Giving we're now in the world of Continuous Deployment, I doubt the cache lasts long.
All 3 of those reasons sound very reaching to me.
And here's the kicker - doing a SPA well enough to be seamless and performant is hard enough that most sites suck if they're delivering a SPA.
Also, if, for example, you do your payments or other sensitive pages in a SPA, you're still running 3rd party scripts on those pages for no reason. Let me know when unloading scripts(&their in mem code) is doable.