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

Ask HN: What's is your go to toolset for simple front end development?

news.ycombinator.com

Post reply on HN
Print view View original

221–230 of 295 posts

Re: Ask HN: What's is your go to toolset for simple front end development?

#221

Post by 015a »

May be unpopular, but: nextjs + react (+ bringing in typescript later if it starts feeling like types would be valuable).

1) React/jsx is legitimately nice for templating. Lets say I have a list of ten things I need to display; I know these things at build-time, its not dynamic like from an API or whatever. These ten things are reasonably complex; div+spans+borders+etc. React is all about components; it makes that easy, write once and copy-paste one line. There are ways to get similar behavior in plain HTML+CSS, but it tends to be leveraging web technologies that I'm not super familiar with (web components?).

2) React has an EXTREMELY good developer community. Everything you could possibly want, there's a component out there, and its an npm i away. In comparison, the more pure HTML/CSS world is more fragmented and less developed.

3) `next export`. When people think nextjs, they think SSR. Don't bother with it. Just `next export`. I leverage next for the local dev tooling, the runtime can take care of itself.

4) Or; I want server-side functionality. You can build backend-only API routes, in Next, and its actually awesome. Of course, you have to give up the static export, but its the first full stack JS "framework" where I've started thinking, this actually works & feels productive. Usually I leverage that for really simple stuff; server-side OAuth logins for hacky dashboards, things like that.

For deployment: netlify is nice, or I'll use digitalocean apps if its not a static export.

Re: Ask HN: What's is your go to toolset for simple front end development?

#223

Post by maskros »

lawl wrote: post #159
gherkinnn wrote: post #26

Earlier quoted context omitted.

It would only take a tiny amount CSS to make it usable. The examples by vonadz are minimal to the point of being a chore to use.

https://motherfuckingwebsite.com/ Vs http://bettermotherfuckingwebsite.com/

Ugh, way to overdo it... #444 is WAY too low contrast.

If black is too dark, I'll reduce the contrast of my monitor myself, so can y'all please stop trying to force me to squint to decipher your gray-on-gray oh-so-beautiful but unreadable text?

Re: Ask HN: What's is your go to toolset for simple front end development?

#224

Post by chatmasta »

toastercat wrote: post #143
egeozcan wrote: post #130

Earlier quoted context omitted.

I've been using htmx since the intercooler days, but I'm of the opinion that just using Next.js and treating React like simple HTML is much easier for starters. Or Alpine, but not htmx. Learning all those attributes (30, not counting the HTML headers and the JS API and the CSS classes, and events like htmx:historyCacheMissError) is not as simple as some in HN make it out to be. Just look at the most basic example in…

Unfortunately, "easier" does not always equal "simpler". Next.js/CRA is "easier" because it hides a lot of the complexity away from you. In my opinion, ignoring how it all works under the hood and just blindly accepting tools/clis because "it works" sets you up for confusion down the road. I've met several JS developers who don't know that JSX gets transformed to JavaScript function calls after a build step -- they j…

This is a valid criticism of SSR and the complex mental model it requires to implement effectively, even with Next.js. You need a firm understanding of the HTTP request lifecycle and the serialization boundary. For a novice programmer starting with frontend dev, I would not recommend starting with Next for this reason (create-react-app would be better).

But for an experienced backend developer, the mental model of Next is no problem, and the flexibility of SSR will feel liberating. After a few weeks you might even put down the Flask!

If you want to use SSR on your pages, I'd recommend sampling some Next projects (just pick one of the examples and get it running locally). You might like what you find. And for closer integration with Python, I'm sure there are options for server-side rendering of JSX that you could use, although they'll all ultimately need to either wrap a JS runtime or emulate JSX compilation in Python. So you may as well just skip the middleman and go to straight to react, whether via a framework or otherwise.

If you don't want a heavy framework, or you just want basic CSR for some richer pages, you can accomplish a lot with just `react` and `esbuild`. Even SSR is just a matter of calling `ReactDOMServer.renderToPipeableStream()` and doesn't need a framework like Next. They're just nice because they take care of all the problems you'd end up solving in a robust deployment anyway.

Re: Ask HN: What's is your go to toolset for simple front end development?

#225

Post by larrik »

015a wrote: post #221

May be unpopular, but: nextjs + react (+ bringing in typescript later if it starts feeling like types would be valuable). 1) React/jsx is legitimately nice for templating. Lets say I have a list of ten things I need to display; I know these things at build-time, its not dynamic like from an API or whatever. These ten things are reasonably complex; div+spans+borders+etc. React is all about components; it makes that ea…

React is so far from "simple" it's not funny, then to throw nextjs in there too...

For instance, I find vuejs to be way simpler as a non-frontend dev, and that's way overkill for what I'm interpreting the OP to want.

Re: Ask HN: What's is your go to toolset for simple front end development?

#226

Post by mattbrewsbytes »

omniscient_oce wrote: post #129
bluehatbrit wrote: post #120

Earlier quoted context omitted.

I'm in the same camp, I've slowly "regressed" backwards from overcomplicated SPA's back to server side rendering. When LiveView hit and I was already using Phoenix it was just perfect. It's a slight embelishment on top of multi-page server rendered pages which gives all the benefits I need and nothing more. If I _really_ need something to be driven by the frontend like a transition then I'll use Alpine.js. For CSS I…

How do you deal with more complex/dynamic forms? As someone who learnt frontend mostly in React I've always struggled wrapping my head around how you would do that with server-side rendering. For example: 1) selecting a checkbox alters other fields in the form 2) validation that needs to hit the backend and then present warnings/errors to user 3) field arrays -> sending back a list of fields

Its actually recommended with Liveview for pure client side stuff (hiding form elements, etc.) to do that in the client. There are hooks to do such things. Granted I've only built admin-y tools that are pure liveview but did hear/read there are options for client side JS.

Just because it can be done 100% server side doesn't mean it should be, especially if its driven out of a "look, no JS!" type of approach.

Re: Ask HN: What's is your go to toolset for simple front end development?

#227

Post by maskros »

Jaruzel wrote: post #42

One single piece of CSS instantly improves the look of plain html pages: body {font-family:sans-serif;} Beyond that, all other CSS is optional imho. And you don't need JavaScript to trigger back-end events, as a simple link will work just as nicely.

No thanks, I very much prefer my serif fonts. If you prefer sans-serif for plain html pages, why don't you change the default font in your own browser instead of trying to convince everyone to force their preference onto everyone else? That way we can all have the kind of fonts we prefer...

An link can't do POST requests, and GET requests should be idempotent, so you'll need to use either Javascript or a form with a button to trigger back-end events.

Re: Ask HN: What's is your go to toolset for simple front end development?

#228

Post by y-c-o-m-b »

I've been doing this for so long that I've gained years of experience in React, Angular, and Vue. You said simple front-end development and there's nothing easier than Vue, hands down. The syntax is so easy and segregated perfectly; no JSX wild-west ugliness or fucking with a minefield of observable and subscriber pipe functions. It's easy to get started, encourages clean code, and very readable. It boggles my mind how there's so few VueJS jobs available despite the advantage. I think part of it is just developer laziness in picking up yet another library, which I totally understand. Unfortunately I'm stuck in React and Angular land 90% of the time and hate it.

Re: Ask HN: What's is your go to toolset for simple front end development?

#229

Post by theptip »

For home-lab/internal UIs, you can go a long way with the auto-generated model-admin pages from Django. If you just need CRUD and actions triggered on a list of models, you can typically avoid any UI work and just define a few Admin classes, and if you need to make custom forms it's quite easy using Django's templating machinery to override individual pages.

https://docs.djangoproject.com/en/4.0/ref/contrib/admin/

A similar modular admin system that's more generic is https://www.forestadmin.com/, I think this one has a layout editor too. But that one requires a REST API and so it may require more plumbing, depending on what you've already built. Or it could fit nicely on top of what you already have, if you already have APIs for everything.

Re: Ask HN: What's is your go to toolset for simple front end development?

#230

Post by iso1631 »

dusted wrote: post #4

I just read that you didn't want to troubleshoot html, css and js, so my goto toolkit for simple UIs might not fit your bill, but hear me out :) At work, when I do internal tools, they are usually well received. They also pass just below the threshold of having their looks be judged. They're not ugly, because they're almost not there. Very plain HTML: HEAD+TITLE, H1, H2, UL, OL, A, IMG, INPUT, BR, TABLE, P Javascript…

Bang on. We have internal tools like that and they just work - something which dumps a list of switches and information for example, trivial to find what's plugged in etc. The interface doesn't get in the way. Dynamic pages are a matter of "print" stuck in the middle of the php.

We also have internal tools based on gigabytes of react across millions of files, we have data fields in there you can't actually highlight and copy the label from that require 3 days efforts to add a tiny feature. But it probably looks nice.

Post reply on HN