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

251–260 of 328 posts

Re: Advice to Young Web Developers

#251

Post by nemetroid »

em-bee wrote: post #182
arkis22 wrote: post #170

Earlier quoted context omitted.

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

the efforts to write code for a javascript frontend framework vs a backend framework are exactly identical. there really is no difference. you save absolutely no effort by keeping html generation in the backend. the differences are rather in the architecture. you can win or loose a lot there, by choosing the right or wrong one. by creating an SPA you win a much simpler backend, you separate data storage and processin…

> you win the ability to have multiple different frontends against the same backend, or run multiple backends against the same frontend.

> you win the ability to upgrade/replace backend or frontend independently.

> you win the ability to develop with multiple independent teams because the connection between frontend and backend is smaller and easier to define.

> you win the ability to reuse generic backends over multiple projects...

None of these are really specific to SPAs, they apply to any architecture with a separation of concerns.

Re: Advice to Young Web Developers

#252

Post by indigo945 »

tdeck wrote: post #221
davnicwil wrote: post #213

Earlier quoted context omitted.

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…

By security I mean pretty basic things like "client should only be able to query objects the user account has access to" and "client should only be able to perform certain kinds of transactions and mutations". On the back end that's not too tedious - just make sure I only query for what I want. But with a SPA I can't just assume the client will make only the "right" queries, otherwise I could just expose a SQL query…

    > (Aside: I realize that back in the day people did indeed 
    > use database mechanisms like DB users and stored 
    > procedures to do what I describe, and then client apps 
    > connected directly to the database. But this practice 
    > seems to have faxed and isn't readily doable on the web 
    > anyway).
This is actually exactly what postgREST does for you. So in that case, you actually can eliminate the backend entirely and run the entire application in the frontend, with the security provided by stored procedures and row-level security. I think Firebase, which is somewhat more widely used, also enables a similar architecture.

That said, I actually agree with your preference for server-side rendered applications. The problem is that from the browser, you can't really do anything that is not SQL -- you can't, for example, call into a C library, query a legacy API, and so on. Of course, all of that can be solved by deploying more microservices, but that not only means you have to think about API design again, it also increases operational costs. Unless you need lots of fancy live-updating things, server-side rendering is still fine, and even when you do need to update dynamically, there's Blazor Server now.

Re: Advice to Young Web Developers

#253

Post by Fradow »

davnicwil wrote: post #227
tdeck wrote: post #221

Earlier quoted context omitted.

By security I mean pretty basic things like "client should only be able to query objects the user account has access to" and "client should only be able to perform certain kinds of transactions and mutations". On the back end that's not too tedious - just make sure I only query for what I want. But with a SPA I can't just assume the client will make only the "right" queries, otherwise I could just expose a SQL query…

> "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 user", to "what are all the things the front-end might want to access through this API for this user, and how do the front-end plan on filtering". The former is obviously easier to answer, and as the result easier to code.

Re: Advice to Young Web Developers

#254

Post by williamdclt »

non-entity wrote: post #17
mroche wrote: post #5

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

Nothing pisses me off like getting a message that some website only supports Chrome in 2020

I've never seen that in 2020, except on proof-of-concept website doing crazy stuff with modern browser APIs. How often does that happen to you?

Re: Advice to Young Web Developers

#255

Post by [deleted] »

enriquto wrote: post #237
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.

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

[deleted]

Re: Advice to Young Web Developers

#256

Post by kall »

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…

(API-less) react websites today will still be around in 10 years time. The browser has never and likely will never break JS backwards compatibility.

Re: Advice to Young Web Developers

#257

Post by born2web »

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.

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

Re: Advice to Young Web Developers

#258

Post by kall »

arkis22 wrote: post #170
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. R…

How are you "simply rendering the correct server side html"? Presumably with some kind of framework and/or template engine and/or programming language? I don't see how that's all that different.

Re: Advice to Young Web Developers

#259

Post by onli »

andai wrote: post #220
3131s wrote: post #173

Earlier quoted context omitted.

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

Every new windows FF can open opens immediately on my system. What kind of window are you opening there?

Re: Advice to Young Web Developers

#260

Post by kall »

arkis22 wrote: post #205
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…

No, we're really pretty close. SPA frameworks query the server for JSON and then render HTML right? Simpler in the sense of what? You prefer to not have all of the variables available when you render HTML? It's simpler to only render client side HTML and to query 4 different AJAX endpoints for resources? Why are you trying to separate business and interface logic? Why are you displaying anything that the business log…

Modern SPA frameworks (-> next.js) offer a similar 1 file code style and require no (manually written) api routes.

The end result looks very similar to the server side frameworks of old, so it's a bit of a circular evolution. I think only using one programming language (the one that is part of the web platform) and a solid, template free component framework make it incrementally better though.

Post reply on HN