7 ms·

Practical Front-End Architecture

176 points by jaredgorski 5y ago

d3nj4l 5y ago
I 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.
- blunte 5y ago
  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).
  - vagrantJin 5y ago
    > 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. Not sure if Yeoman is still around but did they not attempt something similar?
    - blunte 5y ago
      I know it has been attempted many times. But like the general problem of too many options, it doesn't gain enough attention and develop a critical mass. And in the case of setup tools, they tend to all suffer from the problem of being very difficult to change once setup. The tool you use to build the customized foundation is often unable to make future modifications if you have changed any of the generated code. But by now we know the 99% common options people want: a choice of a few databases, (probably but optional) user profiles and auth, etc. The database side is pretty much solved, but the user management is definitely not - and it's the source of so many data leaks.
    - dynamite-ready 5y ago
      Yeoman felt a little too much like a vehicle for one class of developers to foist architectural ideas on people. I'm glad it lost momentum. It would have accelerated the frontend tech churn if it took hold, not simplify or slow it down. It was also clunky to use, and created a situation where 2 or 3 people would compete to vend the canonical Yeoman config for a new frontend technology. In a way, it's been superseded by create-react-app and it's ilk, but I think those kind of tools are fine. If you're reaching for a tool like create-*-app, then you've already made a specific choice about a number of things, and it's just helping you to bootstrap the project. It going to happen again soon with WASM. But I'm welcoming that. We'll probably all end up writing full stack Ruby, or something.
- phist_mcgee 5y ago
  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.
  - enumjorge 5y ago
    In fact I’d say part of the problem with the front end ecosystem has been people trying to get by with shallow knowledge. Building a SPA (as opposed to a web page) is a technical and challenging problem. It’s people who blow that off who, for example, adopt Redux without understanding if they need it and then complain about the complexity in their codebase.
    - phist_mcgee 5y ago
      Spot on, any tool will look blunt in the inexperienced apprentice's hands.
- dgb23 5y ago
  > (Like in this article - I wonder why they chose Next since they're blocking out SSR entirely) They provided a bit of rationale (kind of sprinkled across the article). For me using Next over CRA as a default comes down to three things: - Batteries included, high utility components and defaults for things you ought to stitch together otherwise. CRA is not a drop-in replacement for Next, even if you only render client side. - Flexibility. Your project might just look mostly static (fully rendered at build time) , or server rendered, or client side rendered. It rarely is. If you default to Next you can easily extend and configure these capabilities (and more). - Great DX. It's a framework that respects developers with good documentation, flexibility and a "just JS/React" kind of philosophy. There is magic that you cannot easily break through as with every framework, but so far it seems they keep the magic boundary at the right place.
  - dSebastien 5y ago
    I feel like more people should look into Nrwl Nx to scaffold new projects: https://nx.dev/ https://nx.dev/ It supports Angular, React, Next.js, Gatsby, Storybook, Cypress, and a lot more. Maybe people don't hear about it, or they stop after reading the word "monorepo", while Nx is also great for stand-alone projects.
    - tvphan 5y ago
      Sounds like Vite?
- ehnto 5y ago
  I think that's my pet peeve with modern frontend tooling, they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. When I learned about OOP I was able to understand OOP code in a broad range of applications, languages and frameworks, but learning how react works gives me no insight into anything but react, and it's even abstracted enough from JavaScript that you could learn React without ever properly knowing how to write JavaScript (which is something I've encountered in a handful of new devs).
  - pc86 5y ago
    > they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. This is sort of an expected side effect of recreating nearly-identical JS frameworks every couple months, no?
    - mdtusz 5y ago
      I continue to see this idea posted in HN and Reddit programming threads and it comes across as ignorance more than anything. The reality is that nearly all new modern web applications will be written using react or vue, with a long tail choosing a more esoteric or experimental tool because it either fits the project requirements, or the team is willing to accept more risk in favour of some other benefit (often times just curiosity). Considering you have so few language options for frontend webapp development (excluding wasm and other such options), this really isn't a surprise to have a handful of options either. I can name more python server frameworks that are used in earnest than I can name frontend frameworks. Part of the difference for frontend frameworks is that there's so much variety possible. Nearly every server framework has the same general design and API - some kind of routing, route handler definitions, and some additional niceties like with, db connection handling, sessions etc. I can't conceive of any other design that would work better or even be sensible. While components have become the norm in front-end, there's still plenty of room for different architecture and actual API to use and define components, and manage state. That's where the fun of writing them comes in, and where there is still likely a better react or vue lurking in the shadows or yet to be created.
- chakkepolja 5y ago
  As someone without this new web tech background, I have same experience about react. create-react-app has so many dependencies and takes a lot of time to scaffold a hello world. Adding some router or some popular library produces deprecation warnings and '2 moderate vulnerability' messages. Folder size will blow up over 1 GB to make trivial apps. That's insane.
  - wlesieutre 5y ago
    And don't even think about using "npm audit fix --force", it wants to downgrade the react-scripts dependency from 4.0 to 1.1 and introduce another 50 vulnerabilities. Not the smoothest first impression for what's supposed to be the "on rails" introduction to react development.
    - chakkepolja 5y ago
      I found svelte ecosystem to be much lighter than react, svelte also being much smoother to write, but sadly it's still new and doesn't have the same amount of libraries that react has.
  - nicoburns 5y ago
    create-react-app is incredibly bloated. My current day job inherited a CRA app, and I've spent silly amount of time getting rid of the rubbish in there. But you don't need most of it. For a simple production-ready React setup try the following libraries: - react (obviously) - redux, and react-redux (which ties react and redux together), and redux-thunk (enables asynchronous redux actions). - react-router and react-router-dom (adapts react-router for web rather than react-native) That's 6 libraries, but it's really only 3 as the auxiliary ones under redux and react-router are tiny. If you need to support older browsers then you might also need core-js to polyfill the newer apis, but that's it. And if you use esbuild to build then you won't need need all the complexity that webpack brings.
    - acemarke 5y ago
      Hi, I'm a Redux maintainer. Note that you _should_ be using our official Redux Toolkit package to write all your Redux logic [0]. RTK is now the standard approach for writing Redux logic. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. RTK already includes common Redux-related packages like `redux-thunk` and `reselect` as well. We've updated the Redux core docs tutorials to teach RTK as the default [1] [2], and have examples of migrating existing Redux logic to use RTK [3]. As for the CRA aspect: I still don't really understand why some people refer to CRA as "bloated". It has all the standard pieces that have been used in the React ecosystem for years: Webpack for bundling, Babel for transpilation, Jest for testing, and ESLint for linting, and all with a very reasonable default configuration that has had thousands of hours of effort to deal with edge cases. I'm not saying that CRA is _perfect_. The maintenance has been spotty lately, it's taken a very long time for the Webpack 5 branch to get close to release, and I'd love to see CRA adopt tools like SWC or CRA to speed up builds. But given the problems in the ecosystem before CRA, it's done exactly what it was supposed to: provided a single command to set up a new React app with good build defaults. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://redux.js.org/tutorials/quick-start https://redux.js.org/tutorials/quick-start [2] https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... [3] https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
- recursivedoubts 5y ago
  There is a resurgence of interest in HTML (really, hypermedia) oriented front end libraries like Turbo, htmx (mine) and unpoly. The a majority of web apps being built today could be created at a fraction of the complexity by using these libraries, and they put full stack development back on the table.
- jrochkind1 5y ago
  Same spot as you. If you find any front-end "standard" that doesn't seem "way too complicated for things I would consider a JS-heavy SPA for", let us know! I think maybe it's just... unavoidably complicated. At least any present options are, which probably means it's hard to make one that's not or someone would have done it, right?
- yakshaving_jgt 5y ago
  Elm's architecture is practical, and I haven't found the ecosystem lacking after having shipped tens of thousands of lines of it over the past five years. I've shipped a bunch of big React applications also, but Elm is the one I would choose every time.
- jspash 5y ago
  Hold out for just a bit longer as I have. The pendulum is definitely swinging back the other way with regards to front-end development. Rails has some interesting things in the works with StimuluxReflex. Basically a SSR SPA. It's a bit like the original promise of progressive enhancement before javascript ate the world. ie. everything is server-side, then "enlivened" after with JS. So if/when JS fails, you still have a working website. Personally I prefer LiveView from the Phoenix(Elixir) framework. But my day job still uses Rails. There are similar projects in Django and PHP (Laravel, I think)
yarinr 5y ago
I 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!
sgdesign 5y ago
I 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.
- blunte 5y ago
  > 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.
  - qw 5y ago
    One of the benefits of Wordpress is that it runs on PHP. It's very easy to find a cheap web host and just copy the files over. Many web hosts even have a simple button that sets it up for you. A viable alternative would need to be just as simple, and currently that implies it should probably be implemented in PHP, which will exclude developers who want experience with "blog-friendly" languages.
    - blunte 5y ago
      PHP, _like Javascript_, can be great when used with some extra care. I have no beef with PHP (although omg do they waste space with curly braces on their own lines and vast amounts of indentation!) A good foundation can be in any language, such as PHP. But it needs to have a modern, better architecture with a more consistent base library/API for the plugin writers to take advantage of. WP is like 1.0 of this. We've learned so much in the last 10-15 years; it would be nice to have a completely rethought foundation. But for the plugins, I think there should be a standard interface layer (based on probably http, tcp, pipes, files, even memory stores for communication). Then plugins could be written in any language, hosted locally or remotely, and sandboxed.
sdevonoes 5y ago
I 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).
- r6203 5y ago
  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.
  - spinningslate 5y ago
    +1 for Phoenix LiveViews. The Nitrogen Framework for Erlang [0] is another in a similar vein (and pre-dates LiveViews). Another is lamdera [1] which I came across on the Elm Radio podcast [2]. I've never used it, but the focus on minimising accidental complexity between front and back end was appealing, (along with the use of Elm). [0] https://nitrogenproject.com/ https://nitrogenproject.com/ [1] https://lamdera.com https://lamdera.com [2] https://elm-radio.com/episode/lamdera/ https://elm-radio.com/episode/lamdera/
  - jstummbillig 5y ago
    LiveView is, unfortunately, somewhat of a footgun. The idea is super neat and works great on localhost -- but then somebody clicks a dropdown with a dynamically rendered list of whatever in production and has to wait half a second for a piece of UI to appear, and that's really bad.
- jstummbillig 5y ago
madis 5y ago
Finally! You've done it! All the other front end architectures Are meant to be non-practical. Say what's special your solution in the title. Avoid using empty words. Less nose, more signal
- jaredgorski 5y ago
  Right?! Yeah, the title should be “A few patterns we implemented lately”. I do have more thoughts specific to practical frontend architecture though, so I guess I’ll just hope you see the next post.
eric_b 5y ago
In my experience PJAX/turbolinks + server rendering will get you 80-100% of the way depending on use case. The remaining pieces can be filled in with careful and disciplined use of something like React/Preact or Stimulus.
- midrus 5y ago
  Love Unpoly for this https://unpoly.com/ https://unpoly.com/
ilkkal 5y ago
Got a big chuckle out of them describing server-side rendering as this new-fangled unproven technical risk of a technology :) I get the context, but it was still funny. Ah, back to editing index.php I guess.
- newshorts 5y ago
  Me too. This regularly reminds me that some folks don’t have full stack experience and are coming from a completely different background. I am subsequently much more deliberate in describing architecture these days to front end devs.
- lampe3 5y ago
  Because your index.php did not need to dehydrate and hydrate. Back in the days the apps were unresponsive, clumsy and user unfriendly. You really can't compare web apps with old websites or even forum software like phpbb. EDIT: The down vote of the PHP developer which still wants to write phpBB forum websites :) Good luck with that. I'm waiting for the article that complains about frontend development ;)
- jaredgorski 5y ago
  I’m with you :) It’s certainly nothing new, but the “buzz factor” impresses people who don’t know what it’s for and they implement it everywhere thinking it’s an improvement. The trend/gimmick culture in frontend is a real thing.
- yuchi 5y ago
  Sorry to be the “actually…” guy here, but actually… what the article describes is ISOMORPHIC server side rendering, which is very different from traditional SSR + client side dynamic behaviors. The fact that the same code can render the initial static page AND the dynamic client interactive UI is the point here.
danr4 5y ago
maybe a bit off topic but i'm still on the fence if front end will ever be "solved". The difference is that backend is always going to be some variation of CRUD, so the architecture isn't changing too much. front end being the actual user-facing layer means it will always evolve with human-computer interface (UX?). Mobile phones completely changed the way we thought about frontend, and it's just time until the next big change in form factor comes... and a bunch of new frameworks will pop up
- enumjorge 5y ago
  I’d say backend architecture is also changing. React is older than Kubernetes. I do get your point though that UI dev probably sees more variation since you need to adapt to the form factor of the user’s device, which changes significantly every few years.
- aantix 5y ago
  https://hotwired.dev/ https://hotwired.dev/
keb_ 5y ago
Hey all, as someone ignorant to this whole SSR/Next.js stuff: I understand that Next.js is particularly popular for creating landing pages that require strong SEO. What I don't understand is, in what way is it better than say, using something like HUGO or Jekyll? If you require some dynamic content, wouldn't it be easier (and faster to build) to use a SSG and ship the JS along with all the other static assets? What am I missing here? Thanks.
- vagrantJin 5y ago
  Trust your instincts. That gur feeling like you are missing something important is nothing more than psuedo FOMO. Its complicated and contrived for no good reason at all. SSG are good. Plain HTML is even better.
  - woutr_be 5y ago
    > SSG are good. Plain HTML is even better. I would always advocate for plain HTML, or some basic templating engine. But such a statement highly depends on your needs. Plain HTML is great when you know exactly what you're building. As soon as you're going for something a bit more dynamic, or when certain elements require conditions, you quickly move to either SSG or some for of SSR. Not saying you have to use whatever latest technology people are advocating, but use whatever makes sense to use. Plain HTML has its limitations, that could be solved with SSG or SSR.
- iaml 5y ago
  Both hugo and jekyll use some kind of templating engine, and as far as templating engines go, react is better in a lot of cases. Especially when you can leverage its ecosystem of libraries, or the components for react you already have.
gambler 5y ago
When an article starts by listing a bunch of tools using phrases like "easy", "simple" and "commonly used" as explanations why the tools were chosen, it's not an article about architecture.
cjonas 5y ago
This article is great timing. I'm working on a "next gen" FE app and it validates most my decisions. Only real difference in my stack is I'm using redux toolkit query to connect with a Rest API instead of GraphQL (GQL would be nice, but can't have it all). I'm a HUGE fan of antd! I've been working with it since like 2017 and it blows my mind what I can build in a few hours. I haven't used tailwind, but wanting to look into it. Anyone have practical advise for using tailwind alongside a component library like antd?
- jaredgorski 5y ago
  Using Tailwind alongside anything is pretty simple. It just generates stylesheets for you based on what you use. All you need to do is set up the build (so that it knows which style rules to include and which to purge) and then start using Tailwind classes in your markup. As for “best practices”, I’d say there’s not many problems you’ll run into using something like Tailwind. Any configuration improvements you make probably won’t break anything, but you should still read the docs before you get started.
BigJono 5y ago
> Therefore, we've elected to render our application completely on the client. On Next.js this means that we wrap our React app in a "client-side only" component that looks like this: > <pointless confusing newb-unfriendly code that invokes one of the most esoteric parts of the React API> > This component only allows our React code to render inside the browser environment, minimizing Next.js' server-side render runtime. Yep, sounds like a practical way to do what is literally the default. So does the 4 paragraphs of clusterfuck about integration between Next and Apollo. How many brain cells did your team kill figuring that one out just to decide on client side rendering? I've been using React and webpack for 6 years now, and interfacing with Rest APIs dependency-free using the standard library for at least as long as fetch has been around. All the commenters here are musing about how back end is so solved and front-end is a mess then lauding OP for posting about his "practical" stack at the same time? This stuff is literally the entire reason front end sucks. Front end has been solved for ages with a couple of simple dependencies and all anyone wants to do is write blogs about over overengineered and/or VC funded fadtech because they're terrified of having to write a few lines of simple code. It's not normal to just randomly spend a year "upgrading" to stuff that's barely been popular longer than that. I've been on projects that do just that, then on the next project we'll build a much bigger app from scratch in 3 months with 1/3rd of the team size.
- duncan-donuts 5y ago
  I was excited about this post, saw the stack, and noped out of there. I was hoping for a really simple approach but this ain’t it.
  - jaredgorski 5y ago
    I’m hoping to write a more general post soon about selecting tooling per-use-case, which certainly should not result in this overpowered and complex stack in most cases.
- yashap 5y ago
  Agreed. Having worked extensively with GraphQL, I’ve come to see it as a MASSIVE source of unnecessary complexity in almost all cases. Haven’t worked with Next.js, but using an SSR framework, then not using SSR, seems like a tonne of unnecessary complexity too. They even say: > At Liferay Cloud, our project lives behind authentication and our clients are enterprise-level, with relatively modern browsers and powerful networks. So, SEO and client-side limitations are not concerns for us. Therefore, we've elected to render our application completely on the client. So, why are you using an SSR framework then? The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack.
newshorts 5y ago
Been interviewing for a few roles lately and finding the new “react dev” eerily similar to those relying on jQuery back in the day. I ask vanilla js and low level layout/styling questions in my interviews (not gotcha questions, but instead what I consider to be fundamental skills indicative of experience) and am consistently met with confusion. Maybe I’m too old for this game and front end devs will never again need to know about addEventListener?
- rimliu 5y ago
  Just wait till HTML is rediscovered. "Hey, look, my content page is 2KB instead of 8MB"
  - lampe3 5y ago
    Senior Frontend Dev: HTML was never gone :) I have and still working on big e-commerce websites. For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved. What I see is the problem that people think that "Frontend development is easier than backend development". For me, they have different challenges and different ways of thinking. Getting a good full stack developer is kind of getting a good doctor, which has at least to specialities.
    - woutr_be 5y ago
      > What I see is the problem that people think that "Frontend development is easier than backend development". I hate that statement so much. Even had some serious arguments with "back-end developers" who were constantly mocking HTML/CSS/JS. Turned out that when pushed to do it, they just couldn't do anything and had to ask for help. Writing proper reusable HTML/JS isn't easy, it also requires thinking on how to structure and split up things. Especially when you throw some CSS into it.
      - midrus 5y ago
        I've been a backend developer for many years, and for the last 6 years I've been doing frontend. I can assure you those developers mocking frontend devs can't even do backend if taken outside their big ass framework (django, rails, symfony,etc etc), because they believe everyhing is as easy as those frameworks put it to them. Somebody that had to work outside of that where you have to take many decisions and make tons of trade offs and find how to organize code and manage dependencies, etc will understand better how difficult frontend is. True we sometimes overcomplicate things more than needed (redux, rxjs, etc...) but even when we do not, this is still freakin difficult to get right.
nprz 5y ago
I haven't spent much time with Next.js, but luckily React will soon natively support[0] SSR. Wonder if Next.js will still be around once React Server Components are fully released. [0]https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react...
- codybontecou 5y ago
  Will they also be supporting static site generation?
- andrewingram 5y ago
  In short, the answer is likely yes. React's server component stuff is about providing primitives to make it possible to address some of the downsides of the current approach to building apps/sites that follow the SSR-with-SPA-handover (hybrid rendering) model. There'll still be a need for more holistic frameworks that sit in front of React. SSR itself has been possible with React since 2014 (allowing for a few memory leaks), Next.js just eliminates a lot of the grunt work. The React team is working with the Next.js team (amongst others) to make sure there's alignment.
deleted 5y ago
[deleted]
ianpurton 5y ago
> Likewise, don't choose server-side rendering just because it's buzzy and sounds powerful. Server-side rendering does basically the same job as client-side rendering: generating HTML. Well not quite. With client side rendering you now have manage state in the browser as well as build API end points for each screen you want to create. It's a more complicated architecture.
axhl 5y ago
What a nice post. Thanks jaredgorski for sharing. OP, if you're reading this, could you expand on the rationale for going with Apollo over e.g. Relay?
- jaredgorski 5y ago
  Thanks for the positive vibes. Great question. In fact, that question has more to do with “architecture” than most of my post. The primary reason we went with Apollo is that it’s flexibility-minded and well-documented, making it easier for new engineers to work with. If everything was ideal, we’d use Relay. Relay’s patterns are better (IMO) but it can be confusing for new folks to use it idiomatically. So, it’s primarily a dev-experience consideration for us.
lampe3 5y ago
Sounds a little bit to more like: We are using every new technology because why not, but we don't think about our use cases. Things like "/items/12345/detail" let me believe that this is not a spa really? More like a good old MPA? I'm not sure if the chosen technologies are the right ones for the jobs. In general, I don't understand the trend to default to something like reactjs. We have and had alternatives. What I see is that people complain about technologies which are not build for what they are using. To get good performance and bundle size out of SPA like apps, you really need to put in work. Maybe a simple Laravel/RubyOnRails website would have been the better stack for a lot of projects which are right now written in reactjs/nextjs.
bern4444 5y ago
There's a lot in here that seems off if not quite wrong. Throwing errors to be caught higher up, the way they manage redirects, and the lack of discussion around managing state (which could on its own solve lots of these problems). So much of this seems convoluted and unnecessary for a very simple goal of building a dashboard. Their use of Apollo seems to provide no advantage over a basic REST API. There's frankly very little discussion about actual front end architecture. I'd expect a conversation on a React application architecture to focus on things like how is client side state managed? How is server state managed and kept up to date? Are the two mingled together or kept separate? How are they kept separate? How can you build reusable components? How can you avoid components bloating in size and scope etc Front End development today - especially with React - is so easy to get running with and there are tons of better articles that actually discuss front end architecture including lots of courses on common patterns. Beyond articles, open source projects themselves often provide great architecture discussions. Higher order components, react-query for server state, react-router for client side routing, building reusable behaviors with hooks are all good places to get started for actual architectural design
- jaredgorski 5y ago
  Great feedback. I’ve been wanting to write more about most everything you mentioned, but ended up writing about a few interesting patterns we implemented recently. I probably should’ve titled the post “A few interesting patterns we implemented recently”. As for state management solving the problems of pageload validation (instead of our error boundary and redirect mechanisms), can you provide an example?
  - bern4444 5y ago
    Totally, I think if this article were titled patterns it'd be more accurate. Architecture has a more specific meaning (at least to me). As for using state, when you use something like react-router, all those things, path parameters, query parameters etc are stored in state. You can build hooks that use the hooks provided by react-router to retrieve those values in a useEffect in the relevant components. The hooks you build can be responsible for validating the path/query params, coordinating route changes etc. The larger idea is to use your state as a means of coordinating messages that any component can hook into. So you could include in each of those detail pages a redirect route component that only fires when the hook you wrote detects that a page is invalid. To take this to another level. You could build a Higher Order Component that automatically embeds this ability (a redirect component with a custom hook) into your item detail pages so that it's automatic.
andrewingram 5y ago
Not planning on getting dragged into a debate about whether GraphQL is a good tech choice here (even though I won't pretend i'm not a massive fanboy). But the "with-apollo" Next.js example used as a reference (and then decried as being a bad experience and unscalable), is a pretty bad representation of how it can feel to use GraphQL with Next.js. I've never used Apollo in anger, but i've used Relay with Next.js for a few projects and it's been a dream. The biggest downside has been the size overhead of the Relay client itself (approx 40kb over the network), and the size of the serialized data (but that's the same price you'd be paying whether you were using GraphQL or not, just an unfortunate reality of the hydration model).
- jaredgorski 5y ago
  I’d love to hear more about your experience with that “with-apollo” pattern. I decried it without using it first, but I see the problem as a coupling/cohesion imbalance. What has it looked like in practice for you?
  - andrewingram 5y ago
    I've mostly used the Relay examples as a starting point, though they've generally need to be fixed up to avoid some bugs. In the olden days of getInitialProps (still available as an API, but its use isn't actively encouraged) things were easier and more elegant, getServerSideProps and getStaticProps both force things to be a little uglier. For my older (getInitialProps) approach, you can see a rough example here: https://gist.github.com/AndrewIngram/e974f63160af9df292fc39eeeab62e61 https://gist.github.com/AndrewIngram/e974f63160af9df292fc39e... Look at the last file (PostDetail.jsx) to see what it's like using GraphQL as part of a page (PostLayout isn't defined here, but assume it's just a regular React component using Relay's useFragment hook).
bacro 5y ago
The useValidation hook needs to add data to the dependency list of its useEffect or else it will run on each render unnecessarily.
- jaredgorski 5y ago
  Ha! Yes. It’s pseudo code though. Please don’t copy and paste it.
drewpc 5y ago
Not the OP nor the post's author. We have a similar stack (React + NextJS + TypeScript + Mobx) but use a traditional REST API using Django Rest Framework. There are some interesting topics in the post and in these comments that I figured I could expand on: 1. The primary reason we chose NextJS (with SSR) was to be able to write a declarative React component that is run on the server and the client. For example a button to follow or unfollow a page (think: like/unlike in social media). In the previous generation of our application, we wrote the button in PHP that rendered HTML and toggled UI state on the front end using JS/jQuery. That meant writing the button logic (and HTML/CSS) in two places instead of one. Now, we have a single React component that renders itself based on state; it's the same component on the server and client. 2. I don't understand the extra work to avoid SSR. SSR is great and can be used behind authentication--there's no actual need to work around it. Additionally, in a NextJS application, SSR is only used on the first page load. When you click from page to page, it's all client-side transitions. 3. @yashap said "The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack." Agreed. Same here. It's wonderful. In particular Mobx. A lot of the comments seem to say "I expected the article to talk about how to maintain state in a React application"--that's how. Use Mobx. No matter what reactive JS framework you're using, use Mobx to maintain "global" state. 4. The discussion of "why move to NextJS when my Webpack config from 6 years ago works just fine" is a good one. Two big reasons we moved to NextJS (away from a Webpack config from 7 years ago) were: the handoff from server -> client is more seamless and the developer experience with hot module reload for server + client sides was worth it. Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense.
- nicoburns 5y ago
  > Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense. Doesn't NextJS do the same? The alternative to compare to would be a plain setup without any heavyweight boilerplate. These days you could you esbuild, but a webpack config can be ~50 lines and quite simple if you build it up from scratch.
rawoke083600 5y ago
All good comments here... I think the reason we have so many fe/js/options is that no one option has jump out as 'x10 better' than the rest. Svelte for me at least gets close to 'it' - ymmv Sidenote(sorry for highjack): The ninja hackers/coders out there please code this next: Like you know how we have tree shaking for dead js/ts code ?(Really cool and impressive btw) I want to get "html tree shaking" - Im putting it in quotes since what Im after is: The least amount and/or optimized html that will generate the same 'view/end-result' of my current unoptimzed html. Maybe a case for optimal-auto-encoder ?
rawoke083600 5y ago
lol it would be funny if in a few years... Google(crawler) becomes good enough to read all text from images(they are probably there already and beyond) And instead of rendering html or static site generators...we just export everything as one or a few(for responsive) jpeg :) ?
cannabis_sam 5y ago
Practical for front-end devs, not so much for us users who have to live with laughably shitty js-reimplementations of decades old built-in browser functionality… Heaven forbid you’re on a shitty internet connection, these inane js-behemoths just die from a dropped tcp connection, since they’re built on the most optimistic assumptions about network connectivity. I remember when accessibility was a part of web development, but I guess the ROI was to low.
- jaredgorski 5y ago
  I did mention that our clients are enterprise-level. But I did fail to address a more general decision-making process regarding choosing frontend architecture. If I did (and I probably will soon), I would talk a lot about the egregious initial load times on too many blogs that roll crazy dynamic tools for what should be a completely static site.
  - cannabis_sam 5y ago
    Yeah, I’m sorry. Looking back at it, that comment was written in general exasperation with the current state of the web, not really at you in particular.
    - jaredgorski 5y ago
      Your exasperation is absolutely shared. Thanks for engaging
      - cannabis_sam 5y ago
        Thanks!
turtlebits 5y ago
Personally, I wish front-end frameworks were literally that, a set of files you can toss in a directory and serve (with nginx, apache, or any static host like netlify), with your backend as a separate deployable bundle. SSR, progressive enhancement and all these tricks to speed up load time aren't really necessary if you just keep complexity down and your bundle size small.
marsven_422 5y ago
Remember kids, the purpose of architecture is to minimize the cost of development, deployment and maintenance.
techpression 5y ago
If I understand this post correct they seem to like the idea of putting routes in the file system (Next uses magical file names as a way to generalize routes for those who haven’t used it). To me this makes absolutely no sense, a route doesn’t map to the file system in anything more than the most trivial index.html cases and you lose the ability to do things like “resource routes” to avoid mindless declaration of routes. On top of that, I would assume Next creates a route definition in memory anyways and doesn’t read from disk every request so it’s just pollution of the file system with the additional downside of making navigation unnecessarily hard.

176 points by jaredgorski 5y ago

I 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.

blunte 5y ago
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).
- vagrantJin 5y ago
  > 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. Not sure if Yeoman is still around but did they not attempt something similar?
  - blunte 5y ago
    I know it has been attempted many times. But like the general problem of too many options, it doesn't gain enough attention and develop a critical mass. And in the case of setup tools, they tend to all suffer from the problem of being very difficult to change once setup. The tool you use to build the customized foundation is often unable to make future modifications if you have changed any of the generated code. But by now we know the 99% common options people want: a choice of a few databases, (probably but optional) user profiles and auth, etc. The database side is pretty much solved, but the user management is definitely not - and it's the source of so many data leaks.
  - dynamite-ready 5y ago
    Yeoman felt a little too much like a vehicle for one class of developers to foist architectural ideas on people. I'm glad it lost momentum. It would have accelerated the frontend tech churn if it took hold, not simplify or slow it down. It was also clunky to use, and created a situation where 2 or 3 people would compete to vend the canonical Yeoman config for a new frontend technology. In a way, it's been superseded by create-react-app and it's ilk, but I think those kind of tools are fine. If you're reaching for a tool like create-*-app, then you've already made a specific choice about a number of things, and it's just helping you to bootstrap the project. It going to happen again soon with WASM. But I'm welcoming that. We'll probably all end up writing full stack Ruby, or something.
phist_mcgee 5y ago
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.
- enumjorge 5y ago
  In fact I’d say part of the problem with the front end ecosystem has been people trying to get by with shallow knowledge. Building a SPA (as opposed to a web page) is a technical and challenging problem. It’s people who blow that off who, for example, adopt Redux without understanding if they need it and then complain about the complexity in their codebase.
  - phist_mcgee 5y ago
    Spot on, any tool will look blunt in the inexperienced apprentice's hands.
dgb23 5y ago
> (Like in this article - I wonder why they chose Next since they're blocking out SSR entirely) They provided a bit of rationale (kind of sprinkled across the article). For me using Next over CRA as a default comes down to three things: - Batteries included, high utility components and defaults for things you ought to stitch together otherwise. CRA is not a drop-in replacement for Next, even if you only render client side. - Flexibility. Your project might just look mostly static (fully rendered at build time) , or server rendered, or client side rendered. It rarely is. If you default to Next you can easily extend and configure these capabilities (and more). - Great DX. It's a framework that respects developers with good documentation, flexibility and a "just JS/React" kind of philosophy. There is magic that you cannot easily break through as with every framework, but so far it seems they keep the magic boundary at the right place.
- dSebastien 5y ago
  I feel like more people should look into Nrwl Nx to scaffold new projects: https://nx.dev/ https://nx.dev/ It supports Angular, React, Next.js, Gatsby, Storybook, Cypress, and a lot more. Maybe people don't hear about it, or they stop after reading the word "monorepo", while Nx is also great for stand-alone projects.
  - tvphan 5y ago
    Sounds like Vite?
ehnto 5y ago
I think that's my pet peeve with modern frontend tooling, they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. When I learned about OOP I was able to understand OOP code in a broad range of applications, languages and frameworks, but learning how react works gives me no insight into anything but react, and it's even abstracted enough from JavaScript that you could learn React without ever properly knowing how to write JavaScript (which is something I've encountered in a handful of new devs).
- pc86 5y ago
  > they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. This is sort of an expected side effect of recreating nearly-identical JS frameworks every couple months, no?
  - mdtusz 5y ago
    I continue to see this idea posted in HN and Reddit programming threads and it comes across as ignorance more than anything. The reality is that nearly all new modern web applications will be written using react or vue, with a long tail choosing a more esoteric or experimental tool because it either fits the project requirements, or the team is willing to accept more risk in favour of some other benefit (often times just curiosity). Considering you have so few language options for frontend webapp development (excluding wasm and other such options), this really isn't a surprise to have a handful of options either. I can name more python server frameworks that are used in earnest than I can name frontend frameworks. Part of the difference for frontend frameworks is that there's so much variety possible. Nearly every server framework has the same general design and API - some kind of routing, route handler definitions, and some additional niceties like with, db connection handling, sessions etc. I can't conceive of any other design that would work better or even be sensible. While components have become the norm in front-end, there's still plenty of room for different architecture and actual API to use and define components, and manage state. That's where the fun of writing them comes in, and where there is still likely a better react or vue lurking in the shadows or yet to be created.
chakkepolja 5y ago
As someone without this new web tech background, I have same experience about react. create-react-app has so many dependencies and takes a lot of time to scaffold a hello world. Adding some router or some popular library produces deprecation warnings and '2 moderate vulnerability' messages. Folder size will blow up over 1 GB to make trivial apps. That's insane.
- wlesieutre 5y ago
  And don't even think about using "npm audit fix --force", it wants to downgrade the react-scripts dependency from 4.0 to 1.1 and introduce another 50 vulnerabilities. Not the smoothest first impression for what's supposed to be the "on rails" introduction to react development.
  - chakkepolja 5y ago
    I found svelte ecosystem to be much lighter than react, svelte also being much smoother to write, but sadly it's still new and doesn't have the same amount of libraries that react has.
- nicoburns 5y ago
  create-react-app is incredibly bloated. My current day job inherited a CRA app, and I've spent silly amount of time getting rid of the rubbish in there. But you don't need most of it. For a simple production-ready React setup try the following libraries: - react (obviously) - redux, and react-redux (which ties react and redux together), and redux-thunk (enables asynchronous redux actions). - react-router and react-router-dom (adapts react-router for web rather than react-native) That's 6 libraries, but it's really only 3 as the auxiliary ones under redux and react-router are tiny. If you need to support older browsers then you might also need core-js to polyfill the newer apis, but that's it. And if you use esbuild to build then you won't need need all the complexity that webpack brings.
  - acemarke 5y ago
    Hi, I'm a Redux maintainer. Note that you _should_ be using our official Redux Toolkit package to write all your Redux logic [0]. RTK is now the standard approach for writing Redux logic. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once. RTK already includes common Redux-related packages like `redux-thunk` and `reselect` as well. We've updated the Redux core docs tutorials to teach RTK as the default [1] [2], and have examples of migrating existing Redux logic to use RTK [3]. As for the CRA aspect: I still don't really understand why some people refer to CRA as "bloated". It has all the standard pieces that have been used in the React ecosystem for years: Webpack for bundling, Babel for transpilation, Jest for testing, and ESLint for linting, and all with a very reasonable default configuration that has had thousands of hours of effort to deal with edge cases. I'm not saying that CRA is _perfect_. The maintenance has been spotty lately, it's taken a very long time for the Webpack 5 branch to get close to release, and I'd love to see CRA adopt tools like SWC or CRA to speed up builds. But given the problems in the ecosystem before CRA, it's done exactly what it was supposed to: provided a single command to set up a new React app with good build defaults. [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://redux.js.org/tutorials/quick-start https://redux.js.org/tutorials/quick-start [2] https://redux.js.org/tutorials/essentials/part-2-app-structure https://redux.js.org/tutorials/essentials/part-2-app-structu... [3] https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
recursivedoubts 5y ago
There is a resurgence of interest in HTML (really, hypermedia) oriented front end libraries like Turbo, htmx (mine) and unpoly. The a majority of web apps being built today could be created at a fraction of the complexity by using these libraries, and they put full stack development back on the table.
jrochkind1 5y ago
Same spot as you. If you find any front-end "standard" that doesn't seem "way too complicated for things I would consider a JS-heavy SPA for", let us know! I think maybe it's just... unavoidably complicated. At least any present options are, which probably means it's hard to make one that's not or someone would have done it, right?
yakshaving_jgt 5y ago
Elm's architecture is practical, and I haven't found the ecosystem lacking after having shipped tens of thousands of lines of it over the past five years. I've shipped a bunch of big React applications also, but Elm is the one I would choose every time.
jspash 5y ago
Hold out for just a bit longer as I have. The pendulum is definitely swinging back the other way with regards to front-end development. Rails has some interesting things in the works with StimuluxReflex. Basically a SSR SPA. It's a bit like the original promise of progressive enhancement before javascript ate the world. ie. everything is server-side, then "enlivened" after with JS. So if/when JS fails, you still have a working website. Personally I prefer LiveView from the Phoenix(Elixir) framework. But my day job still uses Rails. There are similar projects in Django and PHP (Laravel, I think)

yarinr 5y ago

I 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!

sgdesign 5y ago

I 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.

blunte 5y ago
> 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.
- qw 5y ago
  One of the benefits of Wordpress is that it runs on PHP. It's very easy to find a cheap web host and just copy the files over. Many web hosts even have a simple button that sets it up for you. A viable alternative would need to be just as simple, and currently that implies it should probably be implemented in PHP, which will exclude developers who want experience with "blog-friendly" languages.
  - blunte 5y ago
    PHP, _like Javascript_, can be great when used with some extra care. I have no beef with PHP (although omg do they waste space with curly braces on their own lines and vast amounts of indentation!) A good foundation can be in any language, such as PHP. But it needs to have a modern, better architecture with a more consistent base library/API for the plugin writers to take advantage of. WP is like 1.0 of this. We've learned so much in the last 10-15 years; it would be nice to have a completely rethought foundation. But for the plugins, I think there should be a standard interface layer (based on probably http, tcp, pipes, files, even memory stores for communication). Then plugins could be written in any language, hosted locally or remotely, and sandboxed.

sdevonoes 5y ago

I 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).

r6203 5y ago
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.
- spinningslate 5y ago
  +1 for Phoenix LiveViews. The Nitrogen Framework for Erlang [0] is another in a similar vein (and pre-dates LiveViews). Another is lamdera [1] which I came across on the Elm Radio podcast [2]. I've never used it, but the focus on minimising accidental complexity between front and back end was appealing, (along with the use of Elm). [0] https://nitrogenproject.com/ https://nitrogenproject.com/ [1] https://lamdera.com https://lamdera.com [2] https://elm-radio.com/episode/lamdera/ https://elm-radio.com/episode/lamdera/
- jstummbillig 5y ago
  LiveView is, unfortunately, somewhat of a footgun. The idea is super neat and works great on localhost -- but then somebody clicks a dropdown with a dynamically rendered list of whatever in production and has to wait half a second for a piece of UI to appear, and that's really bad.
jstummbillig 5y ago

madis 5y ago

Finally! You've done it! All the other front end architectures Are meant to be non-practical. Say what's special your solution in the title. Avoid using empty words. Less nose, more signal

jaredgorski 5y ago
Right?! Yeah, the title should be “A few patterns we implemented lately”. I do have more thoughts specific to practical frontend architecture though, so I guess I’ll just hope you see the next post.

eric_b 5y ago

In my experience PJAX/turbolinks + server rendering will get you 80-100% of the way depending on use case. The remaining pieces can be filled in with careful and disciplined use of something like React/Preact or Stimulus.

midrus 5y ago
Love Unpoly for this https://unpoly.com/ https://unpoly.com/

ilkkal 5y ago

Got a big chuckle out of them describing server-side rendering as this new-fangled unproven technical risk of a technology :) I get the context, but it was still funny. Ah, back to editing index.php I guess.

newshorts 5y ago
Me too. This regularly reminds me that some folks don’t have full stack experience and are coming from a completely different background. I am subsequently much more deliberate in describing architecture these days to front end devs.
lampe3 5y ago
Because your index.php did not need to dehydrate and hydrate. Back in the days the apps were unresponsive, clumsy and user unfriendly. You really can't compare web apps with old websites or even forum software like phpbb. EDIT: The down vote of the PHP developer which still wants to write phpBB forum websites :) Good luck with that. I'm waiting for the article that complains about frontend development ;)
jaredgorski 5y ago
I’m with you :) It’s certainly nothing new, but the “buzz factor” impresses people who don’t know what it’s for and they implement it everywhere thinking it’s an improvement. The trend/gimmick culture in frontend is a real thing.
yuchi 5y ago
Sorry to be the “actually…” guy here, but actually… what the article describes is ISOMORPHIC server side rendering, which is very different from traditional SSR + client side dynamic behaviors. The fact that the same code can render the initial static page AND the dynamic client interactive UI is the point here.

danr4 5y ago

maybe a bit off topic but i'm still on the fence if front end will ever be "solved". The difference is that backend is always going to be some variation of CRUD, so the architecture isn't changing too much. front end being the actual user-facing layer means it will always evolve with human-computer interface (UX?). Mobile phones completely changed the way we thought about frontend, and it's just time until the next big change in form factor comes... and a bunch of new frameworks will pop up

enumjorge 5y ago
I’d say backend architecture is also changing. React is older than Kubernetes. I do get your point though that UI dev probably sees more variation since you need to adapt to the form factor of the user’s device, which changes significantly every few years.
aantix 5y ago
https://hotwired.dev/ https://hotwired.dev/

keb_ 5y ago

Hey all, as someone ignorant to this whole SSR/Next.js stuff: I understand that Next.js is particularly popular for creating landing pages that require strong SEO. What I don't understand is, in what way is it better than say, using something like HUGO or Jekyll? If you require some dynamic content, wouldn't it be easier (and faster to build) to use a SSG and ship the JS along with all the other static assets? What am I missing here? Thanks.

vagrantJin 5y ago
Trust your instincts. That gur feeling like you are missing something important is nothing more than psuedo FOMO. Its complicated and contrived for no good reason at all. SSG are good. Plain HTML is even better.
- woutr_be 5y ago
  > SSG are good. Plain HTML is even better. I would always advocate for plain HTML, or some basic templating engine. But such a statement highly depends on your needs. Plain HTML is great when you know exactly what you're building. As soon as you're going for something a bit more dynamic, or when certain elements require conditions, you quickly move to either SSG or some for of SSR. Not saying you have to use whatever latest technology people are advocating, but use whatever makes sense to use. Plain HTML has its limitations, that could be solved with SSG or SSR.
iaml 5y ago
Both hugo and jekyll use some kind of templating engine, and as far as templating engines go, react is better in a lot of cases. Especially when you can leverage its ecosystem of libraries, or the components for react you already have.

gambler 5y ago

When an article starts by listing a bunch of tools using phrases like "easy", "simple" and "commonly used" as explanations why the tools were chosen, it's not an article about architecture.

cjonas 5y ago

This article is great timing. I'm working on a "next gen" FE app and it validates most my decisions. Only real difference in my stack is I'm using redux toolkit query to connect with a Rest API instead of GraphQL (GQL would be nice, but can't have it all). I'm a HUGE fan of antd! I've been working with it since like 2017 and it blows my mind what I can build in a few hours. I haven't used tailwind, but wanting to look into it. Anyone have practical advise for using tailwind alongside a component library like antd?

jaredgorski 5y ago
Using Tailwind alongside anything is pretty simple. It just generates stylesheets for you based on what you use. All you need to do is set up the build (so that it knows which style rules to include and which to purge) and then start using Tailwind classes in your markup. As for “best practices”, I’d say there’s not many problems you’ll run into using something like Tailwind. Any configuration improvements you make probably won’t break anything, but you should still read the docs before you get started.

BigJono 5y ago

> Therefore, we've elected to render our application completely on the client. On Next.js this means that we wrap our React app in a "client-side only" component that looks like this: > <pointless confusing newb-unfriendly code that invokes one of the most esoteric parts of the React API> > This component only allows our React code to render inside the browser environment, minimizing Next.js' server-side render runtime. Yep, sounds like a practical way to do what is literally the default. So does the 4 paragraphs of clusterfuck about integration between Next and Apollo. How many brain cells did your team kill figuring that one out just to decide on client side rendering? I've been using React and webpack for 6 years now, and interfacing with Rest APIs dependency-free using the standard library for at least as long as fetch has been around. All the commenters here are musing about how back end is so solved and front-end is a mess then lauding OP for posting about his "practical" stack at the same time? This stuff is literally the entire reason front end sucks. Front end has been solved for ages with a couple of simple dependencies and all anyone wants to do is write blogs about over overengineered and/or VC funded fadtech because they're terrified of having to write a few lines of simple code. It's not normal to just randomly spend a year "upgrading" to stuff that's barely been popular longer than that. I've been on projects that do just that, then on the next project we'll build a much bigger app from scratch in 3 months with 1/3rd of the team size.

duncan-donuts 5y ago
I was excited about this post, saw the stack, and noped out of there. I was hoping for a really simple approach but this ain’t it.
- jaredgorski 5y ago
  I’m hoping to write a more general post soon about selecting tooling per-use-case, which certainly should not result in this overpowered and complex stack in most cases.
yashap 5y ago
Agreed. Having worked extensively with GraphQL, I’ve come to see it as a MASSIVE source of unnecessary complexity in almost all cases. Haven’t worked with Next.js, but using an SSR framework, then not using SSR, seems like a tonne of unnecessary complexity too. They even say: > At Liferay Cloud, our project lives behind authentication and our clients are enterprise-level, with relatively modern browsers and powerful networks. So, SEO and client-side limitations are not concerns for us. Therefore, we've elected to render our application completely on the client. So, why are you using an SSR framework then? The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack.

newshorts 5y ago

Been interviewing for a few roles lately and finding the new “react dev” eerily similar to those relying on jQuery back in the day. I ask vanilla js and low level layout/styling questions in my interviews (not gotcha questions, but instead what I consider to be fundamental skills indicative of experience) and am consistently met with confusion. Maybe I’m too old for this game and front end devs will never again need to know about addEventListener?

rimliu 5y ago
Just wait till HTML is rediscovered. "Hey, look, my content page is 2KB instead of 8MB"
- lampe3 5y ago
  Senior Frontend Dev: HTML was never gone :) I have and still working on big e-commerce websites. For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved. What I see is the problem that people think that "Frontend development is easier than backend development". For me, they have different challenges and different ways of thinking. Getting a good full stack developer is kind of getting a good doctor, which has at least to specialities.
  - woutr_be 5y ago
    > What I see is the problem that people think that "Frontend development is easier than backend development". I hate that statement so much. Even had some serious arguments with "back-end developers" who were constantly mocking HTML/CSS/JS. Turned out that when pushed to do it, they just couldn't do anything and had to ask for help. Writing proper reusable HTML/JS isn't easy, it also requires thinking on how to structure and split up things. Especially when you throw some CSS into it.
    - midrus 5y ago
      I've been a backend developer for many years, and for the last 6 years I've been doing frontend. I can assure you those developers mocking frontend devs can't even do backend if taken outside their big ass framework (django, rails, symfony,etc etc), because they believe everyhing is as easy as those frameworks put it to them. Somebody that had to work outside of that where you have to take many decisions and make tons of trade offs and find how to organize code and manage dependencies, etc will understand better how difficult frontend is. True we sometimes overcomplicate things more than needed (redux, rxjs, etc...) but even when we do not, this is still freakin difficult to get right.

nprz 5y ago

I haven't spent much time with Next.js, but luckily React will soon natively support[0] SSR. Wonder if Next.js will still be around once React Server Components are fully released. [0]https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react...

codybontecou 5y ago
Will they also be supporting static site generation?
andrewingram 5y ago
In short, the answer is likely yes. React's server component stuff is about providing primitives to make it possible to address some of the downsides of the current approach to building apps/sites that follow the SSR-with-SPA-handover (hybrid rendering) model. There'll still be a need for more holistic frameworks that sit in front of React. SSR itself has been possible with React since 2014 (allowing for a few memory leaks), Next.js just eliminates a lot of the grunt work. The React team is working with the Next.js team (amongst others) to make sure there's alignment.

deleted 5y ago

[deleted]

ianpurton 5y ago

> Likewise, don't choose server-side rendering just because it's buzzy and sounds powerful. Server-side rendering does basically the same job as client-side rendering: generating HTML. Well not quite. With client side rendering you now have manage state in the browser as well as build API end points for each screen you want to create. It's a more complicated architecture.

axhl 5y ago

What a nice post. Thanks jaredgorski for sharing. OP, if you're reading this, could you expand on the rationale for going with Apollo over e.g. Relay?

jaredgorski 5y ago
Thanks for the positive vibes. Great question. In fact, that question has more to do with “architecture” than most of my post. The primary reason we went with Apollo is that it’s flexibility-minded and well-documented, making it easier for new engineers to work with. If everything was ideal, we’d use Relay. Relay’s patterns are better (IMO) but it can be confusing for new folks to use it idiomatically. So, it’s primarily a dev-experience consideration for us.

lampe3 5y ago

Sounds a little bit to more like: We are using every new technology because why not, but we don't think about our use cases. Things like "/items/12345/detail" let me believe that this is not a spa really? More like a good old MPA? I'm not sure if the chosen technologies are the right ones for the jobs. In general, I don't understand the trend to default to something like reactjs. We have and had alternatives. What I see is that people complain about technologies which are not build for what they are using. To get good performance and bundle size out of SPA like apps, you really need to put in work. Maybe a simple Laravel/RubyOnRails website would have been the better stack for a lot of projects which are right now written in reactjs/nextjs.

bern4444 5y ago

There's a lot in here that seems off if not quite wrong. Throwing errors to be caught higher up, the way they manage redirects, and the lack of discussion around managing state (which could on its own solve lots of these problems). So much of this seems convoluted and unnecessary for a very simple goal of building a dashboard. Their use of Apollo seems to provide no advantage over a basic REST API. There's frankly very little discussion about actual front end architecture. I'd expect a conversation on a React application architecture to focus on things like how is client side state managed? How is server state managed and kept up to date? Are the two mingled together or kept separate? How are they kept separate? How can you build reusable components? How can you avoid components bloating in size and scope etc Front End development today - especially with React - is so easy to get running with and there are tons of better articles that actually discuss front end architecture including lots of courses on common patterns. Beyond articles, open source projects themselves often provide great architecture discussions. Higher order components, react-query for server state, react-router for client side routing, building reusable behaviors with hooks are all good places to get started for actual architectural design

jaredgorski 5y ago
Great feedback. I’ve been wanting to write more about most everything you mentioned, but ended up writing about a few interesting patterns we implemented recently. I probably should’ve titled the post “A few interesting patterns we implemented recently”. As for state management solving the problems of pageload validation (instead of our error boundary and redirect mechanisms), can you provide an example?
- bern4444 5y ago
  Totally, I think if this article were titled patterns it'd be more accurate. Architecture has a more specific meaning (at least to me). As for using state, when you use something like react-router, all those things, path parameters, query parameters etc are stored in state. You can build hooks that use the hooks provided by react-router to retrieve those values in a useEffect in the relevant components. The hooks you build can be responsible for validating the path/query params, coordinating route changes etc. The larger idea is to use your state as a means of coordinating messages that any component can hook into. So you could include in each of those detail pages a redirect route component that only fires when the hook you wrote detects that a page is invalid. To take this to another level. You could build a Higher Order Component that automatically embeds this ability (a redirect component with a custom hook) into your item detail pages so that it's automatic.

andrewingram 5y ago

Not planning on getting dragged into a debate about whether GraphQL is a good tech choice here (even though I won't pretend i'm not a massive fanboy). But the "with-apollo" Next.js example used as a reference (and then decried as being a bad experience and unscalable), is a pretty bad representation of how it can feel to use GraphQL with Next.js. I've never used Apollo in anger, but i've used Relay with Next.js for a few projects and it's been a dream. The biggest downside has been the size overhead of the Relay client itself (approx 40kb over the network), and the size of the serialized data (but that's the same price you'd be paying whether you were using GraphQL or not, just an unfortunate reality of the hydration model).

jaredgorski 5y ago
I’d love to hear more about your experience with that “with-apollo” pattern. I decried it without using it first, but I see the problem as a coupling/cohesion imbalance. What has it looked like in practice for you?
- andrewingram 5y ago
  I've mostly used the Relay examples as a starting point, though they've generally need to be fixed up to avoid some bugs. In the olden days of getInitialProps (still available as an API, but its use isn't actively encouraged) things were easier and more elegant, getServerSideProps and getStaticProps both force things to be a little uglier. For my older (getInitialProps) approach, you can see a rough example here: https://gist.github.com/AndrewIngram/e974f63160af9df292fc39eeeab62e61 https://gist.github.com/AndrewIngram/e974f63160af9df292fc39e... Look at the last file (PostDetail.jsx) to see what it's like using GraphQL as part of a page (PostLayout isn't defined here, but assume it's just a regular React component using Relay's useFragment hook).

bacro 5y ago

The useValidation hook needs to add data to the dependency list of its useEffect or else it will run on each render unnecessarily.

jaredgorski 5y ago
Ha! Yes. It’s pseudo code though. Please don’t copy and paste it.

drewpc 5y ago

Not the OP nor the post's author. We have a similar stack (React + NextJS + TypeScript + Mobx) but use a traditional REST API using Django Rest Framework. There are some interesting topics in the post and in these comments that I figured I could expand on: 1. The primary reason we chose NextJS (with SSR) was to be able to write a declarative React component that is run on the server and the client. For example a button to follow or unfollow a page (think: like/unlike in social media). In the previous generation of our application, we wrote the button in PHP that rendered HTML and toggled UI state on the front end using JS/jQuery. That meant writing the button logic (and HTML/CSS) in two places instead of one. Now, we have a single React component that renders itself based on state; it's the same component on the server and client. 2. I don't understand the extra work to avoid SSR. SSR is great and can be used behind authentication--there's no actual need to work around it. Additionally, in a NextJS application, SSR is only used on the first page load. When you click from page to page, it's all client-side transitions. 3. @yashap said "The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack." Agreed. Same here. It's wonderful. In particular Mobx. A lot of the comments seem to say "I expected the article to talk about how to maintain state in a React application"--that's how. Use Mobx. No matter what reactive JS framework you're using, use Mobx to maintain "global" state. 4. The discussion of "why move to NextJS when my Webpack config from 6 years ago works just fine" is a good one. Two big reasons we moved to NextJS (away from a Webpack config from 7 years ago) were: the handoff from server -> client is more seamless and the developer experience with hot module reload for server + client sides was worth it. Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense.

nicoburns 5y ago
> Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense. Doesn't NextJS do the same? The alternative to compare to would be a plain setup without any heavyweight boilerplate. These days you could you esbuild, but a webpack config can be ~50 lines and quite simple if you build it up from scratch.

rawoke083600 5y ago

All good comments here... I think the reason we have so many fe/js/options is that no one option has jump out as 'x10 better' than the rest. Svelte for me at least gets close to 'it' - ymmv Sidenote(sorry for highjack): The ninja hackers/coders out there please code this next: Like you know how we have tree shaking for dead js/ts code ?(Really cool and impressive btw) I want to get "html tree shaking" - Im putting it in quotes since what Im after is: The least amount and/or optimized html that will generate the same 'view/end-result' of my current unoptimzed html. Maybe a case for optimal-auto-encoder ?

rawoke083600 5y ago

lol it would be funny if in a few years... Google(crawler) becomes good enough to read all text from images(they are probably there already and beyond) And instead of rendering html or static site generators...we just export everything as one or a few(for responsive) jpeg :) ?

cannabis_sam 5y ago

Practical for front-end devs, not so much for us users who have to live with laughably shitty js-reimplementations of decades old built-in browser functionality… Heaven forbid you’re on a shitty internet connection, these inane js-behemoths just die from a dropped tcp connection, since they’re built on the most optimistic assumptions about network connectivity. I remember when accessibility was a part of web development, but I guess the ROI was to low.

jaredgorski 5y ago
I did mention that our clients are enterprise-level. But I did fail to address a more general decision-making process regarding choosing frontend architecture. If I did (and I probably will soon), I would talk a lot about the egregious initial load times on too many blogs that roll crazy dynamic tools for what should be a completely static site.
- cannabis_sam 5y ago
  Yeah, I’m sorry. Looking back at it, that comment was written in general exasperation with the current state of the web, not really at you in particular.
  - jaredgorski 5y ago
    Your exasperation is absolutely shared. Thanks for engaging
    - cannabis_sam 5y ago
      Thanks!

turtlebits 5y ago

Personally, I wish front-end frameworks were literally that, a set of files you can toss in a directory and serve (with nginx, apache, or any static host like netlify), with your backend as a separate deployable bundle. SSR, progressive enhancement and all these tricks to speed up load time aren't really necessary if you just keep complexity down and your bundle size small.

marsven_422 5y ago

Remember kids, the purpose of architecture is to minimize the cost of development, deployment and maintenance.

techpression 5y ago

If I understand this post correct they seem to like the idea of putting routes in the file system (Next uses magical file names as a way to generalize routes for those who haven’t used it). To me this makes absolutely no sense, a route doesn’t map to the file system in anything more than the most trivial index.html cases and you lose the ability to do things like “resource routes” to avoid mindless declaration of routes. On top of that, I would assume Next creates a route definition in memory anyways and doesn’t read from disk every request so it’s just pollution of the file system with the additional downside of making navigation unnecessarily hard.