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

151–160 of 164 posts

Re: Practical Front-End Architecture

#151

Post by iaml »

insonifi wrote: post #127
Weebs wrote: post #119

Earlier quoted context omitted.

I believe you're right, I meant to say React's Hooks, but now I can't find a reference to that so maybe I misremembered. I wasn't interested in previous versions of React after going over the basics in the docs a few times, but after the introduction of hooks I found it more appealing.

I think you actually meant Redux, which as an implementation of the Flux architecture was inspired by Elm, as per the author [1]. [1] https://egghead.io/podcasts/dan-abramov-co-author-of-redux

This is neat, didn't know about elm's influence on redux.

Re: Practical Front-End Architecture

#152

Post by cannabis_sam »

jaredgorski wrote: post #143
cannabis_sam wrote: post #120

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

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.

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.

Re: Practical Front-End Architecture

#153

Post by spiralx »

jaredgorski wrote: post #73
bern4444 wrote: post #57

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

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?

This article is a nice overview of different kinds of state and how to manage them, the code is Angular but the concepts apply to any SPA.

https://blog.nrwl.io/managing-state-in-angular-applications-...

Re: Practical Front-End Architecture

#154

Post by spiralx »

Scarbutt wrote: post #97
lampe3 wrote: post #58

Earlier quoted context omitted.

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

For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved. Can you elaborate how? like some turbolinks thing?

The back-end can render that content when requested, adding very little overhead to an AJAX request just returning the raw data, and it can pre-render and/or cache objects as well. Both Facebook and Reddit do similar when loading extra content into an existing page - they embed HTML content in the JSON response for things like profile popovers or when loading more comments. Saves the front-end from having to render a template (takes time to load the template beforehand and time to render it, maybe for many items) or build it programmatically. Directly using AJHX to get HTML is the same when there's just a chunk of HTML with no metadata.

Re: Practical Front-End Architecture

#155

Post by jaredgorski »

cannabis_sam wrote: post #152
jaredgorski wrote: post #143

Earlier quoted context omitted.

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.

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

Re: Practical Front-End Architecture

#156

Post by stickfigure »

rapind wrote: post #140
stickfigure wrote: post #133

Earlier quoted context omitted.

I think you have it exactly backwards - the days of using string templates to assemble HTML pages was a weird and specialized era. React and modern JS tooling brings us back to traditional client/server GUI application development, just like we did in the 90s. And that's a good thing. GUI development has its own set of concepts and broad applications. React is somewhat novel but still fits squarely in here; the idea…

> the days of using string templates to assemble HTML pages was a weird and specialized era. JSX?

...does not generate strings.

Re: Practical Front-End Architecture

#157

Post by rapind »

stickfigure wrote: post #156
rapind wrote: post #140

Earlier quoted context omitted.

> the days of using string templates to assemble HTML pages was a weird and specialized era. JSX?

...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 difference you're talking about is having the server render each user's UI versus offloading that to the user's machine. Regardless of whether it's via strings, 1s and 0s, https, rpc, etc. Browser's have become a more powerful "general purpose" renderer, so it makes more sense that they'll continue to take on more of the UI work themselves. It's still not as good as a purpose built client though, as sluggish electron apps have demonstrated. And sometimes it might still make sense to render the UI on the server (and cache it) for either / both simplicity and performance.

Occasionally you'll even do a bit of both with a client side app being rendered server side then hydrated... talk about a weird and specialized era.

Re: Practical Front-End Architecture

#158

Post by midrus »

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…

You already have that: JavaScript.

Otherwise, what you are describing isn't going to be "Just Go" or "Just the language"... you'll have again a ton of libraries/frameworks on top of it... the complexity is going to be there... one way or another.

Re: Practical Front-End Architecture

#159

Post by midrus »

woutr_be wrote: post #85
lampe3 wrote: post #58

Earlier quoted context omitted.

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

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

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.

Post reply on HN