Live data from Hacker News

Front-end design, React, and a bridge over the great divide

bradfrost.com

61–70 of 137 posts

Re: Front-end design, React, and a bridge over the great divide

#61
post #8

> Crafting semantic HTML markup with a strong focus on accessibility, in order to make experiences that are friendly to browsers, assistive technologies, search engines, and other environments that can consume HTML. > Creating CSS code that control the look and feel of the web experience, tackling colors, typography, responsive layout, animation, and any other visual aspect of the UI. Frontend designers architect res…

How many of us get to walk into green field projects or even decently architected projects? Accessibility isn’t too hard if you build conventions around doing it from the first commit, but adding aria tags and labels to 100s of old files is going to be a massive undertaking that few product managers will sign off on. I think it is less incompetence and more when it comes down to the wire, those are the first things t…

It doesn’t really matter what’s there already. If your job this week is to add a new feature, spend some time this week thinking about accessibility. If you’re just fixing something old, then don’t worry about it.

I’m not even going to be prescriptive about how much time. If you have 5 minutes, fine, good.

Re: Front-end design, React, and a bridge over the great divide

#62
post #45

Earlier quoted context omitted.

I don't think so, at least not for the kinds of apps I build. My biggest problem is largely around interactivity -- shuffling lots of data back-and-forth between the client and the server. If I'm going to have a SSR app with lots of AJAX code running on the client, I might as well just go all-client.

SSR can be used with React (NextJS), Vue (NuxtJS) and Angular (Universal Angular).

This supports the argument you're replying to.

Re: Front-end design, React, and a bridge over the great divide

#63
post #4

> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bunch of angry nitpicking comments. All I’ll say is that when I go over to projects where I’m writing HTML or HTML-like stuff (Vue, for instance), it feels like a breath of fresh air. JSX is fine, the real power is building your HTML in pure JavaScript. I'll nev…

I was initially a pretty big fan of JSX, but after using Vue it just feels like extra overhead. In my experience, parsing complex JSX in my head results in constant context switches depending on whether the specific parts I'm looking at are closer to HTML or closer to JS. And for the tasks I've generally been doing at work, there rarely seems to be a good reason to combine the two. If I'm trying to fix a bug for exam…

I keep hearing all of these "Vue just makes more sense than React" converts, and I'm baffled. I recently did some Vue after doing React for a few years, and it felt like a major step backward. It felt very JSP - here was a different syntax that was HTML except when it chose not to be - managing data was done in a custom expression language, and I was left to figure out what scope a given value had. Need to loop something ten times? It's one tag with a special "v-for" property. Want do to that loop with a condition? Special "v-if" property, and is that evaluated in the scope of a variable created by v-for or not? No idea! And that's not even getting into the various parts a Vue component object has.

JSX is just javascript. It's HTML looking, but is ALL (not some) a wrapper to write a JS function that outputs HTML. Need to have a loop? Loop in JS. Need to have a conditional? Condition in JS. What scope? This is all a JS function, so the scope rules are all JS scope rules.

I have no idea if I'm a weird minority, or if I'm just running into more people that felt better with Vue than React, but I really don't understand why.

Re: Front-end design, React, and a bridge over the great divide

#64
post #26

Earlier quoted context omitted.

Question: do you generate the sketch file from React code??

No. I've seen the output and it's just not very usable. If you need that functionality these days Framer and it's bridge product is nearly magic. You can set up some basic shim wrappers on your React components and things work perfectly.

Great, many thanks!!

Re: Front-end design, React, and a bridge over the great divide

#65
post #7
post #3

Earlier quoted context omitted.

I continue to believe that the loudest perpetrators of JavaScript hate are those who overcomplicate simple things or follow other people's advice to overcomplicate simple things. Things like using SPAs for five page sites, throwing Redux into every CRA installation, npm installing useless packages like is-odd or leftpad (lol), etc. You don't need to use ! You don't need JSX! You don't need ! Surely you still don't ne…

But seriously why can’t I just do modern webdev with a ?

Wait, is there some other way to load scripts now? Asking for a friend...

Re: Front-end design, React, and a bridge over the great divide

#66
post #42
post #10

every time Brad Frost writes something a bit controversial, it always feels like he can write and understand html and css, but anything else (including React) is way over his head. No disrespect, it just feels like he's not spending the time necessary to understand how things work and instead of doing so, he just goes on and vents on his blog.

For me, it's not that I'm overwhelmed by the learning. I understand the "what" and "how" just fine. But React is a paradigm shift that I have yet to fully grok the "Why" for. It often feels like I'm having to re-solve problems we've had solutions to for a decade, on top of all the brand new problems React introduces. The core problem React solves, "re-usable reactive components", just doesn't come to fruition in most…

I'm curious as to how you can make reusable UI components with just a bit of file organisation?

Re: Front-end design, React, and a bridge over the great divide

#67

Earlier quoted context omitted.

I suspect that, in 2-3 years, server-side rendering is going to be rediscovered as a cure for the plague of spaghetti frontend code, just as current template-in-javascript metalanguages are being discovered now as a cure for spaghetti frontend-plus-backend-rendered code.

So, basically video-streaming, but with websites instead of tv shows?

Basically what most web frameworks have been doing since we moved beyond CGIs.

Re: Front-end design, React, and a bridge over the great divide

#68
post #4

> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bunch of angry nitpicking comments. All I’ll say is that when I go over to projects where I’m writing HTML or HTML-like stuff (Vue, for instance), it feels like a breath of fresh air. JSX is fine, the real power is building your HTML in pure JavaScript. I'll nev…

You should check out CLJS's reagent. It mixes the best of both worlds, everything is a plain CLJS object without special syntax, but it's also obviously HTML/CSS: [:div {:style {:display "flex", :flex-direction "row"}} [:label {:for "email"}] [:input {:type "text"}]]

That looks really ugly IMHO, compared to JSX which is more HTML-like.

Perhaps it might look better if there's a bigger example?

Re: Front-end design, React, and a bridge over the great divide

#69
post #4

> While I’m definitely a lot more fluent in it now, I dunno, it just still feels a bit weird to me. I could share some specifics but that would only invite a bunch of angry nitpicking comments. All I’ll say is that when I go over to projects where I’m writing HTML or HTML-like stuff (Vue, for instance), it feels like a breath of fresh air. JSX is fine, the real power is building your HTML in pure JavaScript. I'll nev…

After doing Elm or PhoenixLiveView, I'll never go back to React stuff. Every time people trying to re-invent html, it will end up pretty much HTML. It's simple and powerful. The sad part is developer resources spent on optimizing for JS instead of joining force improving HTML standard.

Re: Front-end design, React, and a bridge over the great divide

#70

Earlier quoted context omitted.

You should check out CLJS's reagent. It mixes the best of both worlds, everything is a plain CLJS object without special syntax, but it's also obviously HTML/CSS: [:div {:style {:display "flex", :flex-direction "row"}} [:label {:for "email"}] [:input {:type "text"}]]

That looks really ugly IMHO, compared to JSX which is more HTML-like. Perhaps it might look better if there's a bigger example?

> That looks really ugly IMHO, compared to JSX which is more HTML-like.

The point of this is not of asthetics, (IMO it’s not that ugly :-)) but more that it just consists of common data structures that is easy to manipulate. If you’re a React person, think of directly writing JSON instead of using indirect React.createElement calls. Writing components in JSON would be impractical; (actually it might not be - I think I’ve seen blogposts using React without JSX) but writing components in cljs data structures are practical and less tooling is needed!

Post reply on HN