Live data from Hacker News

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

bradfrost.com

31–40 of 137 posts

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

#31
I think HTML is bad. I think DOM based development is bad. I really feel that Desktop UI development is much more mature and has much less legacy to compete with when developing a web UI.

I think the very near future will be web assembly code that paints a canvas. Mature desktop methods with GUI design tools will be ported to web assembler and retrofit for the web. QT5, imgui, are just the beginning.

I think a good exercise would be to open the Full Stack React book again and port the first few running examples to a Qt Quick Controls application and then target webassembler. I am willing to wager that anyone who gives it a real shot will be impressed at the productivity gains -- which generally stem from QML's expressiveness and not having to deal with React's over-complicated design. Not to mention, you'll not waste time because some component you made behaves differently across browsers. You'll also notice a complete lack of the dogma that tends accompany modern JS frameworks and libraries.

It also feels good to know that your UI may be a bit more performant that DOM based UI's.

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

#32
post #24

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.

Not really - and that's why I like it. I like JSX too.

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

#33
post #24

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 difference is that in the cljs version you are writing clojure at all times using clojure data structures and types (vector, map, keyword, string) which lets you manipulate and generate things easily, and, you don't have to jump between "jsx" mode and "JS" mode.

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

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

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

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

So what alternatives?

I don't want to program iOS and Android and web.

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

#36
post #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…

It's Apache 2. You can use it for anything though we do road-map against our own uses of course (mostly Kibana). There's nothing specifically tied to ES in it. The only difference with our library vs. someone else is we tend to have to deal with things like data density, form layouts and visualizations more often than other folks.

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

#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" React makes things, or how "easy" layout now is with CSS Grid. It takes serious time and effort to develop these skills.

So I ask myself, why would a designer do this? It's one thing to have domain-specific knowledge (iOS design is _very_ different from web, for example). It's another to have implementation-specific knowledge, which IMO a designer really doesn't need.

This is great and all for Netflix's web designers, but what about iOS, Android, Apple TV, Playstation, Xbox, Roku, etc etc etc?

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

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

I've always found it odd that many React devs just keep doubling down and insisting it is much better and that it would be a disaster doing it any other way with "magic" templating systems or anything closer to html/css.

Having done some significant work in vue and React and meteor, and played with a whole bunch of others, it is mostly about preference. React has a nice dev orietented mental model. As a true blooded programmer, none of them are that hard to work with once you get past their inital learning curves. I've generally swung towards to keeping things as close to HTML / CSS as much as possible to keep it realtively understandable for most any web "designer" ( so mostly I pick vue, though playing with svelte and that seems promising )

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

#40

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

Hell, a good portion front-end developers don't even care about those things.
Post reply on HN