#Complexities of Isomorphic Development

1 messages · Page 1 of 1 (latest)

lusty widget
#

Hi! I've written about the hidden complexities that come to play when moving frontend developers to the backend. Things not everyone seem to keep in mind when they say "it's an easy switch". I think it's an interesting read for folks working with remix as well. Let me know what you think?

https://twitter.com/meijer_s/status/1663605795727060994?t=hwFzs52xVXxLd6KHmWtNPQ&s=19

It's out. 🙂 This is why I've been saying that server components won't make frontend jobs easier. Spoiler, it has little to do with server components.

https://t.co/EEsnjHT4HX

eager nebula
#

Interesting article, I think that (as a frontend leaning developer) FE devs should understand how the BE and security works even though they are focused on frontend, you need to understand what goes to the server and what goes to the client but I think the biggest hurdle is understanding what isomorphic code actually is and what it isn't. This is a topic not covered as much as it should be. When I first encountered this term and googled it (before chatgpt) I couldn't even find a video or text that explains what isomorphic code is properly and barely dug up an article that explains it.

lusty widget
#

Thanks for sharing @eager nebula . I feel the same. There's surprisingly little attention for isomorphic code. I wonder if it's because I'm overthinking it.

eager nebula
#

Well I guess the reason for it is because it's very JS specific but the community is large tho. I think isomorphic code is the biggest production boost in Remix and Next because you can write utilities and use them on both sides. But many do not understand the boundary between web and node

lusty widget
#

Yeah, that might be it. It's surprising how many people see using Next.js still as "frontend development". The boundary is already blurry in node / javascript with code reuse.