Man I hate typescript.

Using 'raw' JS/CSS/HTML is a coveted skill. A lot of people forgot and/or never learned how to do that. Those over engineered frameworks are essentially a form of premature optimization, and in many cases obsolete because modern browsers already implement their whole reason for existing.

Those articles I linked have a good discussion of it, but pure css has come a very very long way and a lot of these frameworks aren't even necessary anymore. You just bloat the browser, and for little good reason. Tailwind is nice to use if you don't know much CSS, but still know some, since you can just look at a giant list of "what does this do" and choose one that looks good. But yeah, I think I'm going to cut back on my usage of Tailwind massively, it's just annoying a lot of the time.

My impression is that writing "pure CSS" has been replaced by writing !important selectors that undo all of your component library's auto-generated CSS, and then write your own CSS selectors on top, after trying to figure out the theming system for half a day... /rant

It's about the setting defaulting to on. When did Firefox change that? When they first introduced it I had to set it manually and I don't know when/if that changed.

Is it the same setting that's been in Firefox for like... I don't even know how long?

If you want to try another, maybe Material. (The design guidelines or the components. But IMO the component docu has gotten worse.) But if you are going to overwrite the styles anyway, it may be easier to write your own CSS instead of debugging someone else's.

So learn the HTML/CSS basics that you are missing, mostly on MDN. (CSS: selectors, pseudo-classes, flexbox, grid, css variables, units like rem/px/vh, media queries, collapsing of the margin, css reset and box-sizing, overflow, display, positioning, ...; HTML/Web APIs: CSP, self-closing tags, fetch() API, querySelect(), URL.parse(), sessionStorage, form submit, form validation, blob, event bubbling, your browser's inspect tools, ...).

Even if you use a framework you will generally have to learn all this stuff anyway.

The most future proof web tech is not using frameworks and libraries at all.

Render native HTML controls.

I also assume it's lower barrier than any of the libs and frameworks you could use, which is always a subset of web tech with the addition of their own concepts.

Tailwind is an example of those frameworks fighting against/crossing the native web technologies referenced further up with the links to webdev posts.

The idea of shifting CSS declaration into the DOM element class attribute seems flawed to me. You lose what CSS provides natively.

If you don't care too much and don't have experience yet, why not go for native browser and HTML/CSS/JavaScript?

Even if you eventually migrate to other web UI libs and frameworks, the foundations knowledge will be useful.

Front end is such a wasteland of overdoneness now. It used to be fun :/

Interesting, my impression is very much that the days of writing "pure CSS" is at an end, and that UI libraries and CSS frameworks like Tailwind is the way forward. But that is just my impression.

With svelte I’ve only found like two “component” libraries and I’m not sure I’m going to continue to use them. Essentially they just are drop in components so you don’t have to write them yourself. But svelte really seems to like it when you just write the css yourself. I’ve been using tailwind with it and I honestly think I’m going to stop, because it’s harder than just writing normal css that covers either a specific component or the whole app.

Svelte(Kit?) does look pretty nice. I guess I'll try it out, but even then there are many UI libraries and other libraries that need decisions. It seems like in the frontend world, I never run out of choices 😅.

I'll jump on the bandwagon and say that while I haven't used Svelte or Quik, I have used React, NextJS, and a lot of older tech like AngularJS, ASP, PHP, JSP, JQuery, YUI, vanilla JS, ...

I agree. React is over-engineered, and tries to solve the same thing Angular does: optimize for the most efficient DOM updates possible. As a result, your code is compressed into hard-to-debug pretzel shapes. Its cousin, NextJS, confuses front and backend in such a way that you'd need to be experienced with the separation before being able to navigate it. Neither is starter tech by any stretch of the imagination.

I've dabbled a bit with HTMX. I really like this one since it more closely resembles the dynamic web we had before JS and heavy-clients took over. You wind up with a lot more chatter between the browser and server, but each of those conversations can be engineered (more or less) in isolation from the rest of the app. Meanwhile, you avoid round-trips that update the entire page - the very thing that these other stacks try so hard to avoid. You can build an HTMX application one component at a time, instead of all-or-nothing. This makes troubleshooting a lot easier, so it's likely an easier place to start.

I’m also a backend dev that hates how many frameworks there are. At my last company i built a small tool and chose svelte. I’m glad i did. It is so easy for a backend dev to learn in comparison to react or angular or vue. I wouldn’t touch those three with a 50 ft poll in this day and age. There’s several good articles on why in the !webdev@programming.dev community a few days ago.

https://programming.dev/post/39156162

https://programming.dev/post/39374784

I would choose HTMX, Astro, Quik, or Sveltekit. I really like svelte, and it’s been at the top of stack overflow’s “beloved” chart for several years now. It really is a joy to use compared to react or angular (at least for a backend dev like me). I know they’re not nearly as popular, but using react is like using J2EE, you don’t need it, like 99.99% of the time.

This is orthogonal. If you want to do anything custom, it will often be easier to not use your JS framework at all for that part of the App. If you are going to use Tauri you will be using the Tauri API not the API of your framework. If you want stuff like touch input or show system notifications, you'll use the browser's APIs for that. If anything the framework will be in the way for lower-level stuff, and you always have the option to not use it for some part of your App.

I'm a visual thinker and I love art. I picked up coding 10 years ago for survival purposes (I'm currently unemployed). What you need to understand about frontend development is that everything being rendered on screen as DOM elements are fancy looking blocks on a grid. Key value pairs never go away, they just get a coat of paint. There are best practices such as making sure not to put #000000 text on a #ffffff background and some fancy CSS tricks to make things visually appealing. You need to translate brand guidelines and designs into variables so you can template out as much as you can for reusability. Using the ANDI browser extension will check your DOM for accessibility so people with screen readers and poor eye sight will be able to use your app.

Dear god someone give me a job.

more engineer minded people (I’m more design minded)

I'm definitely more engineer-minded, but that is another thing I'm having to deal with in my frontend journey here 😅. Figuring out how to code a UI is one thing, but figuring out what the UI should even look like to begin with is a whole other thing. A thing I'm very uncertain about still. Were you always design-minded or was it something you learned? I feel like I was always engineer-minded and backend came very naturally to me.

I know Python but I don't like using it 😅. I've definitely considered going the non-JS/TS route and using something like Dioxus, since I know Rust very well, but I'm not sure that really a super viable way as it's still quite early for that sort of approach in the Rust ecosystem.

The negative feedback I get from more engineer minded people (I'm more design minded) is that the library is bloated and its features are convoluted. When it first came out and it was completely class based components that was confusing to me. Now the library is focused on functional components which makes it more intuitive in my opinion. With that said React is my bread and butter.

Counterpoint, what if you don't end up doing or needing that? Then you've paid the cost of complexity and added maintenance burden to update dependencies for no reason.

If you do end up needing a complex feature, perhaps the complexity can be isolated to just the part of your application that needs it? For example React can be used to render just parts of one page.

For mobile apps, perhaps all you need can be accomplished as a progressive web app (which is "just" regular HTML, CSS and JS at the end of the day)? That way you don't have to deal with or pay for app store distribution.

If you already an expert in python, you can keep doing that and build a frontend in python using Dash. They have bootstrap components and mantine (React) components for options of style you might prefer. Don't need to write JS or HTML. It's enterprise grade and widely used by large enterprise projects.

Another is Reflex but their open source version is tricky to run in production. They promote more of their cloud version or enterprise license.

My two cents is React, but that drives people nuts.

Could you elaborate on why you think it drives people nuts? And why you are recommending it despite that? Genuine questions, just looking for some reasoning as I have no intuition in this area myself.

My backend is in Rust - I've definitely considered something like Dioxus, but I fear that the Rust ecosystem is not ripe for frontend still. But I may be wrong. I've tried Yew before and it was "okay" but definitely not nice.

So my initial instinct is to stick with the JS/TS frameworks.