Live data from Hacker News

Practical Front-End Architecture

jaredgorski.org

161–164 of 164 posts

Re: Practical Front-End Architecture

#161
post #52
post #37

> 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: > > 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 cl…

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…

Even if not using the SSR part of next, it is still a great build tool, with sane defaults and possibilities of static generation.

What would you use to "simplify" things? Your own webpack config?

Re: Practical Front-End Architecture

#162
post #121

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…

Maybe I am not the only person on the planet who still uses Vanilla JS and plain Node.js. I mean I have a lot of experience with various front end component systems on desktop on the web, including Microsoft stuff and in the browser some Angular, React and Vue. But for my current project which is a little bit involved, I decided to skip React. It is actually working out fine. I assume React devs who see it will sugge…

I've built a few small projects with just backend rendered views in Node.js, and then did all the dynamic "SPA" like features with Unpoly. Turned out a lot better than I thought. Things such as authentication being a lot easier and not having to build an API really helped speeding up things.

Re: Practical Front-End Architecture

#163
post #157

Earlier quoted context omitted.

...does not generate strings.

and it isn't javascript, so it's essentially a template language. It's just being turned into javascript, which then goes into the vdom, which then gets diffed with the real DOM, which generates code to reconcile it with the real DOM. > the days of using string templates to assemble HTML pages was a weird and specialized era. I gotta say, I think React w/ JSX is far more of a weird and specialized era. The real diffe…

While these terms are fuzzy, JSX has less in common with the template languages we used in the 2000s and more in common with interface builder languages like XUL. The experience is assembling components on a screen rather than generating HTML. Despite all the plumbing complexity, React/JSX (and Angular et al) feels fairly familiar to GUI developers from the 90s like me.

I agree with you that "client side app being rendered server side then hydrated" is pretty weird. I also don't think this is the future of the web but rather a holdover from the previous HTML-based era. It may never go away; after all, lots of content is very well suited to simple HTML.

Re: Practical Front-End Architecture

#164

Earlier quoted context omitted.

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.

Your exasperation is absolutely shared. Thanks for engaging

Thanks!
Post reply on HN