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

21–30 of 164 posts

Re: Practical Front-End Architecture

#21

Post by blunte »

qw wrote: post #12
blunte wrote: post #10

Earlier quoted context omitted.

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

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.

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.

Re: Practical Front-End Architecture

#22

Post by eric_b »

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.

Re: Practical Front-End Architecture

#23

Post by dSebastien »

dgb23 wrote: post #11
d3nj4l wrote: post #2

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…

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

I feel like more people should look into Nrwl Nx to scaffold new projects: 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.

Re: Practical Front-End Architecture

#24

Post by ehnto »

d3nj4l wrote: post #2

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

Re: Practical Front-End Architecture

#25

Post by chakkepolja »

d3nj4l wrote: post #2

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…

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.

Re: Practical Front-End Architecture

#26

Post by tvphan »

dSebastien wrote: post #23
dgb23 wrote: post #11

Earlier quoted context omitted.

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

I feel like more people should look into Nrwl Nx to scaffold new projects: 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.

Sounds like Vite?

Re: Practical Front-End Architecture

#27

Post by recursivedoubts »

d3nj4l wrote: post #2

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…

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.

Re: Practical Front-End Architecture

#28

Post by pc86 »

ehnto wrote: post #24
d3nj4l wrote: post #2

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

> 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?

Re: Practical Front-End Architecture

#29

Post by ilkkal »

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.

Re: Practical Front-End Architecture

#30

Post by danr4 »

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

Post reply on HN