Hacker News Reader

Comment by csmpltn | Hacker News Reader

> "Then having one language, no, one _shared code base_ for both client and server, which automatically can only send the minimum necessary over the wire? That's a _huge_ step forward."

This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about.

1. Why should having the client and server share the same codebase even be a goal in the first place? This should be a nuanced conversation with different trade-offs, there's no one-size-fits-all here. It's disingenuous to paint this as an ideal we all have to work towards on a whim.

2. I don't even know where's the innovation in being able to "send the minimum necessary over the wire". This is a pillar of decent software engineering. We've been severely regressing here due to the pervasive use of bloated abstraction layers, combined with a deep lack of understanding of how things work (ref. the Uncle Bob post I've linked earlier).

View on HN

> 1. Why should having the client and server share the same codebase even be a goal in the first place?

Because, in building complex and dynamic web apps, the alternative is to repeat a lot of the same logic in both frontend and backend.

Of course if you are building a blog or a simple static page this is not useful, most of the new techniques are a response to more advanced requirements.

For instance, right now I'm building a "buy form" for internal use (by employees only) in a shop. There is a ton of domain login used to select which field to display, what validation login to use, how to autocomplete some fields ecc ecc. The system is a PHP/Laravel server with SSR rendering and vue only used for some specific advanced components. Most of the logic inside the form has to be written two times: in PHP and in vue. Most enum types are repeated (and must be kept in sync). Having one shared codebase would simplify A LOT the development.

> "Most of the logic inside the form has to be written two times: in PHP and in vue"

Why?

That's just your choice of how to build your app, right? You could've avoided this by rendering templates on the server and sending static HTML to the client, keeping the business logic on the server.

> "Most enum types are repeated"

Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/

> Why?

To take just one of many examples, so that you can do the same validation client side and the server side. You have to do the validation on the server because the client can't be trusted, but if you only do it on the server you have to do a full page load to validate any of the inputs, give feedback, or vary the form fields displayed.

e.g. how many times have you filled out a long and complicated form, pressed submit, waited several seconds, and then get dropped back at the same form where you have to hunt for the error message, change the requested field and try again. And heaven help you if you got multiple fields wrong, where the data from one informs the validation of another. Client-side logic can make this process much lower friction.

> That's just your choice of how to build your app, right? You could've avoided this by rendering templates on the server and sending static HTML to the client, keeping the business logic on the server.

No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole page is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance.

> Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/

Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea

> No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole page is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance.

You can have the backend render partials and only send the affected part. This has been widely in use and battle-tested for about two decades in .NET WebForms, PJAX, Rails Turbolinks and other technologies.

Also, wether the app does this or that is completely orthogonal to how you build it. You don't need tho share code with the backend.

> Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea

Except for cases where the team doesn't know anything other than JS, using this is significantly simpler than forcing the whole backend to be in JS. Also, there are several other options.

> You can have the backend render partials and only send the affected part. This has been widely in use and battle-tested for about two decades in .NET WebForms, PJAX, Rails Turbolinks and other technologies.

No, rendering partials is not a solution once you have a moderately complex app.

Example: The user submits a form to change an entity, you need to send a partial back for the successfully submitted form, but you also need to send partials back for potential 2-3 other places that the entity is displayed on the page, even if they are not displayed on certain pages.

Just tracking and updating them whenever they change is a pain in the ass, not to mention the increased processing/bandwidth for no reason.

The solution to this completely hypothetical an unrealistic problem is to just not have too many partials to begin with. Which is the reality of 100% of the apps made with the libraries/frameworks I mentioned, WebForms, PJAX and Turbolinks.

Ok then what benefit is there over a regular page load?

Faster response to user actions, smaller payload, not reloading the whole page, keeping scrolling position, keeping focus and keyboard cursor position when possible, allowing transitions and animations, no need to change browser history unless necessary, very minimal javascript necessary, allowing user to disable javascript in some cases.

Just because this is a counterexample to something that you deem good, it doesn't mean it has to be absolute shit. The world is not black and white. I would suggest at least doing some research about how things work before criticising them. They might surprise you.

> Except for cases where the team doesn't know anything other than JS, using this is significantly simpler than forcing the whole backend to be in JS. Also, there are several other options.

Of course you shouldn't use a full-js stack if your team of developers doesn't know JS, no one is arguing that because it doesn't make sense.

I never claimed you argued for that. I'm simply stating the cost of each solution. Thrift is definitely much simpler in practice in all cases, except the case I mentioned as being an exception.

> "Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea"

This too, demonstrates the point I raised earlier.

Instead of using a mature, widely adopted and battle-tested system which allows you to efficiently share code across multiple languages without introducing runtime hits - you instead discard it as some "huge dependency" and insist on having JS everywhere, using the latest hype of the week, consequences be damned.

Why actually spend the time to solve a problem in a mature way, when I can just add this week's shiniest NPM package to imports.json?

> Re-rendering the whole page everytime the user checks a box or clicks a button just to replace some fields in a whole page is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance.

In practice, the whole page re-render-from-server is often much faster. Compare how long loading indicators last on full-fat GMail versus Basic HTML Gmail and its full-page reloads. Fastest "web app" I've seen in the past five years was pretty complex, and it re-rendered on every action, even menu navigation. The backend? PHP. I'm in the center of the US and it was served from somewhere in Asia (Singapore, IIRC?). Still the fastest thing I've seen in a long time.

I'm pretty sure the "it's for performance" argument has been dead since we (the industry) stopped sending XML and HTML snippets for direct injection, and started sending JSON and then doing a bunch of processing on it before finally generating some DOM nodes and rendering something. In the wild, what we're doing is killing performance, not aiding it. At least two of your points are simply wrong (c, d), another is highly debatable (a), leaving only one (b) and I'm not sure that's worth the performance cost, at least in many cases.

Exactly. This way of working is such a breeze. PHP does the logic, the state is firmly in the database, and I'm from a time when peopling talking "frontend" meant HTML and CSS. Occasionally some plain JS, and I'm good.

Years ago I was out of the webdev field for some time, and I must admit that HTML and CSS alone have made big strides.

> and I'm from a time when peopling talking "frontend" meant HTML and CSS

When that is the case, the stack you are describing is just perfect even nowadays.

The problem is, in most cases that is just not the case anymore.

I guess that's it. It's the difference between the "application" and "document system" that some other commenter talked about. I guess the wisdom comes down to knowing which one to choose in what situation.

I myself am looking to find the edges of building a web application with the "document system". Clicks and requests for a full page load don't matter that much if you're able to keep your app simple. Which is also defined by context, not only by programming skills. Certain situations or applications are just not suited for the "document system".

> This is exactly the kind of non-nuanced, buzzwordy and handwavy advertising I was ranting about.

I spent four years working on a Meteor.js app. Meteor's main appeal is isomorphic code and a high degree of reactivity. As the app evolved we replaced the in-built MongoDB with GraphQL. It was nice to have one language and GraphQL was very useful. Eventually this kind of model may be the future, but the next project I did, instead of Meteor, I went with a more conventional Vue front end with REST & websocket api for the backend. The reason for the change is that while Node is really nice, Django and Go get predictable outcomes with less time spend on tooling, patching and updates. With a small team, losing lots of hours to "our build broke because an upstream dependency changed a function signature" is not a good thing.

Reply on news.ycombinator.com