Advice to Young Web Developers • Hacker News Board

Re: Advice to Young Web Developers

#161

Post by shreddish » Fri, Jun 19, 2020, 2:10 AM UTC

fluffycritter wrote: post #142

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.

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

Hmm I guess since it's advice to young developers they might make that mistake but any slightly experienced developer knows not to trust anything client side. Not validating data from the client isn't exclusive to isomorphic code.

Re: Advice to Young Web Developers

#162

Post by stevage » Fri, Jun 19, 2020, 2:17 AM UTC

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.

Re: Advice to Young Web Developers

#163

Post by purerandomness » Fri, Jun 19, 2020, 2:24 AM UTC

vyuh wrote: post #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?

Yes, look at the examples at https://htmx.org/

Re: Advice to Young Web Developers

#164

Post by siquick » Fri, Jun 19, 2020, 2:30 AM UTC

heavyset_go wrote: post #51

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…

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

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

There aren't many more soul-destroying experiences as a freelance developer than maintaining a neglected WordPress installation that was built by a maverick agency that took the money and disappeared.

Re: Advice to Young Web Developers

#165

Post by recursivedoubts » Fri, Jun 19, 2020, 2:36 AM UTC

That's unfortunate: the back button doesn't work on the linked site.

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

Re: Advice to Young Web Developers

#166

Post by aspenmayer » Fri, Jun 19, 2020, 2:42 AM UTC

thinkloop wrote: post #157

jjoonathan wrote: post #61

Earlier quoted context omitted.

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 :(

Double-check that your initial privacy excitement during setup isn't the culprit. The couple of times that happened to me (Paypal being one) lowering my "Browser Privacy" setting from "strict" or "custom" back to "standard" fixed the issue. I would be curious to see examples of broken sites if you have em.

I feel like I’m using IE in 1995 hearing this comment, but it’s valid. I feel like time is repeating itself. This is one of those tips that never really stop being relevant.

The modern equivalent is tuning uBlock Origin, uMatrix, Privacy Badger, or similar products, on top of correctly configuring your browser itself.

Re: Advice to Young Web Developers

#167

Post by satvikpendem » Fri, Jun 19, 2020, 2:44 AM UTC

lsalvatore wrote: post #106

Advice to Young Frontend Web Developers: Use React. HTML is not a rich enough framework to do client work. Second article in a row here advocating for HTML purism. That is where I jump in and talk about how React changed my career in 2015. Since then, my life has had a measurable impact because of how easy building apps became thanks to React. There is no app where I would consider not using React including landing p…

Yes, and even with React, one can use a static site generator to turn it into HTML, CSS, and minimal JS, so I don't see any reason not to use React, beyond the oft touted ones.

Re: Advice to Young Web Developers

#168

Post by brailsafe » Fri, Jun 19, 2020, 2:49 AM UTC

stevage wrote: post #162

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…

What kind of stuff are you building and is it the job of the person paying you to actually use the thing?

Re: Advice to Young Web Developers

#169

Post by shreddish » Fri, Jun 19, 2020, 2:49 AM UTC

randompwd wrote: post #30

Kaze404 wrote: post #11

Earlier quoted context omitted.

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 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??

Re: Advice to Young Web Developers

#170

Post by arkis22 » Fri, Jun 19, 2020, 2:54 AM UTC

stevage wrote: post #162

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 is the opposite of what I would expect. React (or basically all JS SPAs) uses components which are essentially HTML elements populated by JSON data. It then stitches them together so that they can communicate via JS.

I can explicitly tie together components/html client side via JS (annoying). Or I can simply render the correct html (no need for json routes) while I have access to all of the data on the server. Rendering speed as you mentioned (client or sever), is basically never a consideration.

So why bother explicitly writing javascript to bind html components together when I could just simply render the correct server side HTML?

Ajax is fantastic, but you don't really need an SPA.

If you want to be wildly productive, minimize the javascript you write.

I'm a big fan of intercooler.js btw.