Practical Front-End Architecture
jaredgorski.org
Practical Front-End Architecture
1–10 of 164 posts
Re: Practical Front-End Architecture
#2I really love this kind of article because, as primarily a Backend developer, I'm finding it really really hard to make a "clean" SPA without any mentorship or help from experienced Frontend Devs. I can't find any well-documented best practices or architectures and patterns that seem to be widely accepted in the frontend ecosystem like there are for backends. Next is the closest that comes to having a "right way" but I think it's way too complicated for things I would consider a JS-heavy SPA for, which are all mainly client-side apps (Like in this article - I wonder why they chose Next since they're blocking out SSR entirely). Elm is perhaps better but I think the ecosystem is lacking compared to React and Next, and it really does its own thing so I can't be sure what I'm learning applies broadly to frontends.
Every time I think of making an SPA for a side project I hit up create-react-app, look at the uncomfortably blank canvas, and go back to Rails with ERB. TBF for most purposes Rails + Turbo gets you really, really far - just look at GitHub.
Re: Practical Front-End Architecture
#3I like these sorts of articles. Where people describe their stack/architecture, how everything fits together, how they're using it to face their challenges, and what are the challenging parts of their setup. I feel like they can often condense many insights in a relatively short piece. I would even love to see a more in-depth version of this, describing more use-cases and how they're being dealt with, or more pain points in the setup.
Edit: looks like my comment is oddly similar to @d3nj4l's. Nice to see I'm not the only one!
Re: Practical Front-End Architecture
#4I think this article shows how far we still have to go. Things like SSR with Apollo (or some other data layer) should be a solved problem by now, and not require every developer to ask themselves these questions again and again. Thankfully I think the next.js team has been doing really great work in that area so I’m hopeful for the next couple years.
Re: Practical Front-End Architecture
#5I get the appealing of SSR with frameworks like Next.js (e.g., you get to develop frontend components using React, which is nice). So, my question, for the ones who know, would be: if in the following years a new generic (backend) programming language emerges that allows building frontend components in the backend (think of PHP + Html, but better; or think of Golang templates but better) as easy as it is to build components using React, then that would mean we wouldn't need anymore a myriad of different technologies: a frontend library (React), a frontend framework (Next.js) a middleware (Apollo), and a backend api (let's say Python/Go/PHP/whatever). We would only need one technology: the new generic (backend) programming language in which you can build frontend components and write business logic as well. We would be back to the 90s (think PHP + Html, but better).
Re: Practical Front-End Architecture
#6I get the appealing of SSR with frameworks like Next.js (e.g., you get to develop frontend components using React, which is nice). So, my question, for the ones who know, would be: if in the following years a new generic (backend) programming language emerges that allows building frontend components in the backend (think of PHP + Html, but better; or think of Golang templates but better) as easy as it is to build com…
The Phoenix framework for Elixir supports something like that with its "LiveViews".
A few other backend frameworks for other languages also have something like that.
Re: Practical Front-End Architecture
#7I really love this kind of article because, as primarily a Backend developer, I'm finding it really really hard to make a "clean" SPA without any mentorship or help from experienced Frontend Devs. I can't find any well-documented best practices or architectures and patterns that seem to be widely accepted in the frontend ecosystem like there are for backends. Next is the closest that comes to having a "right way" but…
I'm in the same boat. But I don't think there's a lack of good info, but rather there's too much info and too many variants and options. There are probably many "correct" choices in the beginning, but we naturally want the good beginning and good long term maintainability/extendability.
Rails without a JS frontend is excellent in so many cases. The trap is when you start adding a little JS here and there to make things nicer, but soon you end up wishing you had just started with a fully JS frontend.
What I'm hoping for is a configurator/wizard where you can choose your options, and then you get a fully functioning foundational system to start from. Yes we can do it all by hand, but especially when it comes to auth and some other needs, the configuration can be a bit messy (because some details are always changing).
Re: Practical Front-End Architecture
#8I get the appealing of SSR with frameworks like Next.js (e.g., you get to develop frontend components using React, which is nice). So, my question, for the ones who know, would be: if in the following years a new generic (backend) programming language emerges that allows building frontend components in the backend (think of PHP + Html, but better; or think of Golang templates but better) as easy as it is to build com…
The eventual linchpin is roundtrip latency. If you want to have a frontend with native level responsiveness, you simply can not move all logic to the sever. Physics will get in your way.
So any universal solution will have to include strong client side prediction in addition to handling the server (something the game industry has understood and implemented for years, and I remain confused as to why it has gained near 0 traction on the web).
To my knowledge Meteor is still the only frameworks to explore down this path, but it has never really caught on. Does anyone know of any frameworks that acknowledge this issue and manage both server and client side accordingly?
Re: Practical Front-End Architecture
#9I really love this kind of article because, as primarily a Backend developer, I'm finding it really really hard to make a "clean" SPA without any mentorship or help from experienced Frontend Devs. I can't find any well-documented best practices or architectures and patterns that seem to be widely accepted in the frontend ecosystem like there are for backends. Next is the closest that comes to having a "right way" but…
Can I say an aside, it's refreshing to hear a backend developer talk about frontend as an equal partner in the picture, rather than disparaging it?
A lot of HN is quite anti-frontend, especially when it involves abstractions like React or even languages like JavaScript. It's great that backend devs are looking into our side of the fence and talking about rational pros and cons.
Re: Practical Front-End Architecture
#10I think this article shows how far we still have to go. Things like SSR with Apollo (or some other data layer) should be a solved problem by now, and not require every developer to ask themselves these questions again and again. Thankfully I think the next.js team has been doing really great work in that area so I’m hopeful for the next couple years.
> should be a solved problem by now, and not require every developer to ask themselves these questions again and again
This applies to so very much of web developement. We have spent so much collective time building web apps, and some have also put a lot of time into building libraries and frameworks, that with all the brainpower and effort, things should be easier now than they are.
I believe this is because we've had too much freedom. Not suggesting we should have stuck with C or Java, but it seems that many people who are motivated and intelligent have decided to build their own better mousetrap. So now we have 1,000 mousetraps. Or maybe 10,000. If we could somehow redirect that effort into 3-4 primary options, I think we'd be overall better off.
Take Wordpress for example. You can do just about anything with Wordpress and some custom plugins. It's a miserable experience mostly, but it's possible. Imagine if some of the smartest people behind some of the best frameworks and libs collectively worked on one new system (plugin-based). As long as there were a good plugin interface, the users (devs) could then use whatever language they prefer to provide business logic and customization.