3 ms·

I still believe good old sever-side rendering + js sprinkle is still the best business value for the buck. Our industry seems to not have analysis on engineerin

I still believe good old sever-side rendering + js sprinkle is still the best business value for the buck. Our industry seems to not have analysis on engineering cost compute with business value.

0xblinq 4y ago
Totally agree with this.
ARandomerDude 4y ago
Your specific recommendation really depends on your use-case. But I think the general principle applies, and you can even go further: try building simpler things. This is why I use static websites + a little JS and some API calls until I absolutely need my own server/SPA/etc.
- Existenceblinks 4y ago
  The technical lead needs to explain and link between highly interactive widget to business value. Breaking down feature/value to pieces and link each to what type of widget it needs. JS frameworks always sell like lets build the whole thing with this whole tools. It's not only not fined-grain solution, it's often mismatched. I don't buy the isomorphic thingy that reduces cognitive load because that's not only it's not absolutely true, it could be false and brings other type of problems.
leke 4y ago
I recently found htmx that allows me to do something like this in any backend language.
- Existenceblinks 4y ago
  I elaborate under the other comment. Htmx is good as long as there's not a lot of business value that needs highly interactive widgets. The whole thing is highly interactive sounds like a attempt silver bullet. The isomorphic invention currently doesn't solve client-server problems at all, it only solves 'I want to use one language' problem. Data still needs to live somewhere and move to somewhere, and there's physical distance between them, so it still has problems due to that condition.
chatmasta 4y ago
This is the best way to get Python devs to start using JavaScript. But if you're already writing in JavaScript (or TypeScript), why wouldn't you want to re-use the code on server and client? Next.js is basically modern day PHP - you create a file in /pages/foo/bar.ts and it renders at localhost:3001/foo/bar. It really doesn't get much easier than this, and anyone complaining about it has likely not tried it or doesn't have a green field project where they can start from scratch with TypeScript and Next.js. Also, this trope that "JavaScript can only render websites that require JavaScript to read" is a common misconception. Next.js, for example, is perfectly capable of rendering websites that work for clients with JavaScript disabled. In fact, that was kind of the original point of SSR: to make websites that search crawlers could read by processing the HTML sent from the server. The server renders the initial page, and then the client (optionally, if following best practices) "hydrates" the DOM to render any further content that requires client-side interaction (indeed, it's bad practice to require hydration, and a mismatch between server rendered DOM and hydrated DOM will generate warnings in development).
andrei_says_ 4y ago
Exactly. slim-lang + htmx or stimulusjs and a single dev can replace a team.
satvikpendem 4y ago
I agree, that's why I like NextJS that gives you the DX of thinking in reusable and composable components (React) and type safety (TypeScript) that then ships no JS at all to the client.
anileated 4y ago
I wouldn’t say the state of the art is particularly great, but interestingly enough server-side rendering + JS sprinkle is exactly what many modern frameworks like Marko are going back to. They provide some opinionated/convenient ways to author code but deliver fully server-side rendered HTML. They use fancy means to detect where interactivity is needed, and only ship JavaScript to the browser for those components. In fact, they make what you describe easier to achieve. When you do it on your own, it’s up to you to ensure one piece JavaScript doesn’t mess another piece up, it’s up to you to sync back-end with front-end—but with a good framework you get encapsulation, bundling, and typing with compile-time checks (if you removed an attribute from some object server-side but forgot to update the client side, your build will fail with a useful error message before you can deploy it).

I still believe good old sever-side rendering + js sprinkle is still the best business value for the buck. Our industry seems to not have analysis on engineering cost compute with business value.

0xblinq 4y ago

Totally agree with this.

ARandomerDude 4y ago

Your specific recommendation really depends on your use-case. But I think the general principle applies, and you can even go further: try building simpler things. This is why I use static websites + a little JS and some API calls until I absolutely need my own server/SPA/etc.

Existenceblinks 4y ago
The technical lead needs to explain and link between highly interactive widget to business value. Breaking down feature/value to pieces and link each to what type of widget it needs. JS frameworks always sell like lets build the whole thing with this whole tools. It's not only not fined-grain solution, it's often mismatched. I don't buy the isomorphic thingy that reduces cognitive load because that's not only it's not absolutely true, it could be false and brings other type of problems.

leke 4y ago

I recently found htmx that allows me to do something like this in any backend language.

Existenceblinks 4y ago
I elaborate under the other comment. Htmx is good as long as there's not a lot of business value that needs highly interactive widgets. The whole thing is highly interactive sounds like a attempt silver bullet. The isomorphic invention currently doesn't solve client-server problems at all, it only solves 'I want to use one language' problem. Data still needs to live somewhere and move to somewhere, and there's physical distance between them, so it still has problems due to that condition.

chatmasta 4y ago

This is the best way to get Python devs to start using JavaScript. But if you're already writing in JavaScript (or TypeScript), why wouldn't you want to re-use the code on server and client? Next.js is basically modern day PHP - you create a file in /pages/foo/bar.ts and it renders at localhost:3001/foo/bar. It really doesn't get much easier than this, and anyone complaining about it has likely not tried it or doesn't have a green field project where they can start from scratch with TypeScript and Next.js. Also, this trope that "JavaScript can only render websites that require JavaScript to read" is a common misconception. Next.js, for example, is perfectly capable of rendering websites that work for clients with JavaScript disabled. In fact, that was kind of the original point of SSR: to make websites that search crawlers could read by processing the HTML sent from the server. The server renders the initial page, and then the client (optionally, if following best practices) "hydrates" the DOM to render any further content that requires client-side interaction (indeed, it's bad practice to require hydration, and a mismatch between server rendered DOM and hydrated DOM will generate warnings in development).

andrei_says_ 4y ago

Exactly. slim-lang + htmx or stimulusjs and a single dev can replace a team.

satvikpendem 4y ago

I agree, that's why I like NextJS that gives you the DX of thinking in reusable and composable components (React) and type safety (TypeScript) that then ships no JS at all to the client.

anileated 4y ago

I wouldn’t say the state of the art is particularly great, but interestingly enough server-side rendering + JS sprinkle is exactly what many modern frameworks like Marko are going back to. They provide some opinionated/convenient ways to author code but deliver fully server-side rendered HTML. They use fancy means to detect where interactivity is needed, and only ship JavaScript to the browser for those components. In fact, they make what you describe easier to achieve. When you do it on your own, it’s up to you to ensure one piece JavaScript doesn’t mess another piece up, it’s up to you to sync back-end with front-end—but with a good framework you get encapsulation, bundling, and typing with compile-time checks (if you removed an attribute from some object server-side but forgot to update the client side, your build will fail with a useful error message before you can deploy it).