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

261–270 of 328 posts

Re: Advice to Young Web Developers

#261

Post by kall »

willio58 wrote: post #90
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…

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.

When I open up the functions.php file of a wordpress site we didn't develop "maintainable and simple" is not what comes to mind.

Re: Advice to Young Web Developers

#262

Post by RNCTX »

imtringued wrote: post #222
jkachmar wrote: post #198

Earlier quoted context omitted.

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

CouchDB is a database from 2005 that can _only_ be accessed via a REST api.

And Solr in 2004, but a json store returning json is not really the same as building a highly performant SQL client that works over http with support for operations on ~45 to 50 data types.

Re: Advice to Young Web Developers

#263

Post by kall »

MrBuddyCasino wrote: post #233

> 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. If I had to pick just one, it would be this.

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.

Re: Advice to Young Web Developers

#264

Post by mediascreen »

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…

I feel like all agencies should stay away from JavaScript frameworks unless they are willing to be open with their clients on how much time will go into maintaining the project.

My agency regularly take over older JavaScript projects - built in whatever JS-stack was trending at the moment. There are always big parts of the stack that are no longer available or in active development. Not to mention the enormous hassle it is to bring dependencies up to date for a JS-project that hasn't been updated in three years.

Depending on the circumstances we usually recommend moving it to a boring CMS like WordPress unless there are compelling reasons to double down on the JavaScript stack (if it really is more of a web application for example.)

Re: Advice to Young Web Developers

#265

Post by timw4mail »

osrec wrote: post #241
runawaybottle wrote: post #105

Earlier quoted context omitted.

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.

I have yet to see this...

Re: Advice to Young Web Developers

#266

Post by Timpy »

adrianhel wrote: post #186
abnry wrote: post #174

Earlier quoted context omitted.

I left Firefox in 2011 because it was unusably slow on my macbook. My recent experience has been that it is much faster and I am considering switching back.

It's the snappiest browser at the moment and I love its render as text function and automatic ad blocking on mobile. I've made a permanent switch on mobile, but I tend to miss the Chrome dev tools whenever I use it on a computer. It's also wonderful that the browser is truly privacy conscious.

I know productivity takes a hit when you switch tools but FF dev tools are great, it just takes some getting used to

Re: Advice to Young Web Developers

#267

Post by mediascreen »

throwawaygh wrote: post #117
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…

Serious question: if the business just needs a static site, why are they paying tons of money for bespoke software engineering? Just use one of the millions of good-enough and free site builders out there.

I think there are a few issues:

1. Site builders are still hard to use for most marketing staff, if the site should look professional and you need a few small integrations.

2. They don't mind paying for a solution where someone else does the work.

I guess it's hard for marketing departments to pick an appropriate agency and to know the consequences of the technical choices the agency makes. They generally evaluate based on design and then have a few requirements like: resonable performance and support for a handful of features in the backlog.

Re: Advice to Young Web Developers

#268

Post by davnicwil »

Fradow wrote: post #253
davnicwil wrote: post #227

Earlier quoted context omitted.

> "client should only be able to query objects the user account has access to" > "client should only be able to perform certain kinds of transactions and mutations" The solution to these is equal for server rendered HTML containing {data} or an API just getting {data} in raw form - the request contains an access token which identifies and authorises the user - same goes for mutations on {data}. The answer to the ques…

In an ideal world, probably, or using {insert technology here} that does that natively, yes. In my experience, it hasn't been the case: designing a REST API (I know REST complexifies the API compared to tailored RCP) that behaves properly for the client is magnitude more work than rendering HTML with data server-side. The main difference is switching the question from "what does this page needs to render for this use…

I agree 100%, and it all depends on what problem you're solving for. For the 80% case of having an API which just serves one or a few of your own clients with their UIs architected into broadly similar views, I basically just go for an additive model of providing a default RESTful API but then additional view-specific, and then if necessary even client-specific, endpoints on top where this makes sense.

Honestly most of the time you can even just cut out the REST layer except where it overlaps with views by coincidence. For instance in practice there are quite a lot of views which simply get a single resource, or list a single type of resource with paging.

For mutations I am a big fan of just doing it RPC-style. I know it's not to everyone's taste but I feel like abstracting mutations out behind a model of RESTful resources and verbs is, 99% of the time, a waste of time, the notable edge case being where you truly need a flexible API for 3rd parties (both apps with UIs and scripts) where organising functionality in this completely generic flexible way - with the considerable extra effort that you mention being the price to pay - has huge payoff.

Re: Advice to Young Web Developers

#269

Post by bigiain »

imtringued wrote: post #209
bigiain wrote: post #203

Earlier quoted context omitted.

What do you base that thinking on? Amazon, Google, Walmart, Mozilla, and Yahoo all have numbers that say otherwise. "Amazon and others found that removing 100 milliseconds of latency improves sales by 1%." I'm 100% sure there are people who care about 1% differences in sales, and the fact that has been rediscovered independently by different organisations shows that "people" at least "aren't happy" with very small in…

I don't think rerendering an entire webpage on the server side every time a new chat message arrives is a good idea. There might be people that misuse SPAs when server side rendering is the better choice but SPAs clearly have use cases that are not possible with just HTML.

> I don't think rerendering an entire webpage on the server side every time a new chat message arrives is a good idea.

Sure, but that's pretty much cherry picked whataboutism when the parent comment we're talking about said: "Most people are happy if the page loads in reasonable amount of time".

So apart from people writing chat messaging widgets for websites, do you have data to contradict the conclusions about webpage load times and rates of change of user behaviour that can be obviously drawn from the Google/Amazon/Walmart/Mozilla/Yahoo data?

Re: Advice to Young Web Developers

#270

Post by danielheath »

ehnto wrote: post #208
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 like a post from an upside-down world to me. I suspect that perhaps you've learned primarily front-end frameworks for the majority of your career (an assumption, sorry if that's not right), which will make it seem as though frontend is easy compared to all this mystery stuff you're not used to working with. It's the same for me, but the other direction. I've always worked with server-rendered applications, so…

I don’t know; I’ve got 8 years building JS-heavy frontends and more than that building backends / ops.

React isn’t too bad, as such things go, but compared to server rendering SPAs are such a slog.

There are good reasons to build them sometimes, but “fast and easy” is not one of them IME.

Post reply on HN