151–160 of 286 posts
I think the next major change will be unified hybrid rendering. Render the initial view via SSR for speed, framework automatically injects more and more of the page transparently as user-driven events happen. All of this will be transparent and you only write the app once.
That's what frameworks like NextJS do.
Earlier quoted context omitted.
> a clear separation between frontend and backend devs I love the 'CHAMP' stack, which stands for CSS, HTML, Apache, MySQL and PHP. ;) Clear separation between frontend and backend. I'm almost happy that I started webdev in the 90's. This 'ancient' technology is still going strong, with websites and a whole lot of webapps.
So how do you handle any interactivity that’s not a user click? Like say, mousemove, or keypress?
The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.
Specifically, it depends on context. How big is the app? How many people are involved in building it?
As with many things, separation of front and back ends grew out of web-scale companies and products. If you're buiding Facebook or Spotify or Gmail, then you need a way to partition your app - because you need to partition your people. Humans need structure, we don't deal well with single teams of multiple hundreds.
Many apps don't fit that model. Lots of apps - e.g. business internal apps - might target at most small 100s of users and justify a dev team of None of which says "separate UI & back end is universally wrong". But it's not universally right either. As is so often the case, it degenerates into a discussion that is technical and absolute when the underlying forces are organisational and relative.
Earlier quoted context omitted.
SSR has more potential for security issues because you're often rendering some set of data from your database, which may come from a user, out to a browser which will then parse and execute code based on that rendering. You have to be sure your data going into the database doesn't have XSS escapes or your rendering of untrustworthy data doesn't have such XSS escapes. Which is why you shouldn't roll your own SSR unles…
This isn't a difference between SSR and SPA, it's a difference between using a modern framework and rolling your own. If I get a user-provided string from the server as a JSON property and set it via `.innerHTML =`, I have an XSS vulnerability. If I use React's JSX string interpolation, I don't. If I get a user-provided string from a database and inject it with a PHP ` ` tag directly, I have an XSS vulnerability. If…
Everything rendered by the server has this potential as it must be deserialized by the browser.
> What important truth do very few people agree with you on? Seems like answering with SSR would fail a Thiel interview for two reasons: 1. It's not important (in the grand scheme of things) 2. It's not a view that very few people hold. SSR was the standard way to do things for a couple of decades up until frameworks like React, and React itself now implements SSR, doesn't it? Thiel uses this question to try and dete…
There is often opposition - if the company I work for asks "what should we build the next app on?", React is the default answer that doesn't need convincing anyone, while SSR is much harder to sell (even when it makes complete sense).
Earlier quoted context omitted.
This isn't a difference between SSR and SPA, it's a difference between using a modern framework and rolling your own. If I get a user-provided string from the server as a JSON property and set it via `.innerHTML =`, I have an XSS vulnerability. If I use React's JSX string interpolation, I don't. If I get a user-provided string from a database and inject it with a PHP ` ` tag directly, I have an XSS vulnerability. If…
You have to explicitly use .innerHTML. As I said, "do work", not that it is impossible. No SPA frameworks do this by default. The default is $DOMElement.textContent = value, which has no escape potential. Everything rendered by the server has this potential as it must be deserialized by the browser.
No, but I've definitely seen bespoke, hand-rolled frontend code do it. You can't select SPA frameworks as representative of frontend rendering but look only at hand-rolled PHP from 2002 for backend rendering.
No major SSR framework is XSS-vulnerable by default. Whether you're using Rails, Laravel, Spring, ASP.NET, Phoenix, or whatever, every template engine escapes your strings unless you opt-in with something like Rails's `html_safe`, and they have for over a decade. Unless you've built your own SSR framework by hand with raw string interpolation, the "easy" way to do things is also the right way, just as it is in React.
This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…
I disagree with this premise.
Dynamic languages don't have builds either.