The Elements of UI Engineering • Hacker News Board

Re: The Elements of UI Engineering

#51

Post by Daynil » Mon, Dec 31, 2018, 4:42 PM UTC

austincheney wrote: post #31

thenanyu wrote: post #6

Much thanks to Dan for taking the time to write this up. UI dev is a deep and highly technical field, but we’re often inundated with juniorish programmers because it’s often the entry point for folks coming out of school or boot camps. We need folks writing more about these kinds of principles and less about a new way to reinvent the wheel

Absolutely. https://en.wikipedia.org/wiki/Invented_here The name of the game is failure aversion. Frameworks and NPM packages for everything. When I interview JavaScript or UI developers this is my first discriminator. Why write original code or reinvent the wheel when somebody else has your simple solution behind 50mb of external code that you didn't write? If you are that fearful coward who believes in not writing…

It's important to understand the root of the arguments for and against both "not invented here" and "invented here". Both can be considered a poor mindset because it's thinking in absolutes. Certainly, everyone can agree there is no need to "write original code" for every problem you encounter. If there are libraries behind which there are teams of strong engineers (React, Angular), who work specifically on that problem and exhaustively test and iterate on it, why would you take time and productivity away from the development of your product in order to create your own solutions?

On the other hand, if the existing libraries/solutions don't fit your use cases and you spend more time customizing them to work than you do developing your product, or the existing solutions are out of date, unsupported, or appear slapped together, it would certainly be worth working on your own solution to see if you can find a better way. Likewise, experimenting with custom reimplementation is a great way to understand the problems libraries solve in an in-depth way, as Dan suggests, and you may even end up with something better. You just need to be realistic about whether it makes sense to make it yourself or utilize what exists.

Re: The Elements of UI Engineering

#52

Post by austincheney » Mon, Dec 31, 2018, 4:45 PM UTC

0xCMP wrote: post #45

austincheney wrote: post #31

Earlier quoted context omitted.

Absolutely. https://en.wikipedia.org/wiki/Invented_here The name of the game is failure aversion. Frameworks and NPM packages for everything. When I interview JavaScript or UI developers this is my first discriminator. Why write original code or reinvent the wheel when somebody else has your simple solution behind 50mb of external code that you didn't write? If you are that fearful coward who believes in not writing…

You're being toxic by calling people "cowards" for simply using a package instead of writing it themselves which reduces the amount of code they need to directly maintain. Displays a complete misunderstanding of the tradeoffs involved as well as being rude. And what's funny is that if you hadn't been a jerk the original point of Frameworks and NPM Packages for everything is a good point and probably would have been w…

Thank you for having the balls to respond.

I could have tap danced around that by using a bunch of words like: demonstrating a proportional degree of insecurity to the depth of requirements presented across the breadth of considerations required by this responsibility. I found the word coward to be more honest and fitting, though. Ultimately, the rampant insecurity isn't a technology problem. It is a personality consideration.

> And what's funny is that if you hadn't been a jerk the original point...

People on the internet tend to have big tears and thin skin. I don't like lying to people because they have sensitivity issues. I would rather take the down votes. All these few down votes from a few shattered JavaScript developer hearts are instantly wiped clean when I get 80 up votes for posting a single comment about analysis or interviewing. Being honest and transparent has always helped me in the offline real world.

Re: The Elements of UI Engineering

#53

Post by gedy » Mon, Dec 31, 2018, 4:59 PM UTC

pdrummond wrote: post #33

I've been building UI for years now and all these points highlighted by Dan are spot on. Great post! I've been thinking lately about the "design system" trend that is becoming more and more popular where companies want more control over styling and behaviour to make their UX unique to their brand as well as consistent across all their products. Ready-made 3rd party components like the excellent react-select don't rea…

That's a great point and something I've seen dealing with multiple look and feels at a single company. While not quite as far as what you suggest, we've had good success building components with no custom CSS at all and instead use Bootstrap classes exclusively. This allows a lot of freedom for the design system to look at it needs, but encapsulates the "hard parts" as you list. We've struggled with react-select as well, but were able to mostly specify various props to use Bootstrap classes. Not a sexy approach, but it works.

Re: The Elements of UI Engineering

#54

Post by c-smile » Mon, Dec 31, 2018, 5:06 PM UTC

Vinnl wrote: post #19

nenadg wrote: post #16

Entropy. Good point. I don't think many brought up that issue, it's either ignored (we know what we're doing) or coped with when it's too late (we knew what we're doing). Entropy handling should be the goal for 2019 UI/Frontend engineering.

I think the reduction of the cognitive load of entropy was what propelled React (and specifically its innovation of the Virtual DOM) to be the most widely-used front-end framework. Being able to write a function transforming state to a description of the view, without having to worry about getting from whatever the view currently looks like to what you want it to look like, is a huge advantage. It can certainly still…

> innovation of the Virtual DOM

Virtual DOM is rather a desperate move - to support components life time constructor/destructor events componentWill/DidMount / Unmount.

What if you will be able to define in standard HTML/CSS something like this (as it is supported natively in Sciter)

   // css
   div.mycomponent {
     behavior: MyComponent url(components.js);
   } 
   // script in components.js
   class MyComponent : Element {
     function attached() { /*constructor*/ }
     function detached() { /*destructor*/ }
     … other custom component specific methods … 
   }

With that simple mechanism you don't need virtual DOM and its overhead at all. Component binding requires only inclusion of that CSS.

Re: The Elements of UI Engineering

#55

Post by ggpsv » Mon, Dec 31, 2018, 5:15 PM UTC

miguelrochefort wrote: post #38

danabramov wrote: post #27

Earlier quoted context omitted.

What do you make of route transition animations?

There's no reason for route transition to be a special case of state transition. Here are some examples of state transitions that can be augmented with animations: - reorder items in a lost - add/remove an item from a list - expand/collapse an element - hover/press/disable a button - show a popup - show an inline error message - open a drop down menu - open/close a burger menu - change the burger menu button to a bac…

Interesting! Are there any resources or books that you might share that delve into this kind of reasoning towards UI engineering?

Re: The Elements of UI Engineering

#56

Post by [deleted] » Mon, Dec 31, 2018, 5:35 PM UTC

austincheney wrote: post #31

thenanyu wrote: post #6

Much thanks to Dan for taking the time to write this up. UI dev is a deep and highly technical field, but we’re often inundated with juniorish programmers because it’s often the entry point for folks coming out of school or boot camps. We need folks writing more about these kinds of principles and less about a new way to reinvent the wheel

Absolutely. https://en.wikipedia.org/wiki/Invented_here The name of the game is failure aversion. Frameworks and NPM packages for everything. When I interview JavaScript or UI developers this is my first discriminator. Why write original code or reinvent the wheel when somebody else has your simple solution behind 50mb of external code that you didn't write? If you are that fearful coward who believes in not writing…

[deleted]

Re: The Elements of UI Engineering

#57

Post by pdrummond » Mon, Dec 31, 2018, 5:47 PM UTC

danabramov wrote: post #35

pdrummond wrote: post #33

I've been building UI for years now and all these points highlighted by Dan are spot on. Great post! I've been thinking lately about the "design system" trend that is becoming more and more popular where companies want more control over styling and behaviour to make their UX unique to their brand as well as consistent across all their products. Ready-made 3rd party components like the excellent react-select don't rea…

That's exactly how some of the newer libraries in React ecosystem work btw. For example, Downshift is that "DYI Autocomplete" — it handles a11y and mechanics but you can compose any kind of behavior and styling out of its primitives. https://github.com/paypal/downshift I'm glad to see this trend.

I've used Downshift before and while I like the idea, what I am suggesting is broader in scope. A set of primitives such as Overlay, Rectangle, Circle, List, Row, Column, etc that still allow you to apply styling but overall they sit at a lower level of abstraction than ready-made components, even ones based on something like Downshift.

The more I think about this the more I feel like I'm describing exactly how "Qt Quick"[1] works, the declarative user interface markup language that is part of the Qt Framework. Of course, it's not a web technology but it would be interesting to see a web-based framework/lib based around some (if not all) of the ideas found in QML.

[1] http://doc.qt.io/qt-5/qml-tutorial1.html

Re: The Elements of UI Engineering

#58

Post by joshtynjala » Mon, Dec 31, 2018, 6:49 PM UTC

djKianoosh wrote: post #29

2Pacalypse- wrote: post #28

Earlier quoted context omitted.

Would love to hear your thoughts as well on this! Especially with regards to remembering scroll position between route navigations in an infinite scroll component that fetches its content asynchronously.

i've thought about this some.. seems to me the url/hash route needs to tell us both the app state and UI state, but most routers dont do this

You can save arbitrary data when you push a new state with the HTML history API. This data is restored when you go back, and it does not affect the URL. Both React Router and Reach Router allow you to programmatically navigate and use this capability. I've used it on multiple occasions to restore both app state and UI state when navigating back. It's a little more work, of course. You can't just link to a simple URL. You need an event listener that creates the state object and tells the router to navigate manually. You may also need to ensure that any back buttons in your UI actually go back into the history instead of adding a new entry. It would be nice if it were easier, but once you get it working, the level of polish compared to most web apps makes it feel worth the effort.

Re: The Elements of UI Engineering

#59

Post by nyadesu » Mon, Dec 31, 2018, 7:14 PM UTC

Is there any book that actually cover those problems from a technical view point? Not from a UX/designer perspective

Re: The Elements of UI Engineering

#60

Post by nojvek » Mon, Dec 31, 2018, 8:30 PM UTC

ehnto wrote: post #20

mwcampbell wrote: post #3

From the part on accessibility: > But we also need to make it easy for product developers to do the right thing. What can we do to make accessibility a default rather than an afterthought? Yes! We accessibility advocates have been wishing for this for decades. In the context of web development, application developers should rarely, if ever, have to reach for the ARIA role attribute, because they should be able to re-…

I have had this in mind for years but never followed through with it. Do you know of any groups currently working on the problem? The dream is framework agnostic Web Components that "just work" in a modern browser. You can make it happen with a bit of polyfill javascript. My worry has been spending a bunch of effort making them and then having to maintain separate sets for all the different frontend "web component-is…

Framework agnostic is hard because building a complex UI toolkit always needs some underlying way of binding model control logic and rendering together.

So if you don’t end up using a modern popular framework, you have already invented one that is undocumented.