Live data from Hacker News

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

bradfrost.com

21–30 of 137 posts

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

#21

> 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…

The problem is that anyone can pick up design and web dev and get up and running fairly quickly, but very few intro tutorials even touch accessibility or get into it. Therefore beginners easily wind up doing things like using links or divs instead of buttons because buttons look bad by default, instead of overriding button css.

And then usually you pile up thousands of kludges before someone blows a whistle and says “Hey, none of this is accessible!”, and then you look back at a mountain of inaccessible garbage you wrote and claim it’s too hard.

So long as design and webdev are learned informally, this will always be an issue. Especially because unless you yourself need the assistance of accessibility software, it’s not obvious that things are broken, because they look good.

As an aside, I also feel like this is because webdev and design are taken less seriously by the world of programming. My college offered only one course on webdev and it mostly involved teaching PHP and jQuery. So no one takes it seriously and then they half-ass learning it.

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

#22
post #5

I'm a "font-end designer". I've been one for since 2000 or so. To me, that basically meant I was a designer that could write HTML and CSS. At some point Sass was thrown into the stack and things became really awesome. I did this for very big companies and even my own startups that I sold. Before React came around I wrote and used some mootools/prototype/jQuery, but very frankly didn't really know JavaScript and just…

> I work at a big company with a great team doing what most people would consider high-level React work that is used by at least hundreds of engineers. But most days if I'm honest I struggle with it too

> The great part about React is that you can start small. Start with the React Create App and just build a widget

Great points! Your whole comment is worth reading.

PS. I had no idea Elastic open sources its internal React UI components. Interesting. (found this via your HN profile). Should I be using this if I want to provide an interface to an API that exposes an Elastic Search DB?

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

#23

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 develop your app. Now in the long run, for a large app, those tools are useful since they make it easier to actually host your website somewhere, but the learning curve is far steeper than just opening up index.html in your web browser.

Also it is hard to determine what the best way to solve a problem in React is when there are so many different versions and additional packages people are using (ex. Redux).

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

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

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.

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

#25
post #5

I'm a "font-end designer". I've been one for since 2000 or so. To me, that basically meant I was a designer that could write HTML and CSS. At some point Sass was thrown into the stack and things became really awesome. I did this for very big companies and even my own startups that I sold. Before React came around I wrote and used some mootools/prototype/jQuery, but very frankly didn't really know JavaScript and just…

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

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

#26
post #5

I'm a "font-end designer". I've been one for since 2000 or so. To me, that basically meant I was a designer that could write HTML and CSS. At some point Sass was thrown into the stack and things became really awesome. I did this for very big companies and even my own startups that I sold. Before React came around I wrote and used some mootools/prototype/jQuery, but very frankly didn't really know JavaScript and just…

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.

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

#27
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 totally get the preference for the JSX approach. Also echoing other commenters, CLJS/reagent and similar tools did a pretty amazing job of this some years ago.

But I think it is wise to consider that there are advantages and trade-offs to a compiled template approach as used by Angular, Svelte, and probably some others I’m forgetting.

* potentially more concise syntax

* potentially more familiar syntax

* do more of the work at compile time, less of it at runtime in downloaded code

* avoid the GC pressure and other overhead of VDOM

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

#28
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.

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

#30
post #28
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.

Sapper & Next.js support server side rendering.
Post reply on HN