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

211–220 of 328 posts

Re: Advice to Young Web Developers

#211

Post by ehnto »

jjav wrote: post #200
SPBS wrote: post #187

Earlier quoted context omitted.

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.

In my personal life I serve HTML, CSS and native, gracefully degrading JS (if any), for the same reasons.

In my professional life though, I realised that 95% of the things I build will be changed in the next year or so. We often inherit projects that were only just finished, and our first task is to start changing it entirely.

So I aim for robustness of maintenance rather than robustness of the finished product. It's inevitable that it will change, but I can anticipate that in the same way a well engineered car can anticipate it's maintenance cycles.

Re: Advice to Young Web Developers

#212

Post by Scarbutt »

em-bee wrote: post #204
arkis22 wrote: post #189

Earlier quoted context omitted.

Loose is a word that describes knots. You are obviously writing more code for client side HTML generation based on JSON than regular server side rendering... I am saving effort if I need to write fewer files... Your feature requires a JSON route, html rendering, and javascript that pulls everything together. Mine is just a route that returns HTML. Why is there absolutely no difference in effort? You have 3 files, I h…

we won't be able to answer this without specifically comparing framework by framework. some frameworks make your code more complex, some help keep it simple. i have used different backend and frontend frameworks, and i found that backend frameworks do not make things simpler in the sense that you are talking about, if you want to create clean and maintainable code. sure you can put everything in one file, but the num…

an API is an abstraction. you can do away with that if you generate html in the backend

You can still and should have an API but it will be an internal one(in-process, not at the network boundary).

Re: Advice to Young Web Developers

#213

Post by davnicwil »

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…

Curious what you mean by the API flexibility Vs security point. To me, the API for a SPA is just another view over the exact same data that would be accessible in the HTML output of a server render (which, indeed, is the 4th point in the article). Your access to that data is gated by a cookie with a token in it in both cases.

On the code level, it's really not all that different - the operations you perform 'directly' through function calls in a pure server render model you simply put behind another HTTP interface.

I get that this mapping work might be a bit cumbersome and take some extra work, but I'm unconvinced that it introduces some kind of security tradeoff - the client ultimately has the ability to call through to exactly the same operations, just getting the data back in a different format, right?

Re: Advice to Young Web Developers

#214

Post by black3r »

speedgoose wrote: post #37
cglace wrote: post #22

Earlier quoted context omitted.

The one that drives me crazy are websites that say they only support safari on iOS... It’s all safari under the hood.

Safari on iOs is a bit special. Some features are missing compared to the Mac version. You also need quite a few safari ios specific code if you want to build a web app. But this is a bit broken since Apple wants you to publish to the appstore and not release web apps anymore. You also need a Mac to debug safari on iOs. I hate Safari.

You don't need a mac to debug safari on iOS. There is remotedebug-ios-webkit-adapter. You need a Mac to debug Safari on Mac. Maybe that's the reason why some people only support Safari on iOS.

Re: Advice to Young Web Developers

#215

Post by arkis22 »

Scarbutt wrote: post #212
em-bee wrote: post #204

Earlier quoted context omitted.

we won't be able to answer this without specifically comparing framework by framework. some frameworks make your code more complex, some help keep it simple. i have used different backend and frontend frameworks, and i found that backend frameworks do not make things simpler in the sense that you are talking about, if you want to create clean and maintainable code. sure you can put everything in one file, but the num…

an API is an abstraction. you can do away with that if you generate html in the backend You can still and should have an API but it will be an internal one(in-process, not at the network boundary).

An API is not an abstraction. It is LITERALLY how your program is communicated with. The API of a website is http.

The code inside the API is an abstraction.

Re: Advice to Young Web Developers

#216

Post by imtringued »

laurentdc wrote: post #27
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…

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

I can't count the number of times I had to write a HTML template for a small component with just jQuery and it was horrible every single time. Something like htm+preact [0] would clearly do the job much better and only add 5kB of Javascript to your site instead of leaving an unmaintainable mess.

[0] https://github.com/developit/htm

Re: Advice to Young Web Developers

#217

Post by arkis22 »

imtringued wrote: post #210
arkis22 wrote: post #178

Earlier quoted context omitted.

any JSON request you make to the server to render html can be replaced by a single request to the server that replaces HTML. It's simpler to do the latter.

No it isn't. Now you need to keep client state on the server. Have you ever used JSF? It's doing what you describe and it's the worst framework I have ever used. Yes it's even worse than using PHP+Apache without a framework.

You always keep client state on the server in the sense that the DB keeps track of sessions and the server keeps track of caching.

Never trust the state of the client... Never trust client's input...

No idea what JSF is. Sorry it didn't give you access to the data you needed when you rendered files.

Re: Advice to Young Web Developers

#218

Post by imtringued »

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.

Documentation doesn't change in real time.

Re: Advice to Young Web Developers

#219

Post by sbergot »

Animats wrote: post #201

"The web is built around server-side rendering." That's the React definition of "server side rendering", where HTML gets generated on the server. Real "server side rendering" would mean generating an image server side and shipping that.

"rendering" in a web context is pretty commonly interpreted as "creating the html document". It is not specific to React.

Re: Advice to Young Web Developers

#220

Post by andai »

3131s wrote: post #173
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 :(

Firefox must have performed poorly on Windows / MacOS in the past, because Firefox on Linux was never actually that bad. I've used Firefox for 15+ years now and never had the problems that people talk about.

Tried it again last week. Still slow, I'm afraid, despite Mozilla literally inventing a new kind of programming language to speed it up!

A lot of it has to do with design, though. ie. when opening a new window, Chrome draws the window instantly and then fills in the UI, while Firefox waits until the window is completely built to display it. Even though they become usable at roughly the same time, Chrome responds instantly to the command while Firefox exhibits zero sign of life for hundreds of milliseconds.

Post reply on HN