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

51–60 of 137 posts

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

#51

Post by magicnubs »

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.

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

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

#52

Post by kangoo1707 »

ng12 wrote: post #45
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 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).

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

#53

Post by tuesdayrain »

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 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 example, it's almost always clearly restricted to either HTML, JS, or CSS. And I really appreciate how Vue minimizes the amount of code I need to search through in those situations.

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

#54

Post by wolco »

tenaciousDaniel wrote: post #46
baddox wrote: post #44

Earlier quoted context omitted.

I thought Netflix was pretty notable for using React Native or something similar in most or all of its native apps.

Perhaps. I don't know anything about how Netflix does their design. But the underlying point was that implementation details change, technologies change, and it's hard enough to keep up with the changes while you're focused solely on development. I'm not opposed to individual designers learning how to code, but my fear is that the industry will come to an expectation that designers should be able to build UI's. I thi…

The expectation is already there. I feel sorry for designers who simply worked in html who's lives keep getting more difficult. At one point you drew in photoshop/sliced then you had bootstrap which would give you a base but you needed to override styles.

JSX makes a lot of sense for those writing components but makes little sense for a designer to be forced to think in that way. Using vue with html templates allows designers to copy and paste html.. it's not that easy with jsx..

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

#55

Post by bromuro »

GhostVII wrote: post #23
patientplatypus wrote: post #14

This feels so foreign to me. Just...use React? JSX syntax isn't hard : Like if it was Haskell or something I would be understanding, but this just sounds like lazy.

I don't think it is the syntax that is difficult, it is the overall layout and design of a React app, and the tools that come along with it. When you start a website with regular HTML/CSS/JavaScript, you just open up index.html and start putting in HTML tags, and maybe add a .css or .js file. When you start a React app, you (usually) run create-react-app, which pulls in a million dependencies and tools you use to dev…

Please don’t stop creating your website n the way you need it. It worked 15 years ago and it still does.

Then, start have your codebase grow and grow, and you will find yourself to rebuild it again and again. Good luck

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

#56

Post by sooheon »

kangoo1707 wrote: post #52
ng12 wrote: 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).

Isn't that use case just to save time on initial load? An SPA with SSR for load times is different from a webapp structured to have logic mostly in the server.

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

#57

Post by sooheon »

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.

Also the CLJS you see is using the vectors and hashmaps of the language, meaning much more direct manipulation the same way you'd program any other datastructure.

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

#58

Post by onion2k »

dahfizz wrote: post #28
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…

Server side rendering has one big advantage - it's fast. Client side rendering frameworks may be easier and sexier, but serving html is always going to be faster.

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 the fastest method of getting something to display in the user's browser, so perceptually it's much faster to serve a static html file and then hydrate it with any custom data using frontend JS.

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

#59

Post by davidjnelson »

GhostVII wrote: post #23
patientplatypus wrote: post #14

This feels so foreign to me. Just...use React? JSX syntax isn't hard : Like if it was Haskell or something I would be understanding, but this just sounds like lazy.

I don't think it is the syntax that is difficult, it is the overall layout and design of a React app, and the tools that come along with it. When you start a website with regular HTML/CSS/JavaScript, you just open up index.html and start putting in HTML tags, and maybe add a .css or .js file. When you start a React app, you (usually) run create-react-app, which pulls in a million dependencies and tools you use to dev…

Building a complex user interface requires an incredible amount of experience in software architecture to do well.

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

#60

Post by lacampbell »

The deeper I get into front end javascript the more I think Vanilla JS is the way to go. As it stands I am just using preact for rendering jsx, I am not using anything for state management or routing. I might as well hardcode most of my html, write some functions that target a few small areas of the dom, and some code triggered by 'onhashchange' that hides all but a single div so I can still be SPA.

I'm not really worried about this causing spaghetti code because, well... I know how to program. I've always been mystified that salvation from bad architecture comes from frameworks.

Post reply on HN