Ask HN: I can't grok front end development

> Like is it supposed to be this hard to build a UI?

Yes. It is hard to build UIs that are accessible, intuitive, and robust to a wide range of user inputs, interactions, and devices. It's a different kind of hard from backend / infra work.

I agree with what many others are saying here - to get started, you can strip away the complications of React, state management, CSS libraries and just learn basics. Tinker around in CodePen. Create a minimal HTML / CSS / JS static page and serve it with e.g. `python3 -m http.server` or `npm install -g http-server; http-server .` Read through e.g. MDN docs [1].

Find someone - maybe a coworker, maybe a friend, whoever - that knows frontend development better than you do. Pair, ask questions, get some peer mentorship. Ask them to review your frontend code - maybe at work, or maybe throw a Github repo up with a personal project and send them a link.

Find examples of good UI / UX, the kind you appreciate. Pick a small part: maybe it's a specific form field, or an animation, or a data visualisation, or even just a layout. Try to build a simple version of it yourself. Start small, start simple. Even if you don't build the beautiful version, now you might see what small details are lurking in that beautiful version.

Don't forget: you've been a (mostly) backend engineer for ~10 years. How long did it take you to really grok the beauty and challenges there? It will take time and effort. It will also pay off: you'll gain a clearer understanding of what others around you are doing, and how your work fits together with theirs.

[1] https://developer.mozilla.org/en-US/docs/Learn

No, the front-end world is just insane. I've been a frontend developer since early jQuery days. I do React every day and I hate it. Solid.js is better, it's basically React done right but there's still plenty of unneeded overhead.

My code was not messy with jQuery but the code quality heavily depended on how good developers were. I've seen plenty of bad: back then it was easy for kids writing markup to call themselves developers and charge a lot of money. Nowadays they wouldn't even be able to start a React hello world.

Back then, in the right circles, using templates for individual components was not uncommon. I remember working on some really nice application with individual context for each component and template rendering. I even had a nice router dynamically loading pages and updating the body via xhr while keeping the navigation intact and working even without JS.

Oh and there was no transpiling: no waiting for minutes to build development bundles, no complicated hot reload (damn, you just refreshed, it was so fast). Just a layer of minification going in production.

Anyway it was great back then, the only problem we had was crossbrowser compatibility.

Nowadays we just cargo cult the latest frameworks that some entitled developers from a fang used to get a promotion.

The complexity is through the roof for no reason and for no gains in productivity. If anything developers are way less productive these days.

I also wanted to jump on the HTMX bandwagon, but I found it too limiting and not providing a lot of value out of the box.

These days I use react for client work but if I have to whip out some frontend I just use plain JavaScript + mustache templates instead of components. The JS browser api is great today, you don't need anything else.

Also AI is pretty great at generating plain JS.

On CSS front: the battle for semantic CSS has been lost (a battle we lost since bootstrap). The standard is too complex, nowadays you might just use tailwind classes and treat those as what CSS was back in the day.

You can still compose them and make semantic classes out of them (even though they discourage it) and you don't need to worry about a lot of CSS bs rules, stupid defaults and exceptions.

> Given my experience with this archaic pattern, I've now started exploring HTMX with Golang. This seems more my speed.

It's actually a pretty good way to start. And not in any way "archaic". The web these days is dominated by JavaScript frameworks, but there's a growing trend towards server-side rendering and static site generation. Go has a solid templating engine that you can use to generate HTML. You can even dodge HTMX and just use plain HTML, CSS, and JavaScript.

> But, I want to build beautiful web applications, but I don't get CSS. Like is it supposed to be this hard to build a UI?

Yes, it can be pretty hard. There is a reason why we have developers who work exclusively on the frontend. It's a whole different world from backend development. It's not just about writing code, it's about design, user experience, and a lot of other things. It's a whole different skill set.

I would suggest trying Tailwind CSS. It's sort of like a "higher-level" CSS framework that makes it easier to produce nice-looking UIs without having to deal with the details of CSS. It also has some very nice design patterns built into it. Creating a beautiful UI is as much about design as it is about coding. I'm a pretty experienced frontend developer and I can't design for :hankey:. But with Tailwind, I can make things look at least decent.

> Are there books or blogs that you'd recommend I read, so I can understand the beauty and challenges of frontend dev?

Building stuff is always the best way to learn. But if you want to read something, I would suggest "Refactoring UI" (by the creators of Tailwind CSS). It's a great book that will give you some insights into how to design a good UI. It's not about coding, but it's a great resource for understanding the design aspect of frontend development.

frontendmasters.com is also a great resource. They have a lot of courses on frontend development, from beginner to advanced. But they are pricey. Watching YouTube tutorials might make more sense if you're just starting out. But again, this days they are heavily focused on JavaScript frameworks. Maybe you can try the channel Web Dev Simplified. He has some great content on frontend development that are more focused on the basics.

CSS really is the core of front end. You'll get better with experience, especially if you hew to always using every opportunity to learn something deep about it instead of just superficially how to complete the task. Eventually you'll be pretty good at it.

But in the meantime, you'll manage to get stuff out the door, that looks almost but not quite right or not quite responsive (abusing absolute positioning and other hacks, for example) and it'll just take longer than it should.

That's just the nature of it, but there's a light at the end of the tunnel. Keep messing around. You'll get there.

You'll have a much easier time with these resources:

(1) Use the browser's debugger extensively while figuring out how various CSS tricks work. Inspect element, turning properties on and off in the browser to see how they affect things, seeing the effective CSS for an element after inheritance, etc, etc. You'll learn much faster this way.

(2) Yes, StackOverflow and ChatGPT can help a lot for quick one off hacks so yes, use them. But, as I alluded, you want to build deeper understanding in the long run so be sure to...

(3) Actually read proper documentation that explains the underlying architecture and concepts. MDN is best for this. It's really fucking good. Well, actually, maybe I'm not qualified to say that, there may well be other great sources too. But considering it's from a browser maker, it's pretty damned close to being "the official manual". (It's also great for JS browser APIs and HTML)

I feel you my friend. I am in exactly same boat. I even asked here previously on what CSS resources I can ready/follow.

Ultimately, I gave up and hired frontend engineers from low cost countries to build the frontend for me. I just write backend APIs. Life has been much better with this strategy. One thing that may help though is to pick tailwind css. It may ease the pain to some extent.

To anyone who says use codepen, MDN docs, smashingmagazine CSS tutorials, inspect console and a bunch of other resources, I tell them this. None of these tutorials help you when you have to reason why things are not coming out the way you expect them to. There is no "compiler" for CSS which spits out error messages. You cant describe a behavior and ask the browser to tell why given CSS will not give said behavior. Most tutorials are about simple boxes and simple websites. When you have to modify something in a complex webapp, it pays to do it under an able mentor.

</rant>

Yes, it is hard and a lot of it is through necessity, especially on larger projects and applications. You can do simple things, simply. You can leverage UI toolkits, frameworks and build on what others have done. But it's a different beast.

That doesn't even include UX niceties that aren't in the box. Such as focusing the username field on a login screen, being friendly to form filling agents and password managers, making sure the app/site works without the analytics and ads loaded. All of which I've seen missing or poorly done on websites for multi-billion dollar companies.

A lot of good front end developers are good with programming concepts as well as compulsive about a good experience. I'm pretty partial to mui (material ui toolkit for react) myself, which is probably the best ui toolkit I've ever used. Even then, most devs I've worked with won't/don't take the time to even look at the documentation and examples to know what can be done and how. They try to bypass the theme system that's in the box.

You either have to understand a lot of things, or take the time to leverage what you're using well... many devs do neither on the front end, and businesses concentrate more on new features than polish more often than not, rewarding the poor experience.

I've yet to use any kind of banking app or website that I find to be "good" for that matter, and I've worked inside enough to see and understand why.

That said, you can go a long way with Go+HTMX and there's very little wrong with that. There are plenty of higher level CSS based frameworks that do very little on the implementation of controls for you. There are definitely options out there.

Try Vue 3 or Svelte instead. React is a pretty retrograde DX these days, and still lacks basic concepts like computed refs, making it the least reactive of all the current UI frameworks.

CSS can easily be really complicated, you can shovel layer upon layer on it and it still seems to work (a lot of guys just cut and paste in new styles). Most cutting edge CSS I see on sites is just to provide animated transitions and effects - you can reduce a lot of overhead if you don't care about animated headings and the like.

My suggestion is:

- Try to keep it simple - start with the basics - A older but very good book on CSS basics is: Stylin' With CSS: A Designer's Guide by Charles Wyke-Smith

- Use the inspect/debugging tools in your web browser to reveal the smoke and mirrors of website elements you like to figure out whats doing the actual work.

As an example is https://doplaces.com - not perfect but I tried to keep it to a minimum while still being functional and flexible...

Biggest quick improvement for CSS will be learning TailwindCSS[0] and FlexBox[1].

For React.js and JS, I highly recommend select parts of this University Helsinki Full Stack Open course[2].

[0] https://nerdcave.com/tailwind-cheat-sheet

[1] https://flexboxfroggy.com/

[2] https://fullstackopen.com/en/part1

1. Backend and devops are disciplines rooted in _mechanical sympathy_. Basically, the better you can understand the needs of the stack (hardware on up,) the better you can meet requirements, which, generally, are stipulated in clear-cut technical terms ('this many requests per hour', etc.) Minimizing complexity is a core value.

2. Frontend is rooted in _user sympathy_. The better you can understand the users, the happier you make them. There are bodies of knowledge (usability theory) that can help with this, but the users are often "irrational" (but, crucially, not _wrong_) in their preferences; e.g. preferring a complex PWA tech stack with a 5s initial load time (but buttery smooth responsiveness thereafter) to a simpler static htmx-style stack with a 0.2s load time per click. They also experience ever-changing needs, and respond enthusastically to trends that do not have any clear basis, (skeumorphism vs not-skeumorphism, etc.) but are nonetheless _vital_. If it's important to your user, it's important, and your job is to do anything and everything to meet those needs, even at the cost of enormous gobs of complexity (provided those gobs don't make them less happy in some other way, today or tomorrow.)

CSS, in particular, has evolved over a period of decades to meet these requirements, and generally does an admirable job of meeting the whims of users, but at an ineluctable complexity cost. (Why do users want drop shadows? Why do they want masonry grid layout? Who knows, but here you go!)

React, similarly, is a Rube Goldberg machine that, for whatever reason, seems to produce apps that meet user expectations better (more efficiently) than alternatives, without fudging the details (or going 'brutalist')

Other strategies -- insisting on old-school 'simple' design, which while conceptually pleasing to non-frontend engineers (that mechanical sympathy!), trade off pizazz for maintainability; but often, I expect, they discover that a non-zero number of users _liked_ the pizazz; that it was a sotto-voce requirement; and that it is now out of reach; and that their solution now has worse product-market fit than it would otherwise have.

This is why, while engineers love htmx, but it rarely shows up in big consumer-facing products. It would appear that for apps like Gmail, etc. something like the PWA model is a more natural centre-of-gravity.

I recently started doing some front-end stuff using C# with Blazor [0]. As UI component library I'm using MudBlazor [1].

I think it's very easy to create a beautiful app this way. You can still use CSS if you want, but don't really need it to start out.

If you want to style an app, just adjust a couple of colors (primary, secondary, surface, background, ...) of the theme and the app looks quite different already. I believe the color scheme is based on Material design, as such, many (shades of) colors will be automatically calculated based on the couple of colors you choose.

Of course you can also change fonts, icon font, etcetera to further customize the app.

The best thing about this approach from my POV is that you don't have to deal with much JavaScript, CSS, HTML ... (though the option is still there when needed).

---

[0]: https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...

[1]: https://mudblazor.com

Use a design system as a starting point, like https://clarity.design

Different design systems give varying levels of guidance; Clarity is on the more detailed side:

- General UX guidelines, like when to use alerts vs banners vs modals[1]

- Basic color palette

- Icons

- Basic responsive layout

- Framework-agnostic web components

---

Also https://www.refactoringui.com seems to be a front end guide for (back end) devs

> Make your ideas look awesome, without relying on a designer.

> Learn how to design beautiful user interfaces by yourself using specific tactics explained from a developer's point-of-view.

From the creators of https://tailwindcss.com. Tailwind is also a (less prescriptive) design system.

[1]: https://clarity.design/documentation/notifications

> But, I want to build beautiful web applications, but I don't get CSS. Like is it supposed to be this hard to build a UI?

IMO, CSS is the hardest part of FE dev. It's deceptively easy, but you can still create good looking UI if you use 3rd party libs like bootstrap, tailwind, bulma etc.

> Recently, I've been trying to learn more about Frontend and started exploring a React project at work.

> Given my experience with this archaic pattern, I've now started exploring HTMX with Golang. This seems more my speed.

Do you want to build FE apps or learn about how FE frameworks? If you just want to build, you can use Golang templates with the above mentioned CSS libs. If you want to learn for career change (BE->FE), you'd have to learn React/Vue/Svelte etc.

You need to start by copying. Find a page and try to reproduce it on your own. Keep doing it and you'll get to the point where you're comfortable doing your own designs.

I am currently maintaining three SaaS products I built with Go. It's a great tool for the job.

One was with Go with vanilla HTML/CSS/JS (with Turbolinks classic for snappy page loads/transitions). The other two products were built with Go and HTMX+AlpineJS+Tailwind CSS.

In retrospect, I'd like to remove Tailwind as it bloated the HTML a lot and rebuilds are slow (~300ms to ~500ms per-build). Alpine has its uses, but I don't think I used it enough to really need it.

To be clear, most frontend dev work isn't programming.

Laying out some UI with React and CSS isn't programming but design.

So you need to shut your hacker brain and think more visually and then learn whatever arcane random methods you need to know and call to make is show up.

React's use of hooks, rendering, useEffect and what runs when is just horrible and unintuitive. Try to learn as much as you can, but know, this is not real programming. This is more biology and less physics.

I define programming = thinking computationally and what the CPU needs to do.

I've found CSS to be brutal because there's SO MANY gotcha's.

You can check out bootstrap or a CSS library, they make CSS manageable for a non-expert to do cool stuff with CSS.

JS isn't too bad in modern times, async/await is awesome instead of promise chains.

Web components out the box as well.

I struggled with understanding web frameworks, though I didn't struggle understanding the basics of plain JS, html, and CSS. CSS kind of just made sense for me.

In the end I settled on dart/flutter for frontend.

everthing you did in the past just work still. You don't need the shiny new toys

Take a look on Elixir/Phoenix/LiveView.

if it's for work and you need to use xyz js frameworks/libraries then i don't have any advice to give but if you're just making personal projects, i'd recommend sticking with vanilla html, css and js as much as you can, unless you're running into a specific problem which something specific solves. the more you do that, the more you'll actually be able to understand the value proposition of basing a project around whatever the fancy new framework of the week is. realistically, you don't need react, you don't need svelte, you don't need nextjs, and so on. almost nobody does.

front end dev at this point is deep in the "so and so does this so i should do this" territory and there's a hell of a lot of junior level devs shilling all sorts of stupid bullshit which nobody ever needed because they've never had to maintain anything for a long time because they switch jobs every year, leaving a huge pile of convoluted shit in their wake.

rant over, feel free to call me a cranky boomer now lol

FWIW, I'm a frontend dev now, but I grew up with a 14.4k modem writing HTML by hand, having just missed Gopher, but that was still before JS and CSS were invented.

I think part of the difficulty of modern frontend dev is that you're dealing with 20+ years of, well, tech debt. HTML was initially a document markup language (think RTF) that just exploded beyond anyone's wildest dreams. CSS and JS were tacked-on afterthoughts made by generations of competing browsers, operating systems, and device types. It's layers upon layers of iterative, revisionist, evolutionary, revolutionary design all rolled into one. It's a mess. How could it not be when you start out with a document layout and somehow end up with a multi screen real time phone app?

That explains the technical part of the chaos, at least (which continues today with the 500 -- no sorry, 600 now -- different React frameworks). But there's also the design side of things.

The last few decades have seen tremendous amounts of resources, research, and conflicting opinions poured into UX and marketing, studying the best ways for an ultra optimized hyper-button to encourage someone to spend a dollar more. It's a 5-way intersection of art, science, marketing, unhinged capitalism, and your manager's personal opinion. Recipe for success, right?

That said, it can also be a lot of fun! You're juggling both technical complexity and human ambiguity. None of the research is perfect, none of it applies to every user or every use case, and none of it is going to be right for every organization, team, or project. There's always room for nuance, which means there's always additional complexity. I'm not arguing that's a good or bad thing, just that it's the reality. Like any novel or painting or advertising poster, people are going to disagree on how effective it is.

That said, there are still broad trends and patterns that many organizations have found to be useful in most cases. These eventually become enshrined into standard best practices, by which I mean specialized think tanks and bloggers mostly agree on them, and if you're really lucky, sometimes they even get enshrined into standards (like WCAG accessibility criteria, which are designed to make the web more user-friendly for all, not just people experiencing disabilities).

So all that said, here are some actually actionable things you can look at. They're just starting places, so it's fine if you don't agree with all of them.

A good short book with useful patterns: https://www.refactoringui.com/ It's one of the best resources I've come across in 20+ years of doing this.

The CSS framework made by those authors: https://tailwindcss.com/ By framework, I mean a set of composable CSS utilities (think "library of style snippets") that abstract over the raw stuff to make quickly reusable functions. It's fine to learn raw CSS, but in day to day work we almost always use a framework of some sort to make life easier, only falling back to vanilla CSS to make modifications when necessary.

Nielsen Norman is one of the big names in UX and accessibility research, and they have many wonderful free articles: https://www.nngroup.com/articles/#popular

https://www.linkedin.com/learning/ (formerly Lynda.com) offers high quality paid video courses for frontend dev, UX, and accessibility. It's my preferred way to learn new concepts.

https://mui.com/ is a set of composable React components (primitives/widgets like a button or a modal popup or accordion or a card, etc.) that make composing a full app much easier. It's overwhelming to start out with something like this, but just take a look at their component examples and templates marketplace to see what you can eventually build up to. Many teams will use a framework like this or build one themselves internally so they can design and write components instead of raw HTML (which isn't very reusable or composable). This is the major strength of React, and why a lot of teams use it (easier to share and reuse components between team members, teams, projects, and generations).

I won't get too much into frameworks here, because honestly they're all going to be out of date by the time I finish this sentence (sigh). Frontend makes you feel old.

Just think of it as an art project where you're also learning to weave the canvas and manufacture the paintbrush bristles yourself while also designing the gallery around it, but the construction company is experimenting with some new building materials and the government decided to revamp the building code for the fifth time this year. That's frontend dev for ya... don't worry lol, nobody can keep up, we all just kinda fake it and try our best :)

Frontend development is like being a TikTok influencer: it's an bullshit boondoggle that wouldn't even exist in a better society.