7 ms·

Using component-based design helps us build faster

62 points by stablemap 7y ago

Liron 7y ago
Of course, another example of how React is the software engineering paradigm shift of this decade. Comparable to last decade's shift from desktop to web apps. Interesting that React is fundamentally an invention at the level of programming language design, an insight about how to best express UI behavior. This means we could have had it (or any mainstream functional reactive programming) much earlier or later than we did. It came on the scene at an arbitrary unpredictable time.
- deleted 7y ago
  [deleted]
- jabbernotty 7y ago
  I find it amazing how many different software development frameworks are out there. After all these years I still haven't bothered to look up what React is, and I probably will never need to. I will probably never get to maintain a codebase that uses it. So if being 'up-to-date' isn't something I will go for, how do I measure myself as a developer? I think I will go for something like 'having made a lot more regular people happy than I have frustrated'.
  - revskill 7y ago
    You should try and use React first before deciding if it's actually helpful for you later. In case of React, to me, i no longer bother with syncing state with html, something like `node.innerHTML = `${my_state}` It's actually beneficial to me.
    - skohan 7y ago
      Yeah I spent some time with raw javascript, jQuery and angular, but React is the first web framework which actually feels like a decent solution to the problem of how to build interactive web applications, rather than just being another hack.
    - pferde 7y ago
      That sounds like something horrible that one never should have needed to bother with in the first place. Like saying that with this new car, I no longer bother checking whether the wheels aren't about to fall off. :)
  - qwerty1234599 7y ago
    Probably around half of frontend developer jobs I see nowadays are for projects using react; and that number keeps going up. If you do any web development at all, chances are you will have to work in a React codebase during the next decade
    - pjmlp 7y ago
      Not when one works at an agency that happens to bet on other stacks.
  - jabbernotty 7y ago
    I don't understand why this is being downvoted. There is no negativity in the message.
- jillesvangurp 7y ago
  I don't know. It reads to me like they are rediscovering what e.g. Visual Basic and Delphi did in the nineties: UI component libraries. Particularly VB used to have a pretty lively component ecosystem. Also, the web is littered with attempts to have reusable javascript components for things like menus, combo boxes, and other cruft people end up wanting in their web sites. This article reads a bit like a blast from the past in that sense. I think if I dig a little I might be able to dig out some papers from the sixties and seventies advertising the virtues of functions, modules, and even components with very similar language as in this article. There is some progress here of course. Internalizing CSS is a good thing. Having that as a separate thing to manage and align is just too painful to keep in a maintainable state. I think some people are still disagreeing with this but I've seen some examples of css increasingly being driven from javascript instead of shipping as a separately loaded and created artifact. Web components sort of formalize this in html/javascript and allow you to isolate components from each other, which is another good thing. Separation of concerns and isolation are good things. Also good is the shift to typescript, a language with a bit stricter semantics than javascript and of course better typing. The article does not mention this but given the speed and confidence with which they did this, I suspect they'd be pretty happy Typescript users. Other than that, I think React is mostly a variation of the same kinds of design patterns that have dominated UI development for the past decades. I did some Swing development in the nineties and I still think that was a pretty nice framework to deal with relative to the current madness that is modern web development. The web can still learn a few new tricks. I have good hopes for WASM bringing some more choice and options to the scene.
  - pjmlp 7y ago
    I believe that once WASM matures a little bit more we will get that tooling back, alongside Flash's revenge.
    - jillesvangurp 7y ago
      Sure, you can use it for good and for evil. I expect this as well. Sadly, there seem to be a few annoying limitations that browser makers seem to be stuck on for the immediate future (e.g. garbage collection, simd, threads, and a few other things). Still, wasm is good enough for pretty sophisticated stuff. I was playing a version of doom 3 ported to wasm a few days ago; with decent frames per second even and quite playable: https://news.ycombinator.com/item?id=18817278 https://news.ycombinator.com/item?id=18817278
pjmlp 7y ago
Also known as, Web development keeps re-discovering 90's best practices of native GUI development.
- edejong 7y ago
  More like 70's best practices [1]. Reusable GUI components were first (? citation needed) used on the Alto machine developed in 1974. The developments of the Xerox PARC team were a huge inspiration to Steve Jobs, who later would create Objective-C and the NeXT system (with NeXTSTEP as the component based GUI) in the late 80s. > Those who cannot remember the past are condemned to repeat it. To covet truth is a very distinguished passion. -- George Santayana [1] https://www.classic-computing.de/wp-content/uploads/2016/01/A_History_of_the_GUI.pdf https://www.classic-computing.de/wp-content/uploads/2016/01/...
  - granshaw 7y ago
    And the cycle keeps going back and forth, on and on...
    - edejong 7y ago
      Well, I think (and many of my fellow engineers as well), that we were making good progress in UI design and abstractions until AJAX and the modern web came about. I've said this before and I will say it again: the web has brought modern software development practices back in time by at least 20 years. Everything had to be reinvented: usability, interaction patterns, accessibility, quality control, component-based GUI design, supportability and so much more. And in many ways we have gone backwards. Interaction patterns vary wildly from site to site. Most don't have undo/redo functionality. A failure of one component often means a failure of the whole. Accessibility on the web is terribly poor for the vision impaired. Interaction response time has gone up, not down even though our machines have many orders of magnitude more power than the 90's. Most websites cannot be properly maintained due to lack of coding standards and abidance of best-practices. Ok, just an old fart rant. Don't get me wrong: I think we have made leaps of progress when it comes to distributed computing, machine learning and mobile application development. The web, however, has turned into a huge dumpster fire.
pedro1976 7y ago
Worth mentioning Brad Frost with his wonderful formalized approach for componetized UIs, called Atomic Design [0] [0] https://bradfrost.com/blog/post/atomic-web-design/ https://bradfrost.com/blog/post/atomic-web-design/
- chrismorgan 7y ago
  Go for http://bradfrost.com/blog/post/atomic-web-design/ http://bradfrost.com/blog/post/atomic-web-design/ instead. His site over HTTPS uses a self-signed certificate that expired over eight years ago.
zubairq 7y ago
At yazz.com we are actually building something which allows web apps to be built from Visual Basic style components, but with Javascript instead, and designed to be deployed to containers
pavlov 7y ago
> "...at one point, the button component’s API had become highly customizable to a fault. Developers could specify the label color, background color, and border color independently, which made for a very large set of possible button looks. One of our principles is to make opinionated components that support visual consistency so in this case we opted to distill those three options into a single choice, a type field that only allows choosing from a predefined set of valid button appearances." This reminds me of buttons in macOS vs. iOS. Mac's UI component library AppKit was inherited from NeXT and redesigned for the OS X "Aqua" look in 2000 with incremental updates ever since. It had a very limited set of button styles, with each style having a specific use case. Customizing a button's appearance used to mean creating a subclass and doing your own vector drawing. When iOS came on the Cocoa scene, it introduced a new component library called UIKit. It supported more flexible customization similar to that described in the Twitter blog post (freely selectable colors for everything as easily applied properties). The downside of UIKit's customizability was the propagation of absolutely hideous third party UIs that broke every rule of visual accessibility and Apple's own Human Interface Guidelines. So Apple tried to rein it in with the "flat" iOS 7 redesign in 2013. Even though the redesign was quite unpopular in tech circles, it ultimately succeeded in unifying the look of iOS apps compared to the '90s style pandemonium that reigned before. When iOS developers try to make Mac app in AppKit, it seems 99% of the time their first complaint is: "Why is it so hard to customize a button?" The answer is that there is great value in UI consistency, as Twitter also discovered. It's more important on the desktop than on mobile simply because there are multiple apps visible at once on the Mac, and it sucks if each of them defines its own crazy branded look.
tsss 7y ago
What the hell, so web developers were somehow reinventing basic UI elements like buttons at every use site? How is that even feasible? Making reusable self-contained UI widgets is a menial task that can be solved by just throwing more money at the problem. We could pump out hundreds of widgets every week if we wanted to. The hard part is coming up with a way to easily compose them and share state, not just on one level but widgets that are composed of other widgets that are again composed of other widgets.

62 points by stablemap 7y ago

Of course, another example of how React is the software engineering paradigm shift of this decade. Comparable to last decade's shift from desktop to web apps. Interesting that React is fundamentally an invention at the level of programming language design, an insight about how to best express UI behavior. This means we could have had it (or any mainstream functional reactive programming) much earlier or later than we did. It came on the scene at an arbitrary unpredictable time.

deleted 7y ago
[deleted]
jabbernotty 7y ago
I find it amazing how many different software development frameworks are out there. After all these years I still haven't bothered to look up what React is, and I probably will never need to. I will probably never get to maintain a codebase that uses it. So if being 'up-to-date' isn't something I will go for, how do I measure myself as a developer? I think I will go for something like 'having made a lot more regular people happy than I have frustrated'.
- revskill 7y ago
  You should try and use React first before deciding if it's actually helpful for you later. In case of React, to me, i no longer bother with syncing state with html, something like `node.innerHTML = `${my_state}` It's actually beneficial to me.
  - skohan 7y ago
    Yeah I spent some time with raw javascript, jQuery and angular, but React is the first web framework which actually feels like a decent solution to the problem of how to build interactive web applications, rather than just being another hack.
  - pferde 7y ago
    That sounds like something horrible that one never should have needed to bother with in the first place. Like saying that with this new car, I no longer bother checking whether the wheels aren't about to fall off. :)
- qwerty1234599 7y ago
  Probably around half of frontend developer jobs I see nowadays are for projects using react; and that number keeps going up. If you do any web development at all, chances are you will have to work in a React codebase during the next decade
  - pjmlp 7y ago
    Not when one works at an agency that happens to bet on other stacks.
- jabbernotty 7y ago
  I don't understand why this is being downvoted. There is no negativity in the message.
jillesvangurp 7y ago
I don't know. It reads to me like they are rediscovering what e.g. Visual Basic and Delphi did in the nineties: UI component libraries. Particularly VB used to have a pretty lively component ecosystem. Also, the web is littered with attempts to have reusable javascript components for things like menus, combo boxes, and other cruft people end up wanting in their web sites. This article reads a bit like a blast from the past in that sense. I think if I dig a little I might be able to dig out some papers from the sixties and seventies advertising the virtues of functions, modules, and even components with very similar language as in this article. There is some progress here of course. Internalizing CSS is a good thing. Having that as a separate thing to manage and align is just too painful to keep in a maintainable state. I think some people are still disagreeing with this but I've seen some examples of css increasingly being driven from javascript instead of shipping as a separately loaded and created artifact. Web components sort of formalize this in html/javascript and allow you to isolate components from each other, which is another good thing. Separation of concerns and isolation are good things. Also good is the shift to typescript, a language with a bit stricter semantics than javascript and of course better typing. The article does not mention this but given the speed and confidence with which they did this, I suspect they'd be pretty happy Typescript users. Other than that, I think React is mostly a variation of the same kinds of design patterns that have dominated UI development for the past decades. I did some Swing development in the nineties and I still think that was a pretty nice framework to deal with relative to the current madness that is modern web development. The web can still learn a few new tricks. I have good hopes for WASM bringing some more choice and options to the scene.
- pjmlp 7y ago
  I believe that once WASM matures a little bit more we will get that tooling back, alongside Flash's revenge.
  - jillesvangurp 7y ago
    Sure, you can use it for good and for evil. I expect this as well. Sadly, there seem to be a few annoying limitations that browser makers seem to be stuck on for the immediate future (e.g. garbage collection, simd, threads, and a few other things). Still, wasm is good enough for pretty sophisticated stuff. I was playing a version of doom 3 ported to wasm a few days ago; with decent frames per second even and quite playable: https://news.ycombinator.com/item?id=18817278 https://news.ycombinator.com/item?id=18817278

pjmlp 7y ago

Also known as, Web development keeps re-discovering 90's best practices of native GUI development.

edejong 7y ago
More like 70's best practices [1]. Reusable GUI components were first (? citation needed) used on the Alto machine developed in 1974. The developments of the Xerox PARC team were a huge inspiration to Steve Jobs, who later would create Objective-C and the NeXT system (with NeXTSTEP as the component based GUI) in the late 80s. > Those who cannot remember the past are condemned to repeat it. To covet truth is a very distinguished passion. -- George Santayana [1] https://www.classic-computing.de/wp-content/uploads/2016/01/A_History_of_the_GUI.pdf https://www.classic-computing.de/wp-content/uploads/2016/01/...
- granshaw 7y ago
  And the cycle keeps going back and forth, on and on...
  - edejong 7y ago
    Well, I think (and many of my fellow engineers as well), that we were making good progress in UI design and abstractions until AJAX and the modern web came about. I've said this before and I will say it again: the web has brought modern software development practices back in time by at least 20 years. Everything had to be reinvented: usability, interaction patterns, accessibility, quality control, component-based GUI design, supportability and so much more. And in many ways we have gone backwards. Interaction patterns vary wildly from site to site. Most don't have undo/redo functionality. A failure of one component often means a failure of the whole. Accessibility on the web is terribly poor for the vision impaired. Interaction response time has gone up, not down even though our machines have many orders of magnitude more power than the 90's. Most websites cannot be properly maintained due to lack of coding standards and abidance of best-practices. Ok, just an old fart rant. Don't get me wrong: I think we have made leaps of progress when it comes to distributed computing, machine learning and mobile application development. The web, however, has turned into a huge dumpster fire.

pedro1976 7y ago

Worth mentioning Brad Frost with his wonderful formalized approach for componetized UIs, called Atomic Design [0] [0] https://bradfrost.com/blog/post/atomic-web-design/ https://bradfrost.com/blog/post/atomic-web-design/

chrismorgan 7y ago
Go for http://bradfrost.com/blog/post/atomic-web-design/ http://bradfrost.com/blog/post/atomic-web-design/ instead. His site over HTTPS uses a self-signed certificate that expired over eight years ago.

zubairq 7y ago

At yazz.com we are actually building something which allows web apps to be built from Visual Basic style components, but with Javascript instead, and designed to be deployed to containers

pavlov 7y ago

> "...at one point, the button component’s API had become highly customizable to a fault. Developers could specify the label color, background color, and border color independently, which made for a very large set of possible button looks. One of our principles is to make opinionated components that support visual consistency so in this case we opted to distill those three options into a single choice, a type field that only allows choosing from a predefined set of valid button appearances." This reminds me of buttons in macOS vs. iOS. Mac's UI component library AppKit was inherited from NeXT and redesigned for the OS X "Aqua" look in 2000 with incremental updates ever since. It had a very limited set of button styles, with each style having a specific use case. Customizing a button's appearance used to mean creating a subclass and doing your own vector drawing. When iOS came on the Cocoa scene, it introduced a new component library called UIKit. It supported more flexible customization similar to that described in the Twitter blog post (freely selectable colors for everything as easily applied properties). The downside of UIKit's customizability was the propagation of absolutely hideous third party UIs that broke every rule of visual accessibility and Apple's own Human Interface Guidelines. So Apple tried to rein it in with the "flat" iOS 7 redesign in 2013. Even though the redesign was quite unpopular in tech circles, it ultimately succeeded in unifying the look of iOS apps compared to the '90s style pandemonium that reigned before. When iOS developers try to make Mac app in AppKit, it seems 99% of the time their first complaint is: "Why is it so hard to customize a button?" The answer is that there is great value in UI consistency, as Twitter also discovered. It's more important on the desktop than on mobile simply because there are multiple apps visible at once on the Mac, and it sucks if each of them defines its own crazy branded look.

tsss 7y ago

What the hell, so web developers were somehow reinventing basic UI elements like buttons at every use site? How is that even feasible? Making reusable self-contained UI widgets is a menial task that can be solved by just throwing more money at the problem. We could pump out hundreds of widgets every week if we wanted to. The hard part is coming up with a way to easily compose them and share state, not just on one level but widgets that are composed of other widgets that are again composed of other widgets.