Live data from Hacker News

Advice to Young Web Developers

tumblr.beesbuzz.biz

21–30 of 328 posts

Re: Advice to Young Web Developers

#21
post #19

Why 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

#22
post #5

> 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

The one that drives me crazy are websites that say they only support safari on iOS... It’s all safari under the hood.

Re: Advice to Young Web Developers

#23
> Even if you need to preserve client state between page loads (for e.g. music or video playback) you can let the browser do most of the heavy lifting by fetch()ing a new page and replacing your content container at the DOM level.

Anyone knows of some easy to learn example of such DOM replacement?

Re: Advice to Young Web Developers

#24
post #21
post #19

Why 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

Any "online data" is virtually infinite. Online in the algorithmic sense, not the internet. Think Instagram or facebook

Re: Advice to Young Web Developers

#25
There are two that stand out to me:

> 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

#27
post #18

Seems 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…

I can't count the times I've started to write some basic internal tool with React only to rm -rf everything 1 hour later and replace it with 20 lines of jQuery/vanilla js

Re: Advice to Young Web Developers

#29
post #9

Earlier 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.

So, it's an anti-pattern of an architecture.

Re: Advice to Young Web Developers

#30
post #11

Earlier 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…

> Prevent reloading of the page every time the user clicks a link,

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.

Post reply on HN