Live data from Hacker News

Advice to Young Web Developers

tumblr.beesbuzz.biz

241–250 of 328 posts

Re: Advice to Young Web Developers

#241
post #86

Earlier quoted context omitted.

Threading could be clearer. Less data would need to be loaded on each page load. I can imagine that a lightweight SPA to handle the a few standard views (e.g. listItems, itemDetails, profile, changePassword, submit) would cut down data transfer by a significant margin (20-30%, maybe more). The UI could also be much better on mobile, and we could give users the option to cache certain pieces of content offline.

What you’re suggesting is heresy on HN. It’s true, a little bit of interactivity, fonts/padding/spacing would improve HN. To this day my thumb covers both the upvote and down vote button.

Yes, the UX on mobile leaves a lot to be desired in my opinion. The two things that are going for HN in its current form is the fact that it's lightweight and fast.

A lot of people think that moving to an SPA would mean killing both those aspects. But the truth is, you CAN have an SPA that is both lightweight and fast - the developer just needs to know what they're doing.

Re: Advice to Young Web Developers

#242

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

I think only developers care about rendering speed like that. Most people are happy if the page loads in reasonable amount of time. UX people probably know what that means exactly.

If everyone has only shit sandwiches people won't say they don't like shit sandwiches, but just don't enjoy sandwiches in general. Then when they try a ham sandwich for the first time they will tell that this one is better and they prefer it to others.

Modern web is serving people mostly with nice looking shit sandwiches.

Re: Advice to Young Web Developers

#243

Earlier quoted context omitted.

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

> 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. Are you legitimately worried about unloading third party libraries into memory on the browser??

unloading third party libraries _from_ memory.

or else gaining the ability to freeze their code and all derived/generated code from accessing the dom/network/etc.

Re: Advice to Young Web Developers

#244

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

"I love how slow this site is," said no visitor. Ever.

If your clients are like mine, there are likely a lot of things your clients don't ask for. For instance, accessibility. Do we ignore that as well?

You're also not factoring in ongoing maintenance. What's easy for you to build and deploy might be less so for someone else. React, Vue, etc. are great tools - when they are the correct tool for the job - but they are still relatively niche. If you're not taking a "what if I get hit by a bus approach" then you're doing your clients a disservice.

You might want to try being a typical user for a month or so. Use a smaller monitor, an older mobile device, a slower internet connection, etc. Then take that lens and apply it to your SPA genius.

Re: Advice to Young Web Developers

#245
post #187

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

If you want site longevity, HTML is the way to go. It's fine if you clients aren't expecting to maintain their website for the next 10 years, go ahead and use the JavaScript framework. Tell me that React websites today will still be around in 10 years time. With constant upkeep and maintenance, maybe. If a website is just a static website, not making it plain HTML is a disservice. The layers of abstraction will take…

Amen. React is for experiences where there is interaction. A simple read only site (a la WordPress) is not where React belongs.

Large entities have need and budget for their applications to evolve. The delta for websites is less intensive. For the latter, reliability and longevity is important.

Re: Advice to Young Web Developers

#246

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

> If you have the option of writing an SPA, it's simpler quicker to build this way, and so easy to deploy. It's simpler if you only write the front-end, because it de-couples the work with the back-end. If you are in charge of both front-end and back-end, server-side rendering is easier. It's a case of Conway's Law. Knowing that, you may choose to have a back-end team and a front-end team or a team of full stack deve…

> It's simpler if you only write the front-end, because it de-couples the work with the back-end.

This is nonsense.

Both the frontend and the backend influence the design of each other(and for good reason). The notion that you can build one without the other and be done with it is just wishful thinking.

Re: Advice to Young Web Developers

#247
post #183

Earlier quoted context omitted.

"Nooo you can't just use an SPA, it's your job to know the most appropriate solution for the problem at hand! Google already factors site speed into rankings and with all the Web Core Vitals stuff they've been pushing lately it's only going to be more important. You're failing your clients!" "Haha react goes brrrr"

I have no idea what you are trying to communicate

It’s a meme variant. Here is another, for comparison:

https://knowyourmeme.com/memes/money-printer-go-brrr

Re: Advice to Young Web Developers

#248

1) Nobody has any idea what they're doing 2) If you think you know more than your manager – you are absolutely right 3) HN is 3 years ahead of mainstream, but 10 years behind the edge 4) React was made by an OCaml programmer 5) if you want to be that good, learn emerging languages (all of them) 5) don't optimize for money too soon, if you follow these instructions you will quadruple soon enough 6) Whatever your probl…

[deleted]

Re: Advice to Young Web Developers

#249
I do appreciate the author's emphasis on accessibility! However, as you read more bullet points, you start to realize that the author is really just venting about how much they hate modern javascript development (SPAs, VDOMs, client-side rendering, etc.). It gets pretty obvious about 10 bullet points down that this is the overwhelming theme of the post.

Re: Advice to Young Web Developers

#250

Earlier quoted context omitted.

Nothing pisses me off like getting a message that some website only supports Chrome in 2020

It's so sad that it became "acceptable" to not test in Firefox (as estimated by the number of sites I randomly encounter that don't work in FF but do in Chrome) right around the time that Firefox Quantum happened and Firefox became good again :(

Some businesses are willing to (and sometimes should) take a 30% cut in traffic in order to ship a product more quickly. It's not a company/developer's fault that there are subtle differences between browsers.
Post reply on HN