jaredgorski

8 ms·

1.
by jaredgorski 4y ago
I was being tongue-in-cheek. Didn't mean to sound like a smartass. Thanks for reading!
2.
by jaredgorski 4y ago
Oddly enough, I just realized I do both
3.
by jaredgorski 4y ago
For clarity, this post was more creative writing exercise than technical treatise. Thanks for reading!
4.
by jaredgorski 4y ago
For clarity, this post was more creative writing exercise than technical treatise.
5.
Web Notes with Nonplain.js(nonplain-11ty-markdown-notes.vercel.app)
3 points by jaredgorski 4y ago|0 comments
6.
by jaredgorski 4y ago
Maybe you should write a web blog post nobody will read about it
7.
Penmanship(jaredgorski.org)
89 points by jaredgorski 4y ago|116 comments
8.
A more intuitive GraphQL server design(jaredgorski.org)
1 points by jaredgorski 4y ago|0 comments
9.
Practical Front-End Philosophy(jaredgorski.org)
2 points by jaredgorski 5y ago|0 comments
10.
by jaredgorski 5y ago
Your exasperation is absolutely shared. Thanks for engaging
11.
by 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 init
12.
by 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.
13.
by 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
14.
by jaredgorski 5y ago
Ha! Yes. It’s pseudo code though. Please don’t copy and paste it.
15.
by 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
16.
by jaredgorski 5y ago
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
17.
by jaredgorski 5y ago
I see what you mean. By way of clarification, I see route validation and pageload validation as potentially separate. For example, a given route parameter may govern a whole scope of pages in the app, so it makes sense to centralize that ro
18.
by jaredgorski 5y ago
Totally. With Next, your page component can export a getServerSideProps function which is used by the Next server to fetch any props necessary for the page component server-side on-demand. There’s a variation of this function for static bui
19.
by 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?
20.
by 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.
21.
by jaredgorski 5y ago
“Hey look, the browser loads each new page one at a time instead of loading them all in the initial load.”
22.
by jaredgorski 5y ago
Good! We need to get back to the basics and stop shoehorning React into every application. I regret that my post is yet another React promotion. Not intended: architecture depends on use-case. I’m hoping to write more soon about selecting t
23.
by 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 implemen
24.
by jaredgorski 5y ago
> So, why are you using an SSR framework then? Great question; I should’ve mentioned this more concretely in the post. I would’ve nuked Next completely, but we like the filesystem-based server and the ability to add imperative server-sid
25.
by jaredgorski 5y ago
I think both can be true. There are practical reasons to use React and Vue, but that practical approach is obfuscated by the zeitgeisty culture around tools that get unwisely applied to every use-case. Frontend architecture needs to be appr
26.
by jaredgorski 5y ago
Absolutely. The trends and gimmicks have caused this “walled garden” effect. It’s made both “practical frontend engineers” and “practical frontend architecture” a rarity. If I could write this post again, I’d talk more about how most use-ca
27.
by 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.
28.
by jaredgorski 5y ago
I probably should’ve clarified that this stack is geared toward our enterprise-facing cloud dashboard. There’s a lot of data flying around and it needs to be displayed real-time. But most websites really don’t need this stuff. Front end nee
29.
Practical Front-End Architecture(jaredgorski.org)
176 points by jaredgorski 5y ago|160 comments
30.
A Vim Puff Piece(jaredgorski.org)
2 points by jaredgorski 6y ago|0 comments

More ›