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

191–200 of 328 posts

Re: Advice to Young Web Developers

#191

Post by MattGaiser »

tdeck wrote: post #176
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 misses the part where with an SPA I have to figure out what data and access patterns my frontend code is going to want, define an API+schema for the frontend-backend interactions, and (often) write data validation on both the frontend and the backend - all this in addition to the data definition I would have to do on the backend in any case. If I'm able to render things from the backend, I just have to query the…

> I have never yet had a client who even mentioned rendering speed, let alone was willing to make any trade-off for it.

This section also frequently applies to security.

> but still inflexible enough to prevent security holes.

Unless it involves a transaction or government secrets, security is usually way down the list of priorities.

Re: Advice to Young Web Developers

#192

Post by arkis22 »

quxpar wrote: post #183
untog wrote: post #177

Earlier quoted context omitted.

> I have never yet had a client who even mentioned rendering speed Because they rarely know about it. And why would they? It's a very technical choice. Factoring in things like render speed is your job when picking the most appropriate solution for the problem at hand. When you're doing this you are placing your own comfort and ease above that of anyone using the site. Google already factors site speed into rankings…

"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

Re: Advice to Young Web Developers

#193

Post by MattGaiser »

SPBS wrote: post #187
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…

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…

> The layers of abstraction will take its toll.

As an industry, this is called job security. It is fascinating to be in an industry where systems requiring high levels of maintenance are preferred by the client.

Re: Advice to Young Web Developers

#194

Post by ridiculous_fish »

schrute wrote: post #134
hejja wrote: post #132

Earlier quoted context omitted.

I'd think anything in the LISP family would qualify

You must understand the point I am missing. Why learn a language in the LISP family as a young developer? Does it somehow improve you overall?

Clojure is indeed mind-expanding. Unfortunately its most compelling ideas don't translate to non-LISPs, so I must sadly disagree with the "learn Clojure" suggestion. It's wild fun, but it's hard to apply the ideas to DayJob.

An example: threading macros. In a language like Haskell, partial application is optimized for left-to-right. `f a` substitutes the first argument; other orders are more awkward. Functions like `map` deliberately place the "most known" arguments first to aid in partial application. If they guess wrong the code gets twisty.

But Clojure's threading macros compose functions, while just letting you say where you want the argument to go:

  (as-> [:foo :bar] v
     (map name v)
     (first v)
     (.substring v 1))
Here `as->` creates `v` as a meta-variable which means "the result of the last function". The code seamlessly mixes the declarative and imperative. It's like nothing else.

Sadly no DayJob language has features like this, and Clojure has other weaknesses which become apparent rapidly. Clojure learning will leave you yearning.

Re: Advice to Young Web Developers

#195

Post by adrianhel »

mooneater wrote: post #75

If you step back from modern fullstack web development, it is stunning how much accidental complexity is needed to accomplish anything at all.

Another thing I painfully realized: It that is not a good idea to document HTML in HTML.

<details> <summary> It's not a good idea </summary> really. &lt/details>

Re: Advice to Young Web Developers

#196

Post by _waqas_ali_ »

SPBS wrote: post #187
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…

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…

This only applies to the use case of creating static websites with React. A lot of React websites are dynamic and comparable with websites built using PHP or other server-side frameworks. Even if you write html by hand while using PHP, you still need to maintain the server code and constant upkeep/maintenance will be required.

Re: Advice to Young Web Developers

#197

Post by uhryks »

siquick wrote: post #164
heavyset_go wrote: post #51

Earlier quoted context omitted.

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

So much this. Bad plugins and outdated versions, cheap hosting with outdated PHP versions, cheap development with bad code quality. WordPress imho is not made to last without regular maintenance.

Re: Advice to Young Web Developers

#198

Post by jkachmar »

RNCTX wrote: post #156
realtalk_sp wrote: post #146

Earlier quoted context omitted.

Can you point to some worthy examples of this as proofs of existence? And I mean something truly novel, and not simply a different way to do something we already can do.

https://github.com/steve-chavez?tab=overview&from=2016-10-01... https://github.com/begriffs?tab=overview&from=2016-10-01&to=... How many projects are there to automatically API-ify a database with auth boilerplate today? At least a few well funded ones, one recently funded by YC even. They came up with it in 2015? 2016? and still have a thriving project going with it. Looks like less than 10 people have more than 10…

Having followed the PostgREST project for years, it’s been wild to see the recent explosion of similar sorts of projects (as you describe); I’d very much believed this was a “solved problem”.

Re: Advice to Young Web Developers

#199

Post by jkachmar »

realtalk_sp wrote: post #150
mattwad wrote: post #42

Earlier quoted context omitted.

OTOH, if you use Flow or Typescript, it is amazing to be able to share type-safe interfaces across the stack (not code). I suppose you could get this from any compiled-to-JS language too.

The realization that this permits end-to-end fullstack type safety and allows some awesome things (like surfacing breakage at compile time in response to changes to the data model) is a quietly brewing revolution.

This is in constant tension with the point that GP is making though.

If you’re not _very_ careful with your software architecture, you can inextricably tie your frontend and backend applications together. Depending on the size of your product, or why the growth plans are for that particular frontend/backend app end up being, this might not be a problem.

If it becomes one, though, then every bad technical design decision made in that `common` set of modules or packages ends up hurting you as it gets unspooled from (at least) two components that likely have very different architectural idioms.

Re: Advice to Young Web Developers

#200

Post by jjav »

SPBS wrote: post #187
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…

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…

So much this. There is tremendous value in longevity. Writing content which is guaranteed to be unusable in a few years is anathema to me.

On my website I have pages which date back to 1993-94. Still readable just fine. I used to post those links to mailing lists back then and they still get regular hits from people in that community because I've also maintained the URLs constant.

Post reply on HN