> 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 fair amount of nuance which the Chrome Compatibility post[0] touches on, but developing the web platform should be done openly, with the browser vendors working together to be compatible with each other and not introduce developer or user inconvenience. Otherwise you end up with web ownership and a fragmented platform.
It’s good advice (like most of the list!) but I’m not sure expecting a beginner[1] to “code to the standard” is realistic. The standard (i.e the spec) isn’t beginner-friendly. You learn by trying things out and seeing what happens.
1: Assuming they meant for the advice to apply to beginners rather than young developers - what age they are seems irrelevant.
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 will use that framework, regardless of whether it's the right tool for the job.
A blog doesn't need to be an SPA. A static business site that never gets updated and doesn't do anything remotely interesting doesn't need to be an SPA. Your documentation doesn't need to be an SPA.
It's like that guy who was recreating CPanel as a WordPress plugin/install. Sure, you could do things that way, but may want to rethink whether this is really the best architecture to build a server control panel in.
> They learn React/Vue/Angular/whatever, then seemingly decide everything they will ever build will use that framework, regardless of whether it's the right tool for the job.
At least where I live, small businesses contract with agencies that develop React sites for them, and suddenly these non-IT companies are owners of expensive and hard to maintain websites that they don't, and shouldn't need to, know the first thing about maintaining. No one wants to work with the projects, because they were written in, say 2015 React, back when React used X feature that isn't cool anymore, so it gets rewritten by another agency, and so on.
Meanwhile, WordPress on a managed host or a static site would suit those businesses just fine. Then, they wouldn't have trouble hiring to maintain it, or could even maintain it themselves.
If you work for an agency or you're freelancing, please stop burdening small businesses like this.
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
When I started at my current company I was shocked that they were using Wordpress for 90% of client sites. Now 2yrs in, I’m thankful we are using Wordpress for these sites. It keeps things maintainable and simple. And for 90% of businesses, that’s exactly what they need.
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 this way, and so easy to deploy.
Sure, it renders slower. I've just signed my 25th professional client, and I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it.
Server-side rendering or writing raw HTML are over-rated.
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 problem is that is holding you back – drinking, eating, whatever – fix it today 7) Learn Clojure
8) learn a statically typed language with a good type system
Even if you end up preferring mainstream language X, learning a language that makes you think in expressions rather than operations, and a language that makes you think in contracts rather than knowing the runtime state in your head, is invaluable for learning how to design, structure and maintain a codebase
What is your reasoning behind the recommendation to learn Clojure? I am generally unfamiliar with it but saw it was a general purpose language. What makes it so valuable to be included in your list?
>3) HN is 3 years ahead of mainstream, but 10 years behind the edge
I think you're using a weird definition of 'edge' here to mean "things that nobody else knows about" rather than the cutting edge of the industry/academia.
Academic publications occasionally float across the front page here that have only been public for a few days. That's pretty much the 'edge' of industry-wide knowledge.
If you want to include things that aren't public, that's super vague and sort of pointless.
Hi, if possible, could the link please be updated to point to the original post at https://beesbuzz.biz/blog/2934-Advice-to-young-web-developer... ? The Tumblr automatic crosspost isn't really intended to be the canonical version, and I wouldn't mind getting a server load test while we're here.
Sorry about that, Fluffy. Your Tumblr feed is listed first in my reader and was moved to submit it almost immediately after reading it. Nice to see you, BTW. Since I never post about my life anywhere I end up just being a lurker in yours, but I'm glad to be.
> 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.
> 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.
What I was trying to (clumsily) say is that when people develop "isomorphic" code they tend to forget that some of it runs on the client and some of it runs on the server and the interface between the two cannot be trusted.
Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client.
And if you don't even know which code is running where, that makes it even more dangerous.
Think of transpilers like GWT, where you write java that's converted to in-browser Javascript; or the current trend of server-side Javascript.
(For what it's worth, both are really really cool technologies!)
Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.
Maybe they are thinking of services like firebase where much of the traditional server logic is now handled in the same js libraries that the frontend uses? But I'm also not sure what exactly the author is referring to.
> Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean.
Infinite scrolls are ugly, but i'm not sure artificially "paginated" text is better. The worst thing about infinite scrolls is that you cannot search for a word in the whole document (just on your visible part of the screen, and a screenful below that).
Why does infinite scroll have to suck on the web, yet you never see pagination in mobile and desktop software?
It makes me think that it's not inherently bad, it's the technology that's lacking.
If the file explorer would split a 1000 file listing into 10 files each it would drive anyone insane. The "Artists" list on my phone's music player can probably be meassured in meters yet it's a joy to use because momentum scrolling is very good.
I really hate the trend with having infite scroll on blogs/news sites. I just scroll to the bottom looking for the comment section and suddenly I'm on a completely new, unrelated article? It's like forcing information into my brain, or someone suddenly placing a newspapper in your face.
the worst is when the "About Us", "Company", "Help", "Contact Us" page links are at the "bottom" and you want to click on them... momentarily appearing and disappearing...
Ironically, it uses tumblr, so the damn back button is captured (try getting back here).
This is my fave:
> Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean.
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.
Not that any of this advice is bad - a lot of it I agree whole-heartedly with - but it overestimates the amount of influence developers, let alone junior developers, have on the final design of a corporate site. If management/design want infinite scrolling then that's what they get, whatever the developers say.
Advice: don't make everything slow as shit please. Note, this most likely means writing your own trim left function and not depending on zillions of libraries. If you can't write something as simple as this, please don't! Just output a static web-page that loads ultra fast. Thanks young web developers!
> 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?
Window load events fail to fire this way among other likely problems. You'd have to specifically design around doing it, or do something else like put the whole page in an iframe with your video/music player staying floating outside, or put back inside when it's loaded.
[+] [-] mroche|5 years ago|reply
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 fair amount of nuance which the Chrome Compatibility post[0] touches on, but developing the web platform should be done openly, with the browser vendors working together to be compatible with each other and not introduce developer or user inconvenience. Otherwise you end up with web ownership and a fragmented platform.
[0] https://news.ycombinator.com/item?id=23563525
[+] [-] jolmg|5 years ago|reply
The one with the greatest market share is incentivized to the contrary in order to cement their position.
[+] [-] tobr|5 years ago|reply
1: Assuming they meant for the advice to apply to beginners rather than young developers - what age they are seems irrelevant.
[+] [-] CM30|5 years ago|reply
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 will use that framework, regardless of whether it's the right tool for the job.
A blog doesn't need to be an SPA. A static business site that never gets updated and doesn't do anything remotely interesting doesn't need to be an SPA. Your documentation doesn't need to be an SPA.
It's like that guy who was recreating CPanel as a WordPress plugin/install. Sure, you could do things that way, but may want to rethink whether this is really the best architecture to build a server control panel in.
[+] [-] heavyset_go|5 years ago|reply
At least where I live, small businesses contract with agencies that develop React sites for them, and suddenly these non-IT companies are owners of expensive and hard to maintain websites that they don't, and shouldn't need to, know the first thing about maintaining. No one wants to work with the projects, because they were written in, say 2015 React, back when React used X feature that isn't cool anymore, so it gets rewritten by another agency, and so on.
Meanwhile, WordPress on a managed host or a static site would suit those businesses just fine. Then, they wouldn't have trouble hiring to maintain it, or could even maintain it themselves.
If you work for an agency or you're freelancing, please stop burdening small businesses like this.
[+] [-] laurentdc|5 years ago|reply
[+] [-] willio58|5 years ago|reply
[+] [-] jonathannat|5 years ago|reply
[+] [-] paxys|5 years ago|reply
Disagree with this. Having the entire documentation site working as normal on my browser when I have bad/no internet connectivity is extremely useful.
[+] [-] stevage|5 years ago|reply
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 this way, and so easy to deploy.
Sure, it renders slower. I've just signed my 25th professional client, and I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it.
Server-side rendering or writing raw HTML are over-rated.
[+] [-] dustingetz|5 years ago|reply
[+] [-] eyelidlessness|5 years ago|reply
8) learn a statically typed language with a good type system
Even if you end up preferring mainstream language X, learning a language that makes you think in expressions rather than operations, and a language that makes you think in contracts rather than knowing the runtime state in your head, is invaluable for learning how to design, structure and maintain a codebase
[+] [-] schrute|5 years ago|reply
[+] [-] pathseeker|5 years ago|reply
I think you're using a weird definition of 'edge' here to mean "things that nobody else knows about" rather than the cutting edge of the industry/academia.
Academic publications occasionally float across the front page here that have only been public for a few days. That's pretty much the 'edge' of industry-wide knowledge.
If you want to include things that aren't public, that's super vague and sort of pointless.
[+] [-] zbentley|5 years ago|reply
D'oh! Why didn't I think of that?
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] xrendan|5 years ago|reply
[+] [-] hejja|5 years ago|reply
[+] [-] fluffycritter|5 years ago|reply
Thanks!
[+] [-] EvanAnderson|5 years ago|reply
[+] [-] flobosg|5 years ago|reply
[+] [-] lxe|5 years ago|reply
> 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.
[+] [-] lucasmullens|5 years ago|reply
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.
[+] [-] fluffycritter|5 years ago|reply
Form validation is a common example of where things can break, like someone injects malicious data that's already been validated by the client-side code and then the server assumes that the code has already been validated by the client.
And if you don't even know which code is running where, that makes it even more dangerous.
[+] [-] gwbas1c|5 years ago|reply
(For what it's worth, both are really really cool technologies!)
Edit: But I also suspect this relates to a temptation to write browser-side Javascript without thinking about the server-side or database; IE, browser-side Javascript that just loads objects willy-nilly via fetch / AJAX and creating lots of round trips.
[+] [-] gt2|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] kanobo|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] hootbootscoot|5 years ago|reply
[+] [-] recursivedoubts|5 years ago|reply
Young developers, if you can spare a moment, try to learn what REST (and HATEOAS) really meant:
http://intercoolerjs.org/2016/01/18/rescuing-rest.html
http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
[+] [-] rickpmg|5 years ago|reply
[+] [-] MrBuddyCasino|5 years ago|reply
If I had to pick just one, it would be this.
[+] [-] enriquto|5 years ago|reply
[+] [-] kall|5 years ago|reply
It makes me think that it's not inherently bad, it's the technology that's lacking.
If the file explorer would split a 1000 file listing into 10 files each it would drive anyone insane. The "Artists" list on my phone's music player can probably be meassured in meters yet it's a joy to use because momentum scrolling is very good.
[+] [-] XCSme|5 years ago|reply
[+] [-] born2web|5 years ago|reply
[+] [-] ChrisMarshallNY|5 years ago|reply
This is my fave:
> Infinite scrolls are inhumane. People need to be able to reach “the end.” There are forms of eternal torment described in religious texts that are less mean.
[+] [-] mooneater|5 years ago|reply
[+] [-] anonytrary|5 years ago|reply
[+] [-] danjac|5 years ago|reply
[+] [-] squid_demon|5 years ago|reply
[+] [-] devcriollo|5 years ago|reply
The most ignored
[+] [-] vyuh|5 years ago|reply
Anyone knows of some easy to learn example of such DOM replacement?
[+] [-] purerandomness|5 years ago|reply
[+] [-] jimmaswell|5 years ago|reply
[+] [-] CameronNemo|5 years ago|reply
[+] [-] partyboat1586|5 years ago|reply
[+] [-] inanutshellus|5 years ago|reply
[+] [-] ithrow|5 years ago|reply