Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Practical Front-End Architecture

jaredgorski.org

Post reply on HN
Print view View original

101–110 of 164 posts

Re: Practical Front-End Architecture

#101

Post by jaredgorski »

billoshoes wrote: post #98
brundolf wrote: post #92

Earlier quoted context omitted.

We use Apollo at my new company and I have mixed feelings on GQL so far, but I asked HN about it and lots of people had positive anecdotes: https://news.ycombinator.com/item?id=28488259

Do you have any examples of JWT refresh token auth for Apollo? I'm having an absolute nightmare figuring it out

Specifically, are you referring to JWT with Apollo client on the server-side?

On the client-side, you can just use a link and get the cookie into an auth header that way. On the server-side, you need some way of getting that auth token from the cookie and passing it into the server-side runtime so that you can insert it into the auth header via a link in each server-side Apollo client instance.

Re: Practical Front-End Architecture

#102

Post by iaml »

Weebs wrote: post #76
ehnto wrote: post #24

Earlier quoted context omitted.

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 abstract…

I think if we're talking about concepts at the level of OOP, we'd be comparing MVU and virtual DOMs rather than React. I learned to write UIs in F# through Elmish (used by Bolero), which was inspired by (unsurprisingly) Elm. React, also being inspired by Elm, was simple enough to transition to once I was comfortable in Bolero. It was basically MVU with components that have local state and lifetime function callbacks.…

> React, also being inspired by Elm

This is news to me, are you sure about that? Wasn't react released earlier than elm?

Re: Practical Front-End Architecture

#103

Post by faizshah »

newshorts wrote: post #40

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…

What are you trying to measure by asking a low level question about say addEventListener? The people who give the best answer will be the people who most recently used that low level api and are good at sharing their knowledge about it. A better way to measure that would be to ask them to tell a story about something then if they mention say debugging an Event Listener then such a question is fair game to understand how they deep dive a topic.

An FEEs job is 90% combine components from the design system with apis from the backend team to implement a UX from the design team (and obviously debugging, deploying, etc.). For this I only care that you know what an Event Listener is or what Flexbox is or what the Box model is I don’t really care whether you know some of the low level details off hand (unless you reference it in a story).

Re: Practical Front-End Architecture

#104

Post by jaredgorski »

axhl wrote: post #47

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?

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.

Re: Practical Front-End Architecture

#106

Post by jaredgorski »

cjonas wrote: post #36

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 loo…

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.

Re: Practical Front-End Architecture

#107

Post by jaredgorski »

madis wrote: post #19

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

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.

Re: Practical Front-End Architecture

#108

Post by matthewhammond »

sdevonoes wrote: post #5

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 com…

Well, you only need to use Node now if you want a single language (+ optionally Next, which runs on node/express and will make your UI development much smoother if it's anything beyond super basic).

Re: Practical Front-End Architecture

#109

Post by iaml »

toastercat wrote: post #33

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 a…

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.

Re: Practical Front-End Architecture

#110

Post by chakkepolja »

wlesieutre wrote: post #54
chakkepolja wrote: post #25

Earlier quoted context omitted.

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.

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.

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.
Post reply on HN