Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice to Young Web Developers

tumblr.beesbuzz.biz

Post reply on HN
Print view View original

91–100 of 328 posts

Re: Advice to Young Web Developers

#91

Post by SahAssar »

lxe wrote: post #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"…

> At least sanitize in a way that won't break the server but will throw an error.

If you need to sanitize to avoid breaking the server then the server is already broken. Also, never sanitize, validate on input and escape/encode on output, but sanitization (meaning removing/cleaning invalid input) is the wrong way.

Re: Advice to Young Web Developers

#92

Post by leephillips »

paxys wrote: post #79
duskwuff wrote: post #68

Earlier quoted context omitted.

It's literally just a folder full of perfectly normal HTML files. You don't need Javascript or a SPA to double-click one of those and look at it in a browser. Even better, if your operating system has full-text file indexing, it'll be able to search them normally.

Sure, but you also have to manually redownload the entire site whenever there is a change.

That’s what rsync is for.

Re: Advice to Young Web Developers

#93

Post by nepeckman »

austincheney wrote: post #74
nepeckman wrote: post #36

Earlier quoted context omitted.

I'll offer up another reason, which I feel is a little more accurate: * Your web app requires heavily interactive bits, such as smart forms, smart tables, previews, content editing, etc. To deliver such functionality in a maintainable way, you use a framework. (As a side note, yes it is possible to deliver this functionality in vanilla JS, but to make it maintainable one must essentially build an ad hoc framework.) B…

I would argue most websites never require any of those. When any of those are required they don’t need a giant framework to achieve maintainability. All that’s needed to achieve maintainability is a competent developer who values both simplicity and written documentation.

This sentiment frustrates me. The majority of web developers today are application developers. I've spent the past 5 years delivering business applications via the web as a platform. The web has a lot of advantage as a platform: no install, cross platform, networked by default. But the web was not designed as an application platform, so making it into one is complex. Business applications have inherent complexity as well, and managing all that complexity is a non trivial task.

Posts like this frustrate me because you seem to be suggesting complexity in the web domain is largely incidental.

Re: Advice to Young Web Developers

#94

Post by timw4mail »

osrec wrote: post #87
timw4mail wrote: post #35

Earlier quoted context omitted.

> It's no longer just text, images and links. Assuming you add video, 99% of the web is just text,images,links,forms, and video. None of these things even require Javascript.

I'd say a big part of the web is gaming, chatting, interacting. A lot of that content updates every few seconds. Without JS, websockets, ajax requests etc, do you suggest users load the entire page again whenever they want to see an updated view?! Or is your opinion that it should only be possible to do those things in native, purpose-built apps? Because in that case, how do you justify using an operating system? Per…

As another poster said: The right tool for the right job.

Also, a SPA is not the only option with Javascript.

Re: Advice to Young Web Developers

#95

Post by detaro »

paxys wrote: post #48
CM30 wrote: 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…

> Your documentation doesn't need to be an SPA. Disagree with this. Having the entire documentation site working as normal on my browser when I have bad/no internet connectivity is extremely useful.

Many SPA examples will try load bits from the server and fail. And a non-SPA site can easily be provided as a download too, or use a service worker to provide offline access in the browser.

Re: Advice to Young Web Developers

#96

Post by kvetching »

"Give people consistent but random stimulus and you will be habit-forming. Getting people hooked on your product might seem like a good idea, but the tobacco industry feels the same way."

DO NOT Listen to this. Make your site as addictive as possible. It can only help you win at life. More users = more impact = more money = better life. So long as it's not porn, your website won't be as bad as tobacco.

Re: Advice to Young Web Developers

#97

Post by frenchyatwork »

paxys wrote: post #79
duskwuff wrote: post #68

Earlier quoted context omitted.

It's literally just a folder full of perfectly normal HTML files. You don't need Javascript or a SPA to double-click one of those and look at it in a browser. Even better, if your operating system has full-text file indexing, it'll be able to search them normally.

Sure, but you also have to manually redownload the entire site whenever there is a change.

You would with a SPA as well.

Edit: incidentally, a common way for this to work is that the documentation just comes with the software itself, so it's just sitting there on you computer. If the software updates, the documentation updates.

Re: Advice to Young Web Developers

#99

Post by hootbootscoot »

lucasmullens wrote: post #33

> To the developer, “isomorphic” code breaks down the barrier between client and server. To a malicious client, it means they have control over the server too. Huh? I don't follow this. Sharing some helpful util functions between the frontend and backend doesn't allow malicious clients to control your server.

meteor

Re: Advice to Young Web Developers

#100

Post by hootbootscoot »

nepeckman wrote: post #36
austincheney wrote: post #13

Earlier quoted context omitted.

The most common reasons for building a SPA: * That is the design pattern dictated by your large framework. * Maintaining state is absurdly simple, but it requires original code if not using a big framework. * The browser provides a simple standard API for interacting with HTML, but your framework provides abstractions you didn’t know you could live without. That’s it. Developers twist themselves in knots trying to qu…

I'll offer up another reason, which I feel is a little more accurate: * Your web app requires heavily interactive bits, such as smart forms, smart tables, previews, content editing, etc. To deliver such functionality in a maintainable way, you use a framework. (As a side note, yes it is possible to deliver this functionality in vanilla JS, but to make it maintainable one must essentially build an ad hoc framework.) B…

...almost... i'll accept "an SPA on one server-side route for that one complicated page that's full of bells and whistles."

and then I'm still going to say "yeah, i'm roughly equally verbose and spaghetti-like in even the best most prescient framework from the gods themselves" and merely wish for the means of modularization: breaking my server- rendered page that my javascript "unfolds from" into further little bits that can each have their own smaller less-spaghetti like world without having to try to dynamically load and include javascript on the client. Break it up. Divide et impera...

Post reply on HN