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

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

bradfrost.com

Post reply on HN
Print view View original

121–130 of 137 posts

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

#121

Post by dmix »

WA wrote: post #72
dmix wrote: post #48

Earlier quoted context omitted.

What about the whole component based approached? You could certainly take a component based approach with simple code organization in HTML, CSS, and JS frontends. I've done that before, in a sort of pseduo-web components way using directories and naming schemes. React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration. Which increases reusabil…

> React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration But is this really true? If you have simple presentational components, this is probably true. But your app is tied together by "container components". The state is unique to the app you're writing. You have to somehow map the state to the components. Maybe you use "container components…

It's true Redux/VueX creates a habit of coupling your components to the specific usecase. But I've been using them for over a year now and whenever I've had to reuse a component, often in very different environments, it takes about an hour of tweaking to make the component reusable. Sometimes you have to rewrite parts of the DOM to make it more flexible.

But this is like any abstraction in programming. When you have a function you want to be reusable you usually have to do some work to make it more portable across your codebase and create a proper flexible "interface" for it via arguments.

The UI components are particularily easy to reuse. If you look at something like Rebass it uses predefined constants to add consistency of values across the entire site + a theming system which simply tweaks those constants (ie, colors, the scales of font sizes across h1-h6, etc).

https://rebassjs.org

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

#122

Post by ebiester »

zbentley wrote: post #34
ng12 wrote: 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 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.

...and then they'll hit POST-redirect-GET and all the problems with the back button and holding state on the server.

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

#123

Post by robertoandred »

tambourine_man wrote: post #101

I remember when I was messing with MooTools and Prototype and then I saw jQuery. OMG, yes, I want that! So powerful, freeing and easy. I've never felt that way since with JS. Backbone didn't have much appeal. Angular, I knew I didn't want to touch it with a ten foot pole. React was interesting, but usually more trouble than it was worth. Vue feels the nicest of the bunch, but not breathtaking. I guess what I'm saying…

The problem being solved IS (manual) DOM manipulation. It's messy and error-prone. Using React et al to generate the DOM as a clear function of state is much better.

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

#124

Post by cljs-js-eval »

rhaksw wrote: post #24
cljs-js-eval wrote: post #18

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"}]]

is this much different than JSX? I definitely want to try CLJS some time. edit Oh I see. You don't need the extra {} to jump into JS mode. And, CLJS requires : to denote keys. I think as long as my editor colors the syntax appropriately I'm okay with either.

The :display is a keyword, which works like keywords in Ruby or Erlang; it's a special, never-garbage-collected string for when you use the same string over and over. Though I'm not sure whether the implementation is the same when compiling to Javascript instead of the JVM.

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

#125

Post by tambourine_man »

robertoandred wrote: post #123
tambourine_man wrote: post #101

I remember when I was messing with MooTools and Prototype and then I saw jQuery. OMG, yes, I want that! So powerful, freeing and easy. I've never felt that way since with JS. Backbone didn't have much appeal. Angular, I knew I didn't want to touch it with a ten foot pole. React was interesting, but usually more trouble than it was worth. Vue feels the nicest of the bunch, but not breathtaking. I guess what I'm saying…

The problem being solved IS (manual) DOM manipulation. It's messy and error-prone. Using React et al to generate the DOM as a clear function of state is much better.

I’m not convinced.

Again, jQuery was an easy sell. Saying manual DOM manipulation is messy… not so much.

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

#126

Post by [deleted] »

jypepin wrote: 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.

[deleted]

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

#127

Post by typetrail »

jypepin wrote: 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.

Are you referring to posts like this?: http://bradfrost.com/blog/post/my-struggle-to-learn-react/

"There’s a giant, great JavaScript community out there, but I feel like a lot of times there’s an implied (or sometimes explicit) 'OBVIOUSLY' or 'just' that comes with a lot of the territory. For instance, I was confused why there are different ways to create components in React, and several people tersely responded 'it’s common knowledge that you use functions for simple components and use classes for managing state.' I had no idea! I didn’t see an explanation of that stuff in the docs. If that’s what the convention is, that’s totally fine. Just don’t assume everyone has that info downloaded.",

The assessment is pretty harsh on the guy, I think in Brad's case he's one of the more publicly documented instances of someone putting in the right kinds of effort.

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

#128

Post by pierreyoda »

dmix wrote: post #121
WA wrote: post #72

Earlier quoted context omitted.

> React and Vue makes it easier with single file components and wrapping it in functions which makes handling state and configuration But is this really true? If you have simple presentational components, this is probably true. But your app is tied together by "container components". The state is unique to the app you're writing. You have to somehow map the state to the components. Maybe you use "container components…

It's true Redux/VueX creates a habit of coupling your components to the specific usecase. But I've been using them for over a year now and whenever I've had to reuse a component, often in very different environments, it takes about an hour of tweaking to make the component reusable. Sometimes you have to rewrite parts of the DOM to make it more flexible. But this is like any abstraction in programming. When you have…

On your last point, I feel like components this basic should really rather be addressed at the real theming level, i.e. in CSS.

Utility-first CSS frameworks are awesome if you get past your first impression. I've been using TailwindCSS [0] both at work and for all my personal projects ever since I read Adam Wathan's justification on it [1]. In TailwindCSS those constants are configured in one place and generated at build time (through Rollup/Webpack/PostCSS etc.). Consistency and theming for free basically.

Even Bootstrap has now a decent collection of them in v4.

[0] https://tailwindcss.com/ [1] https://adamwathan.me/css-utility-classes-and-separation-of-...

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

#129

Post by zubspace »

WA wrote: post #75
corebit wrote: post #7

Earlier quoted context omitted.

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

You can, but have you tried it? The biggest difference is: Before React/Vue, you usually told the UI how to change based on some action. Which is fine, but gets complex really quickly. Take something simple like a login form. Assume for a moment that there is a REST API for logging you in, so there’s no server-side rendered version of your login form. Now you want to make things a bit nicer for the user: Obviously, t…

Thank you. Of all things I've ever read about react, your post is the first one who clearly explains WHY we need something like react and what fundamental problem it solves.

A frontend designer's job is to manage the state of the visible UI controls. There are lots of requirements which evolve and change during the lifetime of the project. You need to encode the application state and transition the controls according to the state. Before react, you mostly kept some variables around somewhere, added some ifs and elses which update controls, handle some events, update the state and you extend and extend and extend... and finally you have a bowl of spaghetti with some state sprinkled all around.

React separates the state from the UI update phase. Simple and elegant.

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

#130

Post by rhizome »

digitaltrees wrote: post #113
save_ferris wrote: post #102

Earlier quoted context omitted.

You didn’t mention all of the new features coming to HTTP 2 that will alleviate network performance issues (prefetch, multiplex connections, etc.) I’ve found many sites that use frameworks like react to be much more user hostile, particularly from a performance and accessibility standpoint. The reddit redesign comes to mind. It’s so much slower now than it used to be on a browser (perhaps they’re intentionally doing…

Same with TechCrunch, every time I visit I am reminded how frustrating react sites can be compared to server rendered pages with all the flicker, slow page reveal, and odd navigation it introduced.

Late loading artifacts is all the fault of JS, not server-side rendering. Not sure what you mean by "odd navigation."
Post reply on HN