Front-end design, React, and a bridge over the great divide • Hacker News Board

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

#101

Post by tambourine_man » Fri, Jul 19, 2019, 12:55 PM UTC

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 is that, after seeing jQuery, I knew I would not use anything else. It solved a problem so well (DOM manipulation) there was no need to.

With recent JS frameworks, it feels like we haven't even defined or come to agree on what the problem we are trying to solve is.

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

#102

Post by save_ferris » Fri, Jul 19, 2019, 1:02 PM UTC

jasode wrote: post #80

zbentley wrote: post #34

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.

>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, Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers , I can't see how the industry will migrate back to server-side rendering in 3 years. The unavoidable technical issue is the round-trip latency of the network. The same delays…

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 this to push people to their mobile app), that it’s noticeably reduced the quality of the experience.

I guess I just don’t understand how people see page reloads with proper caching as unacceptable from a performance standpoint compared some JavaScript app maintaining a virtual DOM, which is also likely regularly communicating with a server.

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

#103

Post by onion2k » Fri, Jul 19, 2019, 1:24 PM UTC

dahfizz wrote: post #92

onion2k wrote: post #58

Earlier quoted context omitted.

If you need custom data in the page on a per request basis then SSR is usually the fastest method to generate the final HTML but it isn't the fastest method of getting something on the user's screen. Its "time to render" that counts, and that means doing as little work as possible to send something to the user. Serving the same static, "prerendered" HTML file with no customization to every user is always going to be…

I hear this often, but I am unconvinced. This just leads to jittery pages that keep moving when I try to do something to them. Just seeing the skeleton of the web page doesn't make it fast. The page will be unresponsive for longer and will visually stutter while rendering. It's a much worse user experience imo.

Just seeing the skeleton of the web page doesn't make it fast.

I didn't say it does. Skeleton loading is slower. It feels faster though, and that perceptive improvement is more important than the actual time something takes. If you ask users which they think is faster they usually say the skeleton version regardless of the facts. When your key metric is user satisfaction rather than raw download speed that's important.

The page will be unresponsive for longer and will visually stutter while rendering.

That doesn't have to be the case though. There are plenty of techniques for writing client side code that doesn't block user interaction.

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

#104

Post by jameal » Fri, Jul 19, 2019, 1:25 PM UTC

sanitycheck wrote: post #96

Things I get from designers: 1. Wireframes 2. Layouts (bitmaps) 3. Assets (fonts, images) (4. Occasionally, interactive prototypes made with designer-friendly tools.) Designers already suck so badly at HTML & CSS that getting them to do any wastes more time than it saves. They don't need to be let near any other implementation tech either, not Android layouts, not iOS storyboards, and not React. Designers don't reall…

The author makes the point that "frontend designer" may not be the right title, so perhaps "UI developer" or one of the other titles he listed is more appropriate.

So I don't think he's talking about making designers learn implementation. The point is that the scope of frontend development has expanded so much that it makes sense to split responsibility between "front of the frontend" UI responsibilities and "back of the frontend" responsibilities like managing state, cache invalidation, routing, etc.

In any case the line between design and dev turns gray when you consider that designers can't practically mock up designs for the web for every viewport size, define what every micro interaction looks like, etc. There are so many nuances to creating a great UX that it makes sense to have a class of front end devs with those kinds of proficiencies.

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

#105

Post by jameal » Fri, Jul 19, 2019, 1:33 PM UTC

tenaciousDaniel wrote: post #37

I love Brad Frost's work and writing, but I seriously disagree with this. Imagine being a designer at a place like Netflix. Your product is among the most ubiquitous in the world - if there's a device with any kind of screen, Netflix has an app for it. Now imagine developing a skillset, as a designer, that totally locks you into one platform (the web in this case). It makes absolutely no sense. I don't care how "easy…

People are getting stuck on the word "designer." The point isn't that all designers need to be involved in implementation but that the scope of front end _web_ development has grown so wide that it makes sense to split the responsibility between "front of the frontend" and "back of the frontend."

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

#106

Post by pjmlp » Fri, Jul 19, 2019, 1:40 PM UTC

efdee wrote: post #88

pjmlp wrote: post #73

Earlier quoted context omitted.

JSX feels like PHP and ASP all over again. Apparently they aren't that bad after all.

How can you say that? PHP and ASP were dumb text template processors. JSX creates object graphs. They are almost nothing alike at all.

Mixed content on the same file, looks pretty much the same, regardless how it is implemented.

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

#107

Post by pjmlp » Fri, Jul 19, 2019, 1:41 PM UTC

Marazan wrote: post #90

pjmlp wrote: post #73

Earlier quoted context omitted.

JSX feels like PHP and ASP all over again. Apparently they aren't that bad after all.

I hesitate to tell people. They are doing it wrong but if you write JSX like how we all wrote PHP back in the day then you are doing it wrong.

So how do you modularize content in separate files?

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

#108

Post by mattacular » Fri, Jul 19, 2019, 1:41 PM UTC

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…

Agreed! It seems as though something will eventually come along and wholesale replace the need for React, Angular, Vue et al just as jQuery did to prototype, dojo, and moo.

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

#109

Post by [deleted] » Fri, Jul 19, 2019, 2:02 PM UTC

save_ferris wrote: post #102

jasode wrote: post #80

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, Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers , I can't see how the industry will migrate back to server-side rendering in 3 years. The unavoidable technical issue is the round-trip latency of the network. The same delays…

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…

[deleted]

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

#110

Post by dwild » Fri, Jul 19, 2019, 2:05 PM UTC

ehnto wrote: post #42

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.

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…

> We can write re-usable components in pretty much any language with as bit of file organisation.

Sure you can, but only in that specific language, which sadly your browser won't understands.

I'm working with Struts 2 at my job sadly, when I started I quickly began to make components because it's much better than the usual copy-paste they were doing.

The components are great and works well, are not so hard to make (much harder than React but still accessible) but once it's rendered, that's it. You want to add an element using JS?

Well okay, you'll just add some kind of template that you will render in the JS, even more works, but that's fine. Thing is, you don't have access to parameters... well just add it in the JS initialization easy right? No they use OGNL, thus if anything is done programmatically (which it will, for concatenation or i18n, or whatever), most likely won't works.

Most time when the component change visually, the same change need to be done on JS too. Twice the time...

In the case of Struts, the components are also quite hard to imbricate into one another, which push toward even more code smell.