
Front-end design, React, and a bridge over the great divide - kimsk112
http://bradfrost.com/blog/post/frontend-design-react-and-a-bridge-over-the-great-divide/
======
ng12
> 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
never go back to a template language, in my mind they're a fundamentally
flawed design. They necessitate introducing extra concepts and implementing
some magic rendering voodoo -- for what? So I can write my code twice, once in
the JavaScript and once in whatever weird template directive language the
framework uses.

So for me the only real alternative to JSX is to do elm-html style nested
function calls which tends to be much uglier. JSX isn't perfect but it's the
best we have by a mile.

~~~
zbentley
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.

~~~
jasode
_> 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,_

Maybe your prediction is informed by different internet usage scenarios but
_for general mainstream web surfers_ , I can't see how the industry will
migrate back to server-side rendering in 3 years.

The unavoidable technical issue is the _round-trip latency_ of the network.
The same delays from the speed-of-light will still be there in 3 years. Most
of the world is accessing the web through _mobile phones_ which has worse
latency than desktops. Server-side rendering (which means painful page
reloads) is user hostile on slow network connections.

~~~
save_ferris
You didn’t mention all of the new features coming to HTTP 2 that will
alleviate network performance issues (prefetch, multiplex connections, etc.)

I’ve found many sites that use frameworks like react to be much more user
hostile, particularly from a performance and accessibility standpoint. The
reddit redesign comes to mind. It’s so much slower now than it used to be on a
browser (perhaps they’re intentionally doing this to push people to their
mobile app), that it’s noticeably reduced the quality of the experience.

I guess I just don’t understand how people see page reloads with proper
caching as unacceptable from a performance standpoint compared some JavaScript
app maintaining a virtual DOM, which is also likely regularly communicating
with a server.

~~~
digitaltrees
Same with TechCrunch, every time I visit I am reminded how frustrating react
sites can be compared to server rendered pages with all the flicker, slow page
reveal, and odd navigation it introduced.

~~~
rhizome
Late loading artifacts is _all_ the fault of JS, not server-side rendering.
Not sure what you mean by "odd navigation."

~~~
digitaltrees
To close an article there is a x button and back swipe is disabled. I agree
that flicker is introduced by Javascript. That is what I was saying. Might be
ok for an app, but a content driven site seems like it should stick to the
concept of pages where navigation is like turning a page. Just seems like
server rendering fits that mental model better. Not sure why react even makes
sense for a blog.

~~~
ng12
It doesn't, but blogs aren't built to present content they're built to sell
advertisements and collect data. That's much easier with an SPA than a SSR
app.

~~~
rhizome
_they 're built to sell advertisements and collect data. That's much easier
with an SPA than a SSR app_

How easier? By dint of additional JS that an SSR doesn't have/need? Not sure
how pulling a header nav (or any cell/element) from a server on pageload plays
into that, but even today I've watched sites (plural) loading, pushing loaded
parts all over the page for 30sec until everything settles down. Maybe blogs
aren't _quite_ so affected by this set of popular dark- and anti-patterns, but
even so the post is almost always the last thing to load. Presumably, the
monetization and data collection takes precedence over all else.

------
tenaciousDaniel
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?

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

~~~
tenaciousDaniel
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 think that's a very very bad idea.

~~~
wolco
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..

------
lone_haxx0r
> 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 resilient CSS code
> with a focus on modularity, flexibility, compatibility, and extensibility.

> Optimizing the performance of frontend code in order to create lightweight,
> fast-loading, snappy, jank-free experiences.

I can't help but chuckle at this. I admit that _good_ frontend designers do
this, but they are extremely rare. Judging solely by the top Google results,
95% of frontend designers don't do any of this: they don't care about
accesibility, friendly experience, compatibility or anything like that.

I applaud the author for caring about these things. His website is the biggest
evidence that he does, but most designers don't do these things.

~~~
ericmcer
How many of us get to walk into green field projects or even decently
architected projects? Accessibility isn’t too hard if you build conventions
around doing it from the first commit, but adding aria tags and labels to 100s
of old files is going to be a massive undertaking that few product managers
will sign off on. I think it is less incompetence and more when it comes down
to the wire, those are the first things to get cut or ignored.

~~~
erikpukinskis
It doesn’t really matter what’s there already. If your job this week is to add
a new feature, spend some time this week thinking about accessibility. If
you’re just fixing something old, then don’t worry about it.

I’m not even going to be prescriptive about how much time. If you have 5
minutes, fine, good.

------
throwaway8879
The last time I did a bit of frontend for a side project was in 2004. Then I
took a long break from dev and computers in general. Earlier this year I'd
decided to brush up on the whole frontend/JS ecosystem. It was weird initially
and there was a lot of friction, as I was especially fixated with a "why can't
I stick this in a <script> tag, what even is NPM..." mindset.

I have the say, after getting the hang of typescript, react, Vue and the
tooling in general, I don't exactly hate it as much as I was led to believe I
would. Also, typescript is very nice.

~~~
nexuist
I continue to believe that the loudest perpetrators of JavaScript hate are
those who overcomplicate simple things or follow other people's advice to
overcomplicate simple things. Things like using SPAs for five page sites,
throwing Redux into every CRA installation, npm installing useless packages
like is-odd or leftpad (lol), etc.

You don't need to use <new framework on reddit>! You don't need JSX! You don't
need <CSS alternative>! Surely you still don't need to support <version of IE
released in 1997>!? Vanilla JS is fine! Most modern browsers have rich enough
feature sets that you don't even need transpilers like babel or dozens of
polyfills (or Webpack, which almost nobody needs unless you're averaging 10M+
views a month...)

Or maybe you do, or think you do. Maybe your bosses made these choices in the
past. Maybe you had to compromise in a team. In which case, I get it. You call
the shots or you're working for someone who does.

But don't blame the language, the frameworks, or the ecosystem. JavaScript
stepped up to the plate because _nobody else did._ Electron is there because
nothing else could provide the same level of power for total novices to come
in and make groundbreaking applications. Node is there because nothing else
let you hire a guy who could handle literally every single aspect of your
business's digital presence, from front end sites to internal employee portals
to mobile apps to APIs to vendor integrations. And there's so much stuff on
NPM because everyone who works in this space for a few years always gets a
brilliant idea for some abstraction that could fix everyone's lives. Many
people who make packages on NPM have only a few months experience _programming
in general_ , which is why (1) we have so many dumb problems that
"professional" software organizations avoid and (2) there are so many new
frameworks all the damn time.

And that's a good thing! The whole point of our field has been to make
computers more helpful to humans. A dumb little language like JavaScript (or
Python if that's your cup of tea) is the perfect candidate to take any normal
person and get them working on critical business problems, whether those
require web dev skills or data science or anything in between.

For most of computer history, the role of today's pioneers has always been to
offer up their shoulders for the pioneers of tomorrow to stand on. I'm sure
bare metal logic electricians made fun of COBOL developers when it first came
out, and COBOL developers made fun of C developers, and C developers made fun
of Java developers, and Java developers made fun of Python
developers...JavaScript is neatly filling the need for a "stepping stone"
language that gives everyone the power to build their own applications, as
opposed to using someone else's application which previously cemented the wall
between "users" and "developers."

I'm excited to unleash a world where _everyone_ has the power and know-how to
develop their own applications, social networks, data processing services,
etc. It sure beats a world where only an elite few have the power to
manipulate society and capitalism to such a large degree.

-

Full disclosure: I'm currently writing a web service back end for my small
business in Racket, so I'm not just a JS developer. However, I have 4+ years
of Node experience professionally and recreationally, having built
Express/React/Mongo web apps, Electron desktop apps, and React Native mobile
apps, so I've experienced most of the ecosystem at this point I think. It's
really not that bad.

~~~
corebit
But seriously why can’t I just do modern webdev with a <script src=“”>?

~~~
recursive
Wait, is there some other way to load scripts now? Asking for a friend...

~~~
arethuza
I suspect what corebit means is loading a script that has been manually
created rather than a file that contains resources bundled by webpack or
similar.

------
jypepin
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.

~~~
ehnto
For me, it's not that I'm overwhelmed by the learning. I understand the "what"
and "how" just fine. But React is a paradigm shift that I have yet to fully
grok the "Why" for. It often feels like I'm having to re-solve problems we've
had solutions to for a decade, on top of all the brand new problems React
introduces. The core problem React solves, "re-usable reactive components",
just doesn't come to fruition in most projects I have seen. It mostly ends up
in a greenfields component stew.

We can write re-usable components in pretty much any language with as bit of
file organisation. So React takes a whole heap of convolution and tooling to
end up in pretty much the same place as before, just written differently.

Don't get me wrong though, I have enjoyed learning it and it is very cool
technology, and I'm still open to having that "aha" moment when I finally get
why people think it's great. It just hasn't hit me yet.

~~~
dmix
What about the whole component based approached? You could certainly take a
component based approach with simple code organization in HTML, CSS, and JS
frontends. I've done that before, in a sort of pseduo-web components way using
directories and naming schemes.

React and Vue makes it easier with single file components and wrapping it in
functions which makes handling state and configuration. Which increases
reusability and helps further encapsulate the components.

One of the most obvious gains to me is helping manage huge CSS files in legacy
projects [1]. Components are way better than a giant BEM'd [2] CSS file, it's
much nicer writing .box in a <style scoped /> in Twitter.vue instead of
.twitter__layoutBox among a ton of other nested layers. All just to avoid
global clashes and maintain some sanity.

Or a ton of global jQuery plugins for select boxes and modals and everything
else.

Everything is so much more portable across projects.

That's not even mentioning the whole plug-and-play reactivity that is baked
in.

[1] Here's a good list of the problems of CSS-in-JS helps solve:
[https://i.imgur.com/LbE1kqc.png](https://i.imgur.com/LbE1kqc.png)

[2] [http://getbem.com/](http://getbem.com/)

~~~
WA
> _React and Vue makes it easier with single file components and wrapping it
> in functions which makes handling state and configuration_

But is this really true? If you have simple presentational components, this is
probably true. But your app is tied together by "container components". The
state is unique to the app you're writing. You have to somehow map the state
to the components. Maybe you use "container components". In one project, you
use Redux, in another, you drill props down to all children. In the next,
there's React Context or whatever the next thing is. Do components load their
own data (like some widgets) or is there a root component that loads all data
and handles the state for the entire app?

I'd argue writing presentational components isn't that different from writing
just HTML and CSS. The tough parts of React is where all the unique state
logic is placed.

~~~
dmix
It's true Redux/VueX creates a habit of coupling your components to the
specific usecase. But I've been using them for over a year now and whenever
I've had to reuse a component, often in very different environments, it takes
about an hour of tweaking to make the component reusable. Sometimes you have
to rewrite parts of the DOM to make it more flexible.

But this is like any abstraction in programming. When you have a function you
want to be reusable you usually have to do some work to make it more portable
across your codebase and create a proper flexible "interface" for it via
arguments.

The UI components are particularily easy to reuse. If you look at something
like Rebass it uses predefined constants to add consistency of values across
the entire site + a theming system which simply tweaks those constants (ie,
colors, the scales of font sizes across h1-h6, etc).

[https://rebassjs.org](https://rebassjs.org)

~~~
pierreyoda
On your last point, I feel like components this basic should really rather be
addressed at the real theming level, i.e. in CSS.

Utility-first CSS frameworks are awesome if you get past your first
impression. I've been using TailwindCSS [0] both at work and for all my
personal projects ever since I read Adam Wathan's justification on it [1]. In
TailwindCSS those constants are configured in one place and generated at build
time (through Rollup/Webpack/PostCSS etc.). Consistency and theming for free
basically.

Even Bootstrap has now a decent collection of them in v4.

[0] [https://tailwindcss.com/](https://tailwindcss.com/) [1]
[https://adamwathan.me/css-utility-classes-and-separation-
of-...](https://adamwathan.me/css-utility-classes-and-separation-of-concerns/)

------
Kaotique
In our agency a lot of our backend developers have moved their work on the
business logic side of the frontend with React, managing state and routes,
interacting with API's. While the traditional frontend developers work more on
the visual part of the frontend with styling, JSX, images, animations.

I now call them technical frontend developers and visual frontend developers
during interviews. I am not sure what terms will stick in the end.

Our senior frontenders handle both the technical and the visual part.

We have some experienced senior full-stack developers who can work on anything
from hosting, server-side code, client-side business logic in React, but they
usually stop there and let visual frontenders implement the design.

Observing our junior frontend developers I noticed it is very difficult to be
effective in both areas. You really need years of experience before you can
grasp the whole thing.

Managing state and business logic is so different from implementing a design.
It requires very different skills. I can really sympathize with traditional
visual frontender feeling overwhelmed with the whole javascript madness that
is going on. Companies who just dumped it on them because "it's frontend", are
making a huge mistake.

------
tambourine_man
I remember when I was messing with MooTools and Prototype and then I saw
jQuery. OMG, yes, I want that! So powerful, freeing and easy.

I've never felt that way since with JS.

Backbone didn't have much appeal. Angular, I knew I didn't want to touch it
with a ten foot pole. React was interesting, but usually more trouble than it
was worth. Vue feels the nicest of the bunch, but not breathtaking.

I guess what I'm saying is that, after seeing jQuery, I knew I would not use
anything else. It solved a problem so well (DOM manipulation) there was no
need to.

With recent JS frameworks, it feels like we haven't even defined or come to
agree on what the problem we are trying to solve is.

~~~
robertoandred
The problem being solved IS (manual) DOM manipulation. It's messy and error-
prone. Using React et al to generate the DOM as a clear function of state is
much better.

~~~
tambourine_man
I’m not convinced.

Again, jQuery was an easy sell. Saying manual DOM manipulation is messy… not
so much.

------
sanitycheck
Things I get from designers: 1\. Wireframes 2\. Layouts (bitmaps) 3\. Assets
(fonts, images) (4. Occasionally, interactive prototypes made with designer-
friendly tools.)

Designers already suck so badly at HTML & CSS that getting them to do any
wastes more time than it saves. They don't need to be let near any other
implementation tech either, not Android layouts, not iOS storyboards, and not
React.

Designers don't really want to do implementation either, why make them learn a
bunch of things they don't care about?

~~~
jameal
The author makes the point that "frontend designer" may not be the right
title, so perhaps "UI developer" or one of the other titles he listed is more
appropriate.

So I don't think he's talking about making designers learn implementation. The
point is that the scope of frontend development has expanded so much that it
makes sense to split responsibility between "front of the frontend" UI
responsibilities and "back of the frontend" responsibilities like managing
state, cache invalidation, routing, etc.

In any case the line between design and dev turns gray when you consider that
designers can't practically mock up designs for the web for every viewport
size, define what every micro interaction looks like, etc. There are so many
nuances to creating a great UX that it makes sense to have a class of front
end devs with those kinds of proficiencies.

------
swsieber
> 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.

There's something to be said for constraints, and easy parse-ability

I experimented with a project once that could programmatically build a DSL for
running e2e tests. The enabling factor was constrained html-like templates[0].
It would never have gotten even close to working with JSX.

[0] [https://samsieber.tech/posts/2019/06/type-
safe-e2e-testing-d...](https://samsieber.tech/posts/2019/06/type-
safe-e2e-testing-dsls-in-kotlin/)

------
patientplatypus
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.

~~~
GhostVII
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).

~~~
bromuro
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

------
externalreality
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.

~~~
Yhippa
> 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 secretly hope this becomes true. I always think back to how nearly
everything done on the frontend are essentially hacks to really sex-up a
document description language for scientists.

I think it would be really neat if we did end up building UI's in a responsive
way like you describe. It would feel more like the right tool for the right
job. But that seems so far away when I start to think about what it would take
to get there.

------
snide
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 used them for tricks like
carousels or basic AJAXy things. For example, in the Django or Smarty/PHP days
(yes, like I said, a long time at this) I just had regular old CSS/HTML with a
whole set of "filters" in whatever the templating system was. It was very,
very easy to read the docs and do |dateformats or something for example. I
could also |sort things really easy. It was just a filter. I didn't need to
learn the actual python and it already did the hard work to make sure whatever
I had WAS sortable.

When I started getting into React I was somewhat taken aback. I needed to
actually learn Javascript (for real this time) to just do basic things. I also
needed to understand very Reacty type things like how things mount. States
were fun and easy to understand, except dealing with previous states. With
states I could replace all that jquery which was mostly me just adding and
removing classes onto things anyway. That side was much better, but it took me
months to actually learn enough JS to actually understand how the "template"
format of a React component was structured. Also, EVERYTHING needed to be
imported. Want to do some basic color stuff? There's a library to import. Want
a way to truncate things? Sure, again, let's import something that works for
more than just simple string limits. Eventually you end up just writing a lot
of JS that does this without some huge dependency, but that took awhile to
learn as well. The biggest thing I missed was something like Django's template
docs. All that stuff was just built in, and I didn't need to piece it together
myself. Ultimately I think that's what makes it harder. The world of
Javascript is fractured at its core. Want to learn how to write a function?
Which version? Have fun doing a google search and getting something that is
the "right" way to do things. OK. Now it's fat arrows...etc. JS just has years
of old examples available.

Once I got past all this, it was obviously fantastic and feels like the right
way to do things. It let me realize some personal dreams by really building a
design system of shared components, not just a CSS library. Now I could take
those design skills and build out stateless components that you could piece
together like lego bricks. Engineers would then take that stuff and build to
their hearts content and I didn't have to worry so much about them abusing a
selector. I could even document things and show real variations with very
simple prop changes. All of this sounds pretty rote and is of course what
React is there for, but man did it require much, much more knowledge that what
I was doing for "frontend design" back in the sever side rendering days. To
this day I know what redux, context and hooks do, but have real difficulty
dealing with them day to day. It's beyond the rendered DOM and so far away
from what I'm looking to do as a designer who just wants to make things look
good.

I continue to think coding is invaluable for web designers and to be honest is
the only true way to hit zenith in your understanding of the medium, but I
really don't envy people starting from scratch that have React as the "easy"
way to do things if they are moving from just handing you a mock. I think it
used to be much easier to get into "coding" as a designer 10 years ago. It's
likely why I run into more and more designers that simply aren't interested in
it or think it is impossible. They work in these React houses and suddenly
have to learn a whole lot more just to do the basics.

I guess what I'm trying to say is. Hey, 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, and I've been at it now for 20 years. That's totally normal if you
still call yourself a "frontend designer" rather than "frontend engineer". I
know and work with the later all the time. They are fantastic people with a
different skillset even though we work within the same files.

Anyways, if you're a designer who hit the wall with this stuff: keep at it.
You'll get there. The great part about React is that you can start small.
Start with the React Create App and just build a widget. Don't jump into
Gatsby and suddenly have to worry about GraphQL, routing, image resizing and
all that stuff. Just build what you built in HTML, but in React. Add some
props as "variables" in your document. Move on from there. You'll get there.

I still have trouble with JavaScript and have to look up how to deal with
arrays and objects all the time. Maybe in 20 more years that part of my brain
will match what I can do on the CSS / design side. Until then, thanks to all
he engineer folks who put up with me and take on the hard stuff.

~~~
rhaksw
> 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?

~~~
snide
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.

------
fevangelou
So, if you read between the lines, React was basically built for a better
"Like" button according to Dan's blog post here: [https://overreacted.io/the-
elements-of-ui-engineering/](https://overreacted.io/the-elements-of-ui-
engineering/)

Hmm...

~~~
efdee
React was written for Instagram. Nothing to do with Facebook's Like button.

~~~
danabramov
That’s inaccurate. React originally was extracted from the Ads codebase.
(Complex forms for creating ads.)

Instagram was the first time it was used to drive the whole page (rather than
a small widget).

------
beders
"everything is a component"

That is a major misconception. In reality, that is simply not the case. (see
all those 'container' like components trying to tame underlying components and
the awful state juggling dance we are now accustomed to.)

And most JS frameworks confuse the logical structure of an app with the
'physical' structure of the DOM.

Components are in the end rendered sub-trees in the DOM. But that forces you
to lay out your app logic along these lines.

It's limiting, it's wrong and there is a very good reason why there's a C in
MVC. It stands to argue we dismissed the C part in the front-end world way too
easily.

~~~
ng12
> And most JS frameworks confuse the logical structure of an app with the
> 'physical' structure of the DOM.

Because that's what JavaScript does. How is it any different than
document.getElementById or the window event handling system?

The point is if we're going to do it we might as well do it well.

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

------
lloydatkinson
I already loved the productivity of Vue and after using React for a while it
makes me appreciate Vue even more.

I genuinely think picking React for a new project over Vue is a mistake.

------
chadlavi
Anyone else using Firefox get a big ol security warning when you try to access
brad frost's site?

~~~
helb
No, but he's got a self-signed certificate there, so you'll get that warning
when trying to access via https (the link posted to HN is just http).

