
15 years trying to make everyone separate HTML, JavaScript, CSS – and then - sidcool
https://twitter.com/thomasfuchs/status/810885087214637057
======
waffleau
This is a complaint I've heard often about React, and usually it's by someone
that's never actually tried it (myself included before I first used it). But
it's a visceral response. Until you sit down and give it a go, it's hard to
believe that _we had the separation of concerns wrong_. Separation of concerns
refers to responsibilities, not languages.

If you're building a static website, sure, you probably don't need React - the
old tools and techniques handle that use case well. But if you're building a
webapp, something with complex, dynamic client-side behaviour, it doesn't make
sense to pretend that CSS, HTML and JS aren't already heavily coupled by the
nature of what you're building. React just embraces that idea, rather than
pretending it doesn't exist.

The reality of modern apps is that JS is going to transform your HTML and CSS
at runtime, and most of the bugs you'll end up tracking down will be related
to it being transformed in ways you weren't expecting. React's component model
and declarative rendering are far more effective at addressing this problem
than any other tool I've tried.

~~~
coldtea
> _This is a complaint I 've heard often about React, and usually it's by
> someone that's never actually tried it (myself included before I first used
> it). But it's a visceral response. Until you sit down and give it a go, it's
> hard to believe that we had the separation of concerns wrong._

We didn't. And React doesn't change that either. React components are not
logic code, they are UI code, and that has always went with view concerns
(loop this times, show this button or that button depending on state, etc).

In the Desktop GUI space, where they don't have our HTML madness, do you think
their UI components are not using code? Buttons, drop-downs, etc are not
appearing by magic, they are created by code that does things like: draw a
line of x length and y color, then another perpendicular to that, etc, then
loop and draw some stripes, etc. That's the case even in Smalltalk, where MVC
was invented. That still matches with "separation of concerns" \-- which is
about not mixing your BUSINESS logic with your UI code, not about not having
code in your UI rendering.

In fact, compared to the classical way (foreach and other kinds of template
instructions embedded in template strings, from PHP's Twig to Angular) it's
even cleaner, because even though JSX looks like HTML it's actually compiled
to Javascript instructions it's not just some ad-hoc language hidden in
template tags to be interpreted at runtime.

And separation of concerns also applies to UI elements (encapsulation, re-use,
etc) something which "logic free" templates like Mustache and so also miss
(or, well, make harder -- of course if you try hard enough you can always fit
a square peg in a round hole).

~~~
tbrownaw
I've worked some with both WinForms and WPF, and so far I kinda like XAML. And
is you're not only working in the windows world, I hear there's a similar-in-
spirit JavaScript/HTML framework being used for "new hotness" style
applications. Called "electron" or something like that I think?

~~~
wildpeaks
In short, Electron is a tool for running Node scripts in a real DOM in
Chromium (so unlike PhantomJS, it can run things like WebGL).

You can also bundle it to generate distributable desktop applications (e.g.
Visual Studio Code, Atom, or the desktop Slack client).

------
throwaway2016a
Reading the comments I'm wondering if I'm the only one who noticed that this
example does NOT intermingle CSS.

This is a view component that keeps track of it's own state. It is 100%
encapsulated and by building in events and data bindings it can be composed
into more complicated applications.

It is in fact separation of concerns. This is only one concern. The UI of a
single component.

In a full React app the business logic will be in controllers and models that
don't themselves contain view/UI code.

But because an HTML like syntax was chosen to represent view hierarchy we draw
a red flag because it looks like we are mixing HTML with Javascript. But that
was only ever a red flag because HTML semantically was hypertext representing
data and relationships.

Having tried React in earnest (and yes, I know people will have counter-
anecdotes) I can say that being able to components my web application leads to
more testable code, easier delegating of workload across teams (each team
member only needs to know the interface of a component to use it), and better
code reuse. It is beautiful (albeit busy looking).

~~~
mercer
As an aside, is anyone else a a bit worried about is the massive use of
destructuring assignment and rest operators and whatnot? I see it a more in
React/Redux code than anywhere else.

I really like how it can reduce a number of tasks to less code, but it's the
most common thing that trips me up when I read React or 'ESNext' codebases. It
feels like ternary operators on steroids, with all advantages and
disadvantages magnified.

Perhaps I just need to get used to it.

~~~
dclowd9901
It's a comfort thing, for sure. I've only started writing more with
destructuring assignment recently (it's part of our code style guide at my new
company), and it's doing things like forcing me not to use a different
variable name for something that's already been defined. It's also forcing me
to do more FP (since our stylguide also forces usage of `const`), which has
actually made my code my more readable and maintainable (consistent naming,
single-responsibility in functions, etc). Once you get used to the new syntax,
it's a breeze to read and understand.

Well, once you understand a statement like this anyway:

`store => next => action => next(action);`

~~~
mercer
That's good to know. It does feel like a powerful feature that's worth
mastering.

I mean, despite the risk of making things complicated, I use ternary operators
all over the place...

------
Lazare
The thing about Fuchs is that he's a very smart guy, who is deeply embedded in
the modern JS world, and is absolutely aware of what that code is doing, why
it looks the way it does, why the trend in frameworks has moved the way it
has, just how many times the argument he's using has been advanced already,
and how thoroughly it's been trashed over the years.

He _knows_ that what he's said has been said a thousand times before, and he
_knows_ that every time it's said a bunch of people will reply with
"separation of concerns, not seperation of technology", and he _knows_ that's
a very valid counterargument which can't be refuted in a tweet, which means he
_also_ knows how pointless this is. Which in turn means that he's not doing
this to start a discussion, but just to get a rise out of people. Giving him
the benefit of the doubt, he might actually have an interesting point to add
to the debate...but we'll never know, since he thinks a better use of his time
is trolling React developers than actually making his case for...whatever it
might be.

One of the tweets in reply to him hit the nail on the head:
[https://twitter.com/chrisbarless/status/810918115601158145](https://twitter.com/chrisbarless/status/810918115601158145)

Sad.

Edit: Scroll through Fuchs' twitter feed right now; he's basically just non-
stop trolling. "This is why we can’t have nice things" "Q: What is React? A:
It’s PHP, but on the client." "I can see how react is awesome if you build
todo apps that do nothing. :)" Then when noting how a million people are
disagreeing with him: "I think that means that I’m on to something." No
attempt at dialogue, no acknowledgement that there might be alternative
viewpoints. Almost every tweet is another dollop of smug arrogance.

It must be nice to have so much confidence that you never have to stop and
wonder if there might be something new you _don 't_ yet know.

~~~
mattmanser
_how thoroughly it 's been trashed over the years_

So often a phrase like this is repeated on HN.

React only got released _3 years ago_. How could it be "trashed over the
years"? Over what years? It barely qualifies for the plural.

I seriously wonder sometimes if javascript programmers live in dog years.

React apps haven't been in production long, we're only just entering the
maintenance phase, _now_ is exactly when we will start seeing the problems
with mingling code + UI as the code gets forgotten, opened again, modified,
added to and bloats.

~~~
Lazare
> React only got released 3 years ago. How could it be "trashed over the
> years"? Over what years? It barely qualifies for the plural.

Yes. Three years. Plural. This has been debated for three years; that's why I
said "years". Are you suggesting I should have said some other time period?

> we're only just entering the maintenance phase

Yes, I am maintaining some React code; some of it has been in maintenance mode
for almost two years now. I also maintain some Backbone code, some jQuery
spaghetti, a couple of Knockout projects, and an enormous MVC-ish PHP app;
I've got a pretty good grip on the various ways people have written web apps
over the last few years and what maintaining them is like.

> now is exactly when we will start seeing the problems with mingling code +
> UI

No, because there are no problems with mingling "code" and "UI" so long as all
of it is _presentational_. What's critical is ensuring separation of concerns,
which you fail to do when you mix business logic with the presentational
logic.

Saying "it's all javascript so it must be related!" is how you end up with
unmaintainable Backbone code. (And to be fair, you can do that with React too,
but that's got nothing to do with what the screenshot was decrying. And it's
actually _harder_ to screw it up with React than Backbone, in my experience,
and I have experienced both.)

Keep in mind: Many of the people who disagree with you have many, many years
of experience and a deep understanding of software engineering principles and
what does and does not lead to maintainable code. That doesn't mean React/JSX
is perfect, but it does mean that you aren't going to get very far with snide
comments. The obvious criticism of JSX is that separation of concerns is
important, and the obvious defense is that JSX enables very effective
separation of concerns. And that criticism and defense were first made, yes,
years ago. Any further progress needs new arguments.

Ninja edit: And yes, I too have written original ASP code, and worked on
"DHTML" sites, and wrote hideous inline JS to try and make rollovers work in
IE6, and tried to reverse engineer the broken JS that MS Frontpage
automatically injected into the pages it creates, and a bunch more besides. I
too know the urge to yell at people to get off my lawn. Just because it's new
doesn't mean it's always wrong though...

~~~
mattmanser
You very well know that "Over the years" doesn't mean "in the last year or 2".

I'm merely observing that neophiliac programmers tend to massively over-
exaggerate how long things have been around. And how much experience they have
in that tech.

------
flukus
It is amazing how much react resembles php and classic asp from 15 years ago.
I guess that's what happens when you don't hire anyone over 30.

~~~
quasse
This was exactly my thought, and it's not like I'm even that old. We should
know better by now. I went from writing PHP in high school that looked exactly
like this, to using Python CGI and then finally Flask to write (I think) very
modular, maintainable web applications.

Now several years later I'm inheriting Nodejs and [flavor of the month]
Javascript framework projects from coworkers that look like the PHP video
sharing site I wrote in 10th grade using XAMPP.

I feel like I have (or everyone else has) contracted some sort of amnesia.
Didn't we already hash this out guys?

~~~
throwaway2016a
While old school PHP might look like this it is not the same thing by far. The
code in this screenshot is a stateful component and is supposed to encapsulate
all the logic on how it should be displayed in one place.

It is close to a view in a MVC framework than true old-school spagetti code.

But unlike a view component in an MVC framework the stateful components can
update themselves automatically when data changes much more elegantly than
they could in older systems.

Granted some people write React and include business logic in their components
but you're not really supposed to do it that way.

~~~
aantix
Curious on your take; for a component, why do I need the virtual dom diffing?

If I'm working on a component level, it's already granular enough where I can
easily understand the changes that need to be made and I can just update those
DOM elements myself (e.g. Oh, I should add this class here and update my
shopping cart total).

The DOM diffing for small components seems so... heavy handed. "Don't worry
React, I got this.."

~~~
slowrabbit
ReactJS is currently the fastest, most scalable frontend solution available so
compared to all that has come before it, it can seem heavy handed. But if you
want to build highly scalable apps like Facebook, Instagram, Pinterest, Reddit
and Twitter mobile, then losing easy speed gains with every one of the
hundreds to thousands of components you build is unacceptable.

~~~
neilellis
The problem is that 99.99% of developers aren't (writing Twitter etc) but they
still apply techniques used by unicorns to handle their own very exceptional
needs.

We should always be wary of applying skyscraper building techniques when
building a house or a shed.

I honestly bet that 99.99% of people who read Hacker News could write their
applications with a drop of jQuery and some basic ES6 code.

I have nothing bad to say about these frameworks, more caution that we don't
apply techniques needed at scale to small scale products.

------
dclowd9901
What this image doesn't show: Refactor safety.

When I can include my CSS as modules into my components (which, by the way, is
still separated, only now it's completely isolated from demonic CSS side-
effects), and when I can TEST my HTML (read that again: TEST my HTML, again,
easily separatable meaningfully by utilizing a pure-function mechanism), and
when I can use something like Flowtype to identify structures in my code
DESPITE the type limitations of Javascript, and when I can do it performantly
and brainlessly _EVEN IN_ the slapdash "platform" of The Browser (TM), yes,
this is a _huge_ step forward. Don't blame the people who decided to do
something about the shittiness of Tim Berners-Lee's overly-verbose and
unmaintainable HyperText Markup Language for a solution that doesn't look as
pretty as Python.

~~~
paulddraper
> shittiness of Tim Berners-Lee's overly-verbose and unmaintainable HyperText
> Markup Language

A bit too strong.

Imagine Markdown becomes wildly popular and the majority of the Internet's
content is now available in Markdown.

As more content becomes available, we expand Markdown to include forms to get
bidirectional communication.

There are some layouts and styles that can't be done in markdown, so we add
stylesheets. Can't exactly write them in Markdown, so we have to come up with
a new language.

Then people want to form validation or augment the UI in more dynamic ways,
because hey, this is _the_ platform. So we add a turning-complete language.
Can't be Markdown of course, so we make a scripting-language for Markdown.

\---

HTML wasn't made for flappy bird; it was made for text markup. But
practicality beats purity over and over and eventually people want to use the
super-compatible browser platform with easy distribution model for everything.

No one sinned; we just wound up here through a lot of inventions, accidents,
and opportunities.

~~~
jazoom
We're all geniuses when we have 30 years of retrospect.

~~~
j1o1h1n
Only if you take the time to look back

------
Jetrel
I think the big thing most people miss is that whilst separation-of-concerns
is a great idea, trying to make the division line happen between our styles
and our logic was a really bad idea, historically. We're much better off
having the "dividing lines" be between different UI components and different
segments of an application.

If I have some really weird custom CSS for some component on a site, I'd much
rather have said CSS be embedded in the code for that one odd component - and
scope-limited so it doesn't affect anything else (at my workplace we've got a
common practice where any sass we write is usually scoped to only ever affect
children of specific dom classes, and we use this to make sure it affects "its
own kind of component, and never anything else".

I've been through the hell of having totally segregated CSS, and trying to
hunt down where "that one weird styling rule" is coming from is a real mess.

There's also the fact that very often CSS really _has to_ be data driven; if
I'm doing a bar chart on some page and I'm using rectangular divs to represent
the individual chart series, the only way I know of to set their height,
client-side, is via javascript. React is quite nice because I can guarantee
the presence of required dom elements for something like this, and even
restructure them on the fly, and have a number of guarantees about avoiding
race conditions, which I don't get via something like jQuery.

~~~
paulddraper
It was fine when the UI was basically simple enough to be one or two
components.

Having 40 different independent "components" is relatively recent, and shows
the weakness of the old separation.

~~~
flukus
> Having 40 different independent "components" is relatively recent, and shows
> the weakness of the old separation.

Maybe on the web, but we've been creating desktop (and console) applications
just as complicated as any web app for a long time, that's where the
importance of separation of concerns was first learned.

~~~
tracker1
Yes, but where do you separate these concerns... Do you put view rendering and
raising events in separate files? From my own experience in reviewing other
people's code, it depends, but usually no. I mean, you can use MVC as
separation pattern, but there's also MVVM and many other patterns that place
the walls in different places.

I'm pretty happy with how React/Redux works compared to what came before...
separating file structure by directories of features, and
components/actions/reducers that represent them is much easier than looking in
one spot for all my view templates with a goofy DSL abstraction, and another
directory for the actual event binding.

------
bschwindHN
I kind of want to show him this code to upset him more. I think React is
great, especially when using it through ClojureScript.

    
    
      (defn todo-list []
        (let [todos (atom [])
              text (atom "")
              add-todo #(do
                          (swap! todos conj @text)
                          (reset! text ""))]
          (fn []
            [:form {:on-submit add-todo
                    :action "javascript:"}
             [:input {:type "text"
                      :value @text
                      :on-change #(reset! text (.-target.value %))}]
             [:button {:type "submit"} "Add"]
             [:ul
              (for [todo @todos]
                ^{:key todo} [:li (str todo "!")])]])))

~~~
throwaw12ay
It's great that you don't need Clojurescript or even JSX to do that. You can
write plain ES5 and get the same result. And it would stay readable for most.

------
JTenerife
The images of the 2000 line long JS and CSS monoliths didn't fit into a tweet.
:-)

Seperation should be by the responsibilities a component, not by language. So
the trend to components in frontend dev is right despite some unfamiliar
mangling of html and js.

~~~
throwaway2016a
> Seperation should be by the responsibilities a component, not by language.

Very well said! I'm quoting this one.

------
geetee
Separation of concern or technology? A well structured React application is
much easier to understand than something where you need to keep 3 files in
your mind at once.

~~~
rimantas
It used to be a separation of conterns. HTML for structure, CSS for
presentation, JS for some bells and whistles. Now, when everyone forgot what
the web was about and see it just and app platform that does not really apply.

------
msimpson
Thomas Fuchs is a troll. He has posted before on the alleged complexities of
React. Yet, he has never posted a coherent argument against the view
framework. Even this attempt was thwarted by Blake Newman:

[https://twitter.com/blakenewman/status/811142762368221184](https://twitter.com/blakenewman/status/811142762368221184)

However, Thomas had nothing to say in response. He only patted himself, and
others, on the back both before and after that tweet as he continues to ignore
any retort to his claims.

Oh. And if you're wondering why he's mad, consider that he's the author of
Zepto.js. That jQuery compatible drop-in library that essentially no one uses
as jQuery is hardly relevant anymore. But that's fine, he's busy with his own
business: Slash7 LLC.

[http://slash7.com/company/](http://slash7.com/company/)

Where the overwhelming majority of his client work links are dead and his
biggest triumph seems to be an early 2000's era JavaScript animation library
on par with Scriptaculous. In fact, the website is even a rip off:

[http://scripty2.com/](http://scripty2.com/) vs.
[http://script.aculo.us/](http://script.aculo.us/)

Even his own site uses the same type of vanity domain:

[http://mir.aculo.us/](http://mir.aculo.us/)

Sad ...

~~~
antoniuschan99
I don't know who he is but he is with Amy Hoy who I heard of and she runs some
businesses online. She's popular enough that I think they are doing well
enough with their SaaS businesses.

~~~
msimpson
Well, given her partner, we can be sure none of their products use React.

------
sametmax
We are still separating HTML/JS/CSS.

React widget logic is on their own methods, PUB/SUB logic is in flux. Template
logic is in one isolated method in JSX. CSS is not in there.

Yes, the widget logic and template are in the same files, but the code is
strongly separated.

React encourage to group related CSS/JS/HTML together, to make a stand alone
component. Yet CSS/JS/HTML are distinct in the component. I think it's a nice
solution.

------
Kiro
The whole separating HTML, JS & CSS has never felt right to me. Just because
it's in different files doesn't mean it's not entangled. Moving to self-
contained components without any external dependencies has completely changed
the way I code web.

------
nojvek
I've been using preact with tsx and inline styles. Every component Is a es6
module that declares it's imports and exports. I have a theme.ts containing my
theme variables. There are watchable models. Only views contain tsx and css as
js. Views import a controller and mediate events to them. Controllers know
nothing about the view and they are the only ones that can modify the model.

My application contains a single index.html with entry point to my js bundle,
empty body tag and no css.

Everything is loaded as needed, encapsulated as modules. The simplicity is
just amazing .

The way I think about it is react like thinking offers me the most semantic
compression in my code.

~~~
mercer
I tried getting Preact to work with webpack and TypeScript, but I ran into
issues with aliasing (which AFAIK isn't possible in TypeScript). How did you
solve this issue?

(I use webpack because it now supports tree-shaking)

------
fergie
Separation of concerns == totally valid

However, "Separation of concerns" doesn't always mean the separation of
programming languages. Its completely reasonable to have one file that
concerns itself with one thing, yet is comprised of different languages.

Bash programmers know this to be true.

------
carsongross
Inlining styles and lots of javascript looks pretty awful to me, but I don't
mind binding actions directly to the UI elements they are associated with, so
long as it is declarative (like anchor tags and forms do already)

Now, have I told you all about intercooler.js...

~~~
mercer
[http://i.imgur.com/QmrvkOl.png](http://i.imgur.com/QmrvkOl.png)

;-)

------
pmontra
We're building desktop applications with HTML now even when we're using them
inside a web site. I'm not surprised that programming patterns start looking
like the ones of desktop applications. It has been 10 years since I did one,
not counting a couple of small Android apps 5 years ago. I remember UI widgets
instantiated in a Java file, not much different from what I saw in this post.
The next step could be a Visual Basic like UI designer to arrange widgets.
Flexbox would help there. Remember that development for the desktop is a kind
of solved problem with some will defined tools. JavaScript, HTML, CSS will get
there too.

------
hoodoof
Why would an integrated component not include it's logic plus presentation?
Putting logic here and presentation there immediately leads to the need for a
mechanism to ensure that this version of the presentation is matched with that
version of the logic.

The real objection seems to be "I'm smart and I don't like it", not some
considered explanation of what the inherent reason is to separate logic and
presentation.

The wider context is that these components are typically built within an
organised class structure enabled by ES2015, and operate within an organised
component lifecycle as defined by react. Integration of logic with
presentation and code into a single component makes a great deal of sense to
me - all I hear are haters griping from the sidelines about how it looks like
PHP.

~~~
flukus
> Why would an integrated component not include it's logic plus presentation?

Typically this makes it hard to test the logic. That's the big reason why
logic and presentation were separated in the first place.

> Putting logic here and presentation there immediately leads to the need for
> a mechanism to ensure that this version of the presentation is matched with
> that version of the logic.

In the past this was handled by compilers and tests.

~~~
Chris_Newton
_Typically this makes it hard to test the logic._

Why?

You have your underlying data model, and any associated constraints and
business logic built around that data. This can be tested using whatever tools
you normally like to use.

Independent of that, you have how you want to render some or all of that data
in some particular way, which is the part React handles. There are tools for
testing this as well, though in practice I rarely use them as I don’t like to
have any complicated logic at this level in my design anyway.

If you do need to do some non-trivial work to get from the underlying data to
the processed data that is used for rendering — perhaps selecting the top five
items from a set by some criteria, or combining some conditions to see whether
a control should be enabled or disabled — you can build an intermediate layer
that sits between the underlying raw data and the rendering logic. Again, this
is a typical architecture for large-scale UIs that has nothing specifically to
do with React, and again, the code can be tested with your preferred tools.

In short, contrary to the tweet, we _aren’t_ actually writing code like that
in real projects built using React.

------
insin
If you're curious where this came from, it's actually a Preact component
(props and state being passed to render() is the tell-tale sign), taken from
its homepage: [https://preactjs.com/](https://preactjs.com/)

------
eindbaas
Classic knee-jerk reaction to JSX.

------
k__
haha, I read this too.

And I thought so too.

I'm using React for 1 1/2 years now and I have to admit it has its pitfalls
but co-locating templates and code really made things easier.

The only problems I had was when I tried to push props too far down (== not
co-locating) because then my components relied on each other too much.

But most of the time the top of the file is controller code and the bottom
(render method) is view code.

Often I just use props for IDs or push "full data" into tightly coupled
components (list items in a list etc.)

If a component is responsible for all its data, it can be moved around freely,
which often saved me many hours.

I think React has its problems, but THIS is none of them.

------
vbezhenar
Separating makes sense for websites with gradual improvement. You can disable
JavaScript and have usable website. You can disable CSS and have usable
website. Some features won't be available, it might be not that pretty, but
it'll function.

Now with web applications it's not necessary makes sense to separate some
concerns. Functionality, design, markup — it's all glued together, like it or
not. Remove CSS and there won't be anything but bunch of pointless divs.
Remove JavaScript and it'll be just a garbage.

------
kaoD
That doesn't look like React, render() takes what looks like props and state.
Is this a similar framework to React, or just poorly-written React?

~~~
insin
It's Preact, the screenshotted code is from the Preact homepage.

------
pacomerh
I think he's oversimplifying by assuming separation of html, css, js is 'The
way to go'. It's a way, not the way. Building views by composing functions is
actually really interesting and should not be discarded that quickly. He would
probably die if he looked how you build interfaces with OM.

------
LeanderK
Don't take this too seriously (CSS is still separated), it's not important to
separate html and Javascript, but to separate something. You can choose your
own abstractions and how you organise the code-base to make it maintainable
and simple. There is not absolute right/wrong.

------
Tade0
Fun Fun Function did a great talk about this:
[https://www.youtube.com/watch?v=0ZNIQOO2sfA](https://www.youtube.com/watch?v=0ZNIQOO2sfA)

Although in my personal opinion JSX got it wrong. Vue on the other hand
handles this problem great.

------
jasoncchild
I mean, you don't _have_ to use JSX...

...but I agree with many of these comments; I thought it was odd (to be
charitable) but after using it find it to be quite nice. Redux is what I see
over used (imo) and at times almost an antipattern

------
jcoffland
React is popular because of Facebook just like Angular was popular because of
Google. Both are bad ideas. Why programmers insist on running off a cliff
every few years like a bunch of lemmings, I don't know.

~~~
pas
Why do you think they are bad ideas?

~~~
sanbor
IMHO Angular is a bad idea because you're doing rendering in the client side.
Maybe your building an HTML5 image editor or something that requires client
rendering. But most CRUD apps doesn't really need client side rendering. There
is also a hype of SPA (single page apps) which is usually harder to implement
than server-rendered apps. It is harder because you have to avoid the browser
refreshing the page and keeping the state in the browser AND syncing with the
server. If you do server side rendering you don't have to sync client and
server with JS.

Many people said that it was ok to render the view using JS in the client, but
often they start having performance issues. Not just the performance, but
introducing changes in Angular apps wasn't easy for me because there are lots
of things going on. I don't have a lot of experience in Angular but the few
code that I hacked it was hard to introduce changes because it's hard to
follow the flow of changes in the code.

React may be good if you really want to have an SPA and you can afford it. But
the complexity introduced by it may not be worth it in many projects where
they'd be fine with just HTML/JS/CSS and server rendering.

~~~
pas
What do you mean doing rendering on the client side?

The browser does the rendering anyway. Or do you mean assembling the HTML to
be rendered?

Single Page Apps are very good. GMail is possible because you don't have to
reload the whole page and the images every time you click.

It's the "autocomplete" on steroids turned to 11. And it's much easier to
implement, because you have state on the client side, and you can implement a
simple REST API, which is much easier than maintaining sessions on the backend
and implementing a thousand /?q=<method> endpoints. (And can be consumed
easily by other clients.)

And these frontend frameworks solve the "browser refreshing" thing for you.

Introducing changes to Angular 1 apps was a bit hard, yes. But compared to the
previous jQuery hell, I think the structure that the evil Angular cult forced
on people was worth it. And TypeScript and ES6 modules are finally making
those things pleasant.

------
kriro
The abstraction chosen by React makes a lot of sense to how my brain works. If
one is bothered by the mixture of HTML/JS/CSS(where in the example?) there's
always code generation.

------
hitchhiker999
My dirty little coding secret: After decades of coding, I think MVC isn't
appropriate for all websites!!! The horror. M(V&C) is my dirty secret.

------
Nekorosu
This is a typical Thomas Fuchs trolling. It shouldn't be taken serious. You
won't get any constructive arguments from him anyway.

------
Nekorosu
It's hard to acknowledge for OOP crowd they've got the separation of concerns
the wrong way.

------
sova
Sounds like we need a fundamentally different approach to UI...

------
wineisfine
imagine this without syntax highlighting.

~~~
victoray
yeah, you're right!

------
sparkie
"15 years building linear web pages when we should've been building
applications"

------
eagsalazar2
The linked tweet is nothing but a troll and everyone fell for it. I seriously
don't understand why people want to hate on js so hard where they just
contrive trite and inaccurate one-liners like this.

~~~
flukus
This is about react more than js specifically. There are plenty of javascript
templating libraries that offer better separation between presentation and
logic.

------
ClayFerguson
In my 15 years I've come to realize that HTML code-generation via JavaScript
(or now TypeScript actually) is vastly superior to any type of templating
(like JSP, JSF, Velocity, Mustache). Both ways (templating v.s. straight
generation) have exactly one sort of 'level of indirection' so they are on the
same order of complexity, but generating HTML rather than templating it is a
billion times more powerful, so it is just better.

To prove my point: Here's the code for the Audio Player in meta64.

[https://github.com/Clay-
Ferguson/meta64/blob/master/src/main...](https://github.com/Clay-
Ferguson/meta64/blob/master/src/main/resources/public/ts/dlg/AudioPlayerDlg.ts)

No one can possibly argue that an HTML template for that would be easier to
read, than the TypeScript I've written. I think the way meta64 uses Polymer,
TypeScript, generated-HTML, etc is the ideal architecture for the modern app.

BTW: I just picked a random example of my generated code from meta64. I do
agree the CSS embedded in that would be better as a CSS class. I am not
arguing for dynamically created CSS, but only dynamically created HTML (i.e.
no templates). My point was that if you have clean code, you can make your
HTML-code-generation look almost like the HTML itself, or be 'as readable' as
it would be if it were an HTML template. Readability is the key here. That's
all that counts. If you can achieve that in JS/TS then it beats a template
approach easy, because of its power in terms of OOP, reuse, etc, which
templates are just awkward with.

~~~
Already__Taken
What is 'build = (): string => {' ?

Or specifically ():, I know arrow functions.

~~~
scottmf
Looks like build is the function and it returns a string.

I think without the typing it would just be build = () => {

~~~
Already__Taken

        var build = function(){...} //return a string
    

Rather than some other commenters, and I would have thought given arrow
functions;

    
    
        var build = function(string){...}

~~~
scottmf
I don't understand what you're trying to say?

------
williamle8300
I wonder if he's tried using it yet. Thomas Fuchs is an important figure in
the JS community but he can't sit on his laurels and not provide constructive
criticism.

------
andrew_wc_brown
MithrilJS is better. Don't know why people bother with ReactJS.

~~~
jsguy
Whilst I agree, Mithril is also a very different beast - it includes a routing
system, and full MVC - React is just a view component library.

------
GrumpyNl
For me, old school programmer, we are almost back from where we started. Keep
it simple and keep yous shit seperated. You dont really need oops, you dont
really need react. Dont pretend you have 15M visitors on a page and it has to
be optimized for that.

