17 ms·

15 years trying to make everyone separate HTML, JavaScript, CSS – and then

254 points by sidcool 10y ago

flukus 10y ago
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.
- noonespecial 10y ago
  The same thing lures people in every time. You sit down, open a single file and type for 5 minutes and you've got a baby web app. Whee! The pain comes later. So much pain. Its like the payday loan of technical debt.
  - iEchoic 10y ago
    Where does the debt come in?
  - Nekorosu 10y ago
    Except it's quite the opposite in case of React.
- quasse 10y ago
  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?
  - SomeStupidPoint 10y ago
    Ah, you think technical design is governed by technical concerns. It's fashion, like anything else.
    - quasse 10y ago
      I've been lucky enough in the general case to either be in charge of system design or have very thoughtful coworkers who are well aware of the burden of technical debt. Unfortunately I can't babysit every other team and have occasionally inherited some real abominations. Often times it has been worth spending the ~week in man hours to immediately rewrite them to avoid the constant time suck of maintaining spaghetti code down the line. Often they are a kernel of simple functionality buried in thousands of lines of code smeared across a random assortment of files that can actually be replaced fairly simply once you've sussed out what they're actually supposed to be doing.
      - deleted 10y ago
        [deleted]
  - throwaway2016a 10y ago
    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 10y ago
      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.."
      - Chris_Newton 10y ago
        (I’m not the person you replied to, but I’ll offer some thoughts anyway.) for a component, why do I need the virtual dom diffing? React allows you to build relatively large and complicated DOM trees by composing smaller components, and it is designed so you can then (re)render the entire tree as a single operation when any relevant underlying state changes, without having to manage (re)rendering each individual component within that tree manually. This is useful because now you only need to define one absolute way to render from a given set of underlying data. You no longer need to give a relative specification for all possible transitions from one state to another, which can be a huge reduction in complexity and edge cases if you’re working on a large, complicated UI. However, other things being equal, rerendering your entire DOM tree on the slightest change in the underlying data would become painfully slow for any system that isn’t very small. That is partly because there are costs to regenerating the DOM tree itself, as with any template-based system. However, the tightest bottleneck in today’s browsers is usually the consequential costs that result from updating the DOM in terms of regenerating layout and so on. The virtual DOM diffing is essentially a performance optimisation that lets you mitigate those consequential costs, because now only the parts of the DOM that actually change as a result of changes in the underlying data will lead to rerendering in the browser and the costs that incurs. In other words, virtual DOM diffing isn’t the point of React, declarative/absolute rendering is, but the former is what makes the latter fast enough to be viable. As an aside, React’s answer to the other half of the performance problem, the cost of regenerating the entire DOM tree, is the `shouldComponentUpdate` function. That lets components, including child components deep within a large tree, perform any quick tests they can to determine whether their rendered output will actually change, and to skip the rerendering if not. That leads on to various other ideas that have become popular in connection with React, such as using immutable data models for the underlying data. With immutable underlying data, a shallow comparison between a couple of object references that can be performed in moments acts as a “dirty check”. However, you don’t have to use React in that way. Some people are wary of relying too much on `shouldComponentUpdate`, which inherently violates the “single source of truth” principle and risks introducing bugs if its assumptions differ from those of the same component’s `render` method. Others find the arguments for building your entire data store around immutable objects, which itself carries a hefty performance overhead, less compelling. There are certainly other reasonable architectures you could choose for supplying the underlying data to React components and triggering rerendering when that data changes, including more traditional designs where view components observe the underlying data model in some way and trigger their own rerendering on any relevant change. Going down this path is effectively using React as a reasonably efficient and composable template rendering engine, so you can still have the advantages of absolute rendering logic, and you bypass some of the potential performance problems caused by doing large-scale rerenders with React, but in return you take back some of the responsibility to set up explicit dependencies between your view components and the data they depend on. As ever, there are trade-offs, and usually there will be multiple quite different designs that will do a decent job as long as you understand their pros and cons.
  - TeMPOraL 10y ago
    > I feel like I have (or everyone else has) contracted some sort of amnesia. Didn't we already hash this out guys? Maybe we're backtracking on the idiocy we started on around PHP times? The whole "separation of concerns" thing that went to such extremes as to become a cargo cult? I offer two observations: - presentation is often very much content at the same time (that's why websites end up cluttered with divs that have no semantic meaning and serve no other purpose than being CSS hooks) - separation of concerns was about not putting business code in views, not about having views without any code; you need code to drive views (and yes, template languages are Turing-complete, so they count as code too)
- kul_ 10y ago
  Agreed. Take the example of people hating XML and trying to reinvent everything good XML already had with JSON and JSON Schema. http://json-schema.org/ http://json-schema.org/
  - tracker1 10y ago
    My biggest peeve with XML is there's no concrete way to represent a piece of XML in code, it's in my opinion TOO flexible. You can express something as an attribute, a child, multiple children of the same element, a value of a child, etc. It doesn't translate cleanly to any kind of object structure in terms of code. And it goes in reverse too. Now, there are standards like SOAP, etc... In the end, JSON and some clear docs for an API is usually easier to reason with than any of the boatloads of cruft that came along with XML. Not to mention the much larger transmission size.
    - kul_ 10y ago
      I am not sure if you had chance to play with JAXB, it maps xml very cleanly to java objects. I mean you can have the whole darn thing define inheritance and it would generate the corresponding relation in Objects too. IMO It just needs to be given some consideration before rejecting as old bloated piece of crap.
    - tannhaeuser 10y ago
      That's because originally SGML/HTML/XML attributes were for (mostly) presentational details, but this role was shifted to CSS. The resulting combination does indeed look arbitrary, especially with CSS's total lack of mental discipline (but let's not be too harsh here). In judging whether something should be represented as element text or as attribute, ask yourself whether that something is content or metadata. In a context where this distinction doesn't make sense, markup (SGML, XML, HTML) probably doesn't make sense either. Markup isn't and never was intended for representing arbitrary data - it is for representing text with optional markup, and is designed for end-users and content authors, not necessarily web developers. As for representing XML in code, there was E4X which allowed you to represent XML literals in Javascript (Firefox and rhino had it a couple years ago, but it kindof wasn't convincing). Keep in mind that Javascript was invented as a language to manipulate a DOM in the first place, so there you have your canonical representation of markup in Javascript.
- Chris_Newton 10y ago
  I guess that's what happens when you don't hire anyone over 30. Writing as someone comfortably over 30, I don’t see the problem here (edit: meaning having something that looks like HTML and something that looks like JS in the same place). If you need to generate content dynamically for a web page based on some underlying business logic and data, you need some sort of rendering logic that determines how to fill in the blanks in your generic pattern using your current specific information. This has been true for every template system and framework since forever. Personally, I don’t much like putting the logic right there in the JSX, as the `map` does in the tweeted example. I think one of the nicer things about the way React and JSX work is that you do have the full power of JS to write your rendering logic, and you can build up a part of the rendered output separately and then compose the overall output from the individual parts without needing to put a lot of extra logic in there. But that’s just my personal preference, and others might reasonably disagree. The challenges with building larger applications in PHP — or in JavaScript, for that matter — have more often been about not having good tools in the language to build cleanly separated, modular designs. That side of things has improved somewhat with time, and will probably always be less than ideal because of the legacy baggage these languages now carry, but in any case the big problems were never really about an artificial separation of HTML, CSS and JS, and including JSX within JS code when using React is little different to embedding conditional logic in any other template language used by any other programming language or library.
- hoodoof 10y ago
  This is a really smarmy and ignorant comment - if you tell me that you are an experienced react programmer and therefore understand what you are looking at, then I'll reconsider, but as it stands, your comment is just ignorant.
  - flukus 10y ago
    Why react specifically? My general experience tells me that mixing presentation and logic ends badly, as well as the collective experience of the industry. We've been down this path with just about every GUI technology before but it seems we have to learn it again.
    - Chris_Newton 10y ago
      Why react specifically? My general experience tells me that mixing presentation and logic ends badly If you’re talking about the `todos` list in the tweeted example, I’m afraid you’ve been successfully trolled. In non-toy code, you’d typically hold the underlying state in a separate part of your system rather than the rendering React component, as with any other sanely designed UI. That data would be passed into the React component via `props` so it knew what to render, and the callback function to handle a form submission would also be passed in via `props`, and the React component would have no dependencies on anything else in your system. It’s actually one of the simplest, cleanest and most completely specified interfaces of any modern JS UI library or framework, in my experience. It is true that a React component can also hold its own state and can use that data in addition to the supplied props when rendering. However, that state is normally reserved for UI-related data that isn’t part of the underlying data model, such as keeping track of a selected item or which page is currently active on a paginated table view. Toy examples like to-do lists sometimes use React component state to hold more general data, because that is simpler in a trivial demonstration than writing separate MVC components or the equivalent, but that’s not how you write idiomatic React code in production systems, and it never has been.
      - flukus 10y ago
        Do you know of an example that does things properly? There are a lot of people here defending the code as written.
- throwaway2016a 10y ago
  > I guess that's what happens when you don't hire anyone over 30 It's comments like these while people don't hire anyone over 30. Rather than provide thoughtful critique of the platform the response is "This looks like something I saw 20 years ago and it didn't work then so it won't work now, I'm not even going to look at it!" Speaking as someone who is over 30... before you criticize something, understand it. For example, this code is nothing like PHP spaghetti code for reasons I listed in other comments among others I'm sure I didn't think of. I see it very often. People like "we did this 30 years ago. I guess what is old is new again. Hahaha" But I've lived through it... like many of you... I've gone from CGI scripts written in C++ when you couldn't even guarantee a browser had Javascript to PHP, to Ruby, etc etc etc, blah blah blah. But after all that, and a Computer Science degree, I gave React an honest look and while it's not perfect. It is worth a look.
  - flukus 10y ago
    The critique is in the title. There are good reasons presentation and logic are separated.
    - tracker1 10y ago
      And how often are the presentation and logic changed in isolation of each other... they aren't separate concerns at many levels. The concern is sepearated in React at a component level... how a component is rendered is just as important as how it raises/accepts changes outside of itself, and often interacts. Also, having JSX in my JS is much easier to deal with than remembering some abstract DSL for how to iterate through children in a template language. It's no more goofy.
      - flukus 10y ago
        Anywhere from never to always. A Pure logic change shouldn't need a ui change. At some companies the ui and logic are different responsibilities (this used to be common). Other times there will be multiple UIs for the same logic.
- eagsalazar2 10y ago
  Bitter over 30 year-old? (I'm 43 btw so not trying to be ageist, just asking what seems like an obvious question) It does look similar but it is night and day different beyond the superficial appearance. Are you actually trying to say that the in-browser experience in web apps from 15 years ago were in the same ballpark as even simple single page javascript apps from today? That is laughable. So something must be different right?? Derisive condescending comments like yours prevent the conversation from figuring out what the positive is and ultimately keep the conversation stuck in the all too common and boring whining about javascript which has infected HN.
  - flukus 10y ago
    > Bitter over 30 year-old? Yes I'm bitter that the same errors we made with desktop apps in the 90's (and possibly earlier) are being repeated. > Are you actually trying to say that the in-browser experience in web apps from 15 years ago were in the same ballpark as even simple single page javascript apps from today? Yes. The biggest difference is the amount of postbacks, the state handling has moved client side.
    - tracker1 10y ago
      But are they really the same... a common prescription for state management with react is to use something like flux or redux. State management solutions that have worked out well for gaming platforms to this day. Not the MVC patterns that bring a lot of complexities that make cross cutting concerns that much more difficult. This is emphatically NOT the same as the desktop apps in the 90's.
  - deleted 10y ago
    [deleted]
  - rimantas 10y ago
    The problem is that while true web apps experience might have improved, the web as the whole degraded a lot since everyone is treating everyting as the app, whn in reality majority should be just a static content sites. Now you download 4MB of crap just to see 2KB of text.
- enobrev 10y ago
  I started my career "professionally" with Cold Fusion 3 or 4 about 16ish years ago, and left it behind for PHP4, and so on, once I had to start paying for my own hosting. I realized a couple months ago how incredibly similar JSX is to Cold Fusion - At least CF4. It's nearly identical in some respects.
- coldtea 10y ago
  It's also amazing how much its nothing like that and how shallow the comparison is. And I've been around before PHP was a thing.
- Lazare 10y ago
  Interestingly enough, I am over 30, and my day job is to both write new React code, new modern php code, and to maintain some "classic" php code that intermingles logic, SQL, HTML, CSS, and javascript in one horrible disaster. So I think I can say with some confidence that everything you have written is completely nonsense. > It is amazing how much react resembles php and classic asp from 15 years ago. Yes, it's amazing how it's nothing at all alike.
- madeofpalk 10y ago
  Actually, React was written by developers, who may or may not be over 30, who have a very solid understanding of PHP (Facebook) and sort to replicate their discipline and success with PHP on the client.
- Nekorosu 10y ago
  > I guess that's what happens when you don't hire anyone over 30. I have arguments against that but I'll keep them to myself because your sentence isn't really relevant to the original discussion.
dclowd9901 10y ago
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 10y ago
  > 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 10y ago
    We're all geniuses when we have 30 years of retrospect.
    - j1o1h1n 10y ago
      Only if you take the time to look back
wineisfine 10y ago
imagine this without syntax highlighting.
- victoray 10y ago
  yeah, you're right!
geetee 10y ago
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.
- tracker1 10y ago
  Or worse when those three files are in three different, mirrored directories.
- rimantas 10y ago
  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.
JTenerife 10y ago
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 10y ago
  > Seperation should be by the responsibilities a component, not by language. Very well said! I'm quoting this one.
- deleted 10y ago
  [deleted]
throwaway2016a 10y ago
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).
- ajeet_dhaliwal 10y ago
  Yes, given the tweet text I was looking for the css in the image but couldn't find it, I didn't want to bother looking for too long and figured it was just well hidden.
- carlosdp 10y ago
  Yea, I'm super confused on how this snippet of code is meant as evidence of un-separated concerns. He even says it contains styling, but it absolutely does not. Sure, if someone does React incorrectly, they will inter-mingle code that could make working on it painful, but that's true of vanilla HTML/JS/CSS as well. Having developed using React for a bit now after years of using mostly vanilla JS/jQuery, I would never go back if I can help it. It's much nicer to write code that generates markup rather than code that manipulates markup.
- happycodework 10y ago
  Tbh how is the one concern not the Fact they use 'let'. Gross. Fun fact: types, line numbers, and BS keywords like 'let' 'var' and * *&uint32, are only constructs of the language authors mind... a visualization of how he thinks. And are completely optional to a language (given a slightly more flexible parsercompiler)
ClayFerguson 10y ago
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/resources/public/ts/dlg/AudioPlayerDlg.ts https://github.com/Clay-Ferguson/meta64/blob/master/src/main... 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.
- Jetrel 10y ago
  Yeah - this, a thousand times, this. This is one of the biggest wins we've had recently over just about every prior web authoring approach - and my experience goes back to the PHP days.
- hitchhiker999 10y ago
  That's lovely. Beautiful, readable, elegant bit of code. (35 years experience)
  - ClayFerguson 10y ago
    Thanks, it actually wasn't a great example to make my point because that file contains actually a few things I do try to avoid, but it does demonstrate that "generated HTML" doesn't have to be ugly and hard to read, using TypeScript or even JavaScript if you have a consistent architecture for how it's done.
andrew_wc_brown 10y ago
MithrilJS is better. Don't know why people bother with ReactJS.
- jsguy 10y ago
  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.
hoodoof 10y ago
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 10y ago
  > 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 10y ago
    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.
carsongross 10y ago
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 10y ago
  http://i.imgur.com/QmrvkOl.png http://i.imgur.com/QmrvkOl.png ;-)
eagsalazar2 10y ago
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 10y ago
  This is about react more than js specifically. There are plenty of javascript templating libraries that offer better separation between presentation and logic.
Jetrel 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      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.
sparkie 10y ago
"15 years building linear web pages when we should've been building applications"
sova 10y ago
Sounds like we need a fundamentally different approach to UI...
bschwindHN 10y ago
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 10y ago
  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.
pmontra 10y ago
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.
waffleau 10y ago
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.
- tracker1 10y ago
  Completely agreed... I've been building web based apps for over two decades now. React is the first framework that feels "right"... there are some things that could be better, It's so much better than what came before. Angular brought me so many WTF moments, I can't even begin to mention them all, even ng2+. With React there's been a handful, usually with a useful error that made sense. So much effort has been done with React to work with the broader JS community and its' direction as opposed to against it. ES6 class syntax, simple render function components, modules. React doesn't need much to get started, and it's unprescripted enough that just a few tools can round it out, with heavier and lighter options. I don't want to go back, and frankly, I'd rather have JSX in my JS than go back to weird template DSLs ever again.
- coldtea 10y ago
  >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).
jasoncchild 10y ago
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
hitchhiker999 10y ago
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.
kriro 10y ago
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.
nojvek 10y ago
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 10y ago
  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)
insin 10y ago
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/
Lazare 10y ago
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 10y ago
  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.
  - 10y ago
Kiro 10y ago
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.
vbezhenar 10y ago
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 10y ago
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 10y ago
  It's Preact, the screenshotted code is from the Preact homepage.
- deleted 10y ago
  [deleted]
LeanderK 10y ago
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.
GrumpyNl 10y ago
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.
fergie 10y ago
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.
jcoffland 10y ago
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 10y ago
  Why do you think they are bad ideas?
  - Sacho 10y ago
    I've articulated some of the "bad ideas" that Angular 1 had before - https://news.ycombinator.com/item?id=11846843 https://news.ycombinator.com/item?id=11846843 but I'm curious to hear which ideas are similarly bad in React.
  - sanbor 10y ago
    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.
    - Nekorosu 10y ago
      Actually both Angular and React have it's place. I have to say here I absolutely hate Angular but it's a very good tool for Java developers in need of building some simple CRUD admin interface. Familiar concepts/vocabulary help a lot.
williamle8300 10y ago
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.
k__ 10y ago
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.
eindbaas 10y ago
Classic knee-jerk reaction to JSX.
sametmax 10y ago
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.
Nekorosu 10y ago
This is a typical Thomas Fuchs trolling. It shouldn't be taken serious. You won't get any constructive arguments from him anyway.
Tade0 10y ago
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.
Nekorosu 10y ago
It's hard to acknowledge for OOP crowd they've got the separation of concerns the wrong way.
msimpson 10y ago
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 10y ago
  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 10y ago
    Well, given her partner, we can be sure none of their products use React.
pacomerh 10y ago
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.

254 points by sidcool 10y ago

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.

noonespecial 10y ago
The same thing lures people in every time. You sit down, open a single file and type for 5 minutes and you've got a baby web app. Whee! The pain comes later. So much pain. Its like the payday loan of technical debt.
- iEchoic 10y ago
  Where does the debt come in?
- Nekorosu 10y ago
  Except it's quite the opposite in case of React.
quasse 10y ago
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?
- SomeStupidPoint 10y ago
  Ah, you think technical design is governed by technical concerns. It's fashion, like anything else.
  - quasse 10y ago
    I've been lucky enough in the general case to either be in charge of system design or have very thoughtful coworkers who are well aware of the burden of technical debt. Unfortunately I can't babysit every other team and have occasionally inherited some real abominations. Often times it has been worth spending the ~week in man hours to immediately rewrite them to avoid the constant time suck of maintaining spaghetti code down the line. Often they are a kernel of simple functionality buried in thousands of lines of code smeared across a random assortment of files that can actually be replaced fairly simply once you've sussed out what they're actually supposed to be doing.
    - deleted 10y ago
      [deleted]
- throwaway2016a 10y ago
  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 10y ago
    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.."
    - Chris_Newton 10y ago
      (I’m not the person you replied to, but I’ll offer some thoughts anyway.) for a component, why do I need the virtual dom diffing? React allows you to build relatively large and complicated DOM trees by composing smaller components, and it is designed so you can then (re)render the entire tree as a single operation when any relevant underlying state changes, without having to manage (re)rendering each individual component within that tree manually. This is useful because now you only need to define one absolute way to render from a given set of underlying data. You no longer need to give a relative specification for all possible transitions from one state to another, which can be a huge reduction in complexity and edge cases if you’re working on a large, complicated UI. However, other things being equal, rerendering your entire DOM tree on the slightest change in the underlying data would become painfully slow for any system that isn’t very small. That is partly because there are costs to regenerating the DOM tree itself, as with any template-based system. However, the tightest bottleneck in today’s browsers is usually the consequential costs that result from updating the DOM in terms of regenerating layout and so on. The virtual DOM diffing is essentially a performance optimisation that lets you mitigate those consequential costs, because now only the parts of the DOM that actually change as a result of changes in the underlying data will lead to rerendering in the browser and the costs that incurs. In other words, virtual DOM diffing isn’t the point of React, declarative/absolute rendering is, but the former is what makes the latter fast enough to be viable. As an aside, React’s answer to the other half of the performance problem, the cost of regenerating the entire DOM tree, is the `shouldComponentUpdate` function. That lets components, including child components deep within a large tree, perform any quick tests they can to determine whether their rendered output will actually change, and to skip the rerendering if not. That leads on to various other ideas that have become popular in connection with React, such as using immutable data models for the underlying data. With immutable underlying data, a shallow comparison between a couple of object references that can be performed in moments acts as a “dirty check”. However, you don’t have to use React in that way. Some people are wary of relying too much on `shouldComponentUpdate`, which inherently violates the “single source of truth” principle and risks introducing bugs if its assumptions differ from those of the same component’s `render` method. Others find the arguments for building your entire data store around immutable objects, which itself carries a hefty performance overhead, less compelling. There are certainly other reasonable architectures you could choose for supplying the underlying data to React components and triggering rerendering when that data changes, including more traditional designs where view components observe the underlying data model in some way and trigger their own rerendering on any relevant change. Going down this path is effectively using React as a reasonably efficient and composable template rendering engine, so you can still have the advantages of absolute rendering logic, and you bypass some of the potential performance problems caused by doing large-scale rerenders with React, but in return you take back some of the responsibility to set up explicit dependencies between your view components and the data they depend on. As ever, there are trade-offs, and usually there will be multiple quite different designs that will do a decent job as long as you understand their pros and cons.
- TeMPOraL 10y ago
  > I feel like I have (or everyone else has) contracted some sort of amnesia. Didn't we already hash this out guys? Maybe we're backtracking on the idiocy we started on around PHP times? The whole "separation of concerns" thing that went to such extremes as to become a cargo cult? I offer two observations: - presentation is often very much content at the same time (that's why websites end up cluttered with divs that have no semantic meaning and serve no other purpose than being CSS hooks) - separation of concerns was about not putting business code in views, not about having views without any code; you need code to drive views (and yes, template languages are Turing-complete, so they count as code too)
kul_ 10y ago
Agreed. Take the example of people hating XML and trying to reinvent everything good XML already had with JSON and JSON Schema. http://json-schema.org/ http://json-schema.org/
- tracker1 10y ago
  My biggest peeve with XML is there's no concrete way to represent a piece of XML in code, it's in my opinion TOO flexible. You can express something as an attribute, a child, multiple children of the same element, a value of a child, etc. It doesn't translate cleanly to any kind of object structure in terms of code. And it goes in reverse too. Now, there are standards like SOAP, etc... In the end, JSON and some clear docs for an API is usually easier to reason with than any of the boatloads of cruft that came along with XML. Not to mention the much larger transmission size.
  - kul_ 10y ago
    I am not sure if you had chance to play with JAXB, it maps xml very cleanly to java objects. I mean you can have the whole darn thing define inheritance and it would generate the corresponding relation in Objects too. IMO It just needs to be given some consideration before rejecting as old bloated piece of crap.
  - tannhaeuser 10y ago
    That's because originally SGML/HTML/XML attributes were for (mostly) presentational details, but this role was shifted to CSS. The resulting combination does indeed look arbitrary, especially with CSS's total lack of mental discipline (but let's not be too harsh here). In judging whether something should be represented as element text or as attribute, ask yourself whether that something is content or metadata. In a context where this distinction doesn't make sense, markup (SGML, XML, HTML) probably doesn't make sense either. Markup isn't and never was intended for representing arbitrary data - it is for representing text with optional markup, and is designed for end-users and content authors, not necessarily web developers. As for representing XML in code, there was E4X which allowed you to represent XML literals in Javascript (Firefox and rhino had it a couple years ago, but it kindof wasn't convincing). Keep in mind that Javascript was invented as a language to manipulate a DOM in the first place, so there you have your canonical representation of markup in Javascript.
Chris_Newton 10y ago
I guess that's what happens when you don't hire anyone over 30. Writing as someone comfortably over 30, I don’t see the problem here (edit: meaning having something that looks like HTML and something that looks like JS in the same place). If you need to generate content dynamically for a web page based on some underlying business logic and data, you need some sort of rendering logic that determines how to fill in the blanks in your generic pattern using your current specific information. This has been true for every template system and framework since forever. Personally, I don’t much like putting the logic right there in the JSX, as the `map` does in the tweeted example. I think one of the nicer things about the way React and JSX work is that you do have the full power of JS to write your rendering logic, and you can build up a part of the rendered output separately and then compose the overall output from the individual parts without needing to put a lot of extra logic in there. But that’s just my personal preference, and others might reasonably disagree. The challenges with building larger applications in PHP — or in JavaScript, for that matter — have more often been about not having good tools in the language to build cleanly separated, modular designs. That side of things has improved somewhat with time, and will probably always be less than ideal because of the legacy baggage these languages now carry, but in any case the big problems were never really about an artificial separation of HTML, CSS and JS, and including JSX within JS code when using React is little different to embedding conditional logic in any other template language used by any other programming language or library.
hoodoof 10y ago
This is a really smarmy and ignorant comment - if you tell me that you are an experienced react programmer and therefore understand what you are looking at, then I'll reconsider, but as it stands, your comment is just ignorant.
- flukus 10y ago
  Why react specifically? My general experience tells me that mixing presentation and logic ends badly, as well as the collective experience of the industry. We've been down this path with just about every GUI technology before but it seems we have to learn it again.
  - Chris_Newton 10y ago
    Why react specifically? My general experience tells me that mixing presentation and logic ends badly If you’re talking about the `todos` list in the tweeted example, I’m afraid you’ve been successfully trolled. In non-toy code, you’d typically hold the underlying state in a separate part of your system rather than the rendering React component, as with any other sanely designed UI. That data would be passed into the React component via `props` so it knew what to render, and the callback function to handle a form submission would also be passed in via `props`, and the React component would have no dependencies on anything else in your system. It’s actually one of the simplest, cleanest and most completely specified interfaces of any modern JS UI library or framework, in my experience. It is true that a React component can also hold its own state and can use that data in addition to the supplied props when rendering. However, that state is normally reserved for UI-related data that isn’t part of the underlying data model, such as keeping track of a selected item or which page is currently active on a paginated table view. Toy examples like to-do lists sometimes use React component state to hold more general data, because that is simpler in a trivial demonstration than writing separate MVC components or the equivalent, but that’s not how you write idiomatic React code in production systems, and it never has been.
    - flukus 10y ago
      Do you know of an example that does things properly? There are a lot of people here defending the code as written.
throwaway2016a 10y ago
> I guess that's what happens when you don't hire anyone over 30 It's comments like these while people don't hire anyone over 30. Rather than provide thoughtful critique of the platform the response is "This looks like something I saw 20 years ago and it didn't work then so it won't work now, I'm not even going to look at it!" Speaking as someone who is over 30... before you criticize something, understand it. For example, this code is nothing like PHP spaghetti code for reasons I listed in other comments among others I'm sure I didn't think of. I see it very often. People like "we did this 30 years ago. I guess what is old is new again. Hahaha" But I've lived through it... like many of you... I've gone from CGI scripts written in C++ when you couldn't even guarantee a browser had Javascript to PHP, to Ruby, etc etc etc, blah blah blah. But after all that, and a Computer Science degree, I gave React an honest look and while it's not perfect. It is worth a look.
- flukus 10y ago
  The critique is in the title. There are good reasons presentation and logic are separated.
  - tracker1 10y ago
    And how often are the presentation and logic changed in isolation of each other... they aren't separate concerns at many levels. The concern is sepearated in React at a component level... how a component is rendered is just as important as how it raises/accepts changes outside of itself, and often interacts. Also, having JSX in my JS is much easier to deal with than remembering some abstract DSL for how to iterate through children in a template language. It's no more goofy.
    - flukus 10y ago
      Anywhere from never to always. A Pure logic change shouldn't need a ui change. At some companies the ui and logic are different responsibilities (this used to be common). Other times there will be multiple UIs for the same logic.
eagsalazar2 10y ago
Bitter over 30 year-old? (I'm 43 btw so not trying to be ageist, just asking what seems like an obvious question) It does look similar but it is night and day different beyond the superficial appearance. Are you actually trying to say that the in-browser experience in web apps from 15 years ago were in the same ballpark as even simple single page javascript apps from today? That is laughable. So something must be different right?? Derisive condescending comments like yours prevent the conversation from figuring out what the positive is and ultimately keep the conversation stuck in the all too common and boring whining about javascript which has infected HN.
- flukus 10y ago
  > Bitter over 30 year-old? Yes I'm bitter that the same errors we made with desktop apps in the 90's (and possibly earlier) are being repeated. > Are you actually trying to say that the in-browser experience in web apps from 15 years ago were in the same ballpark as even simple single page javascript apps from today? Yes. The biggest difference is the amount of postbacks, the state handling has moved client side.
  - tracker1 10y ago
    But are they really the same... a common prescription for state management with react is to use something like flux or redux. State management solutions that have worked out well for gaming platforms to this day. Not the MVC patterns that bring a lot of complexities that make cross cutting concerns that much more difficult. This is emphatically NOT the same as the desktop apps in the 90's.
- deleted 10y ago
  [deleted]
- rimantas 10y ago
  The problem is that while true web apps experience might have improved, the web as the whole degraded a lot since everyone is treating everyting as the app, whn in reality majority should be just a static content sites. Now you download 4MB of crap just to see 2KB of text.
enobrev 10y ago
I started my career "professionally" with Cold Fusion 3 or 4 about 16ish years ago, and left it behind for PHP4, and so on, once I had to start paying for my own hosting. I realized a couple months ago how incredibly similar JSX is to Cold Fusion - At least CF4. It's nearly identical in some respects.
coldtea 10y ago
It's also amazing how much its nothing like that and how shallow the comparison is. And I've been around before PHP was a thing.
Lazare 10y ago
Interestingly enough, I am over 30, and my day job is to both write new React code, new modern php code, and to maintain some "classic" php code that intermingles logic, SQL, HTML, CSS, and javascript in one horrible disaster. So I think I can say with some confidence that everything you have written is completely nonsense. > It is amazing how much react resembles php and classic asp from 15 years ago. Yes, it's amazing how it's nothing at all alike.
madeofpalk 10y ago
Actually, React was written by developers, who may or may not be over 30, who have a very solid understanding of PHP (Facebook) and sort to replicate their discipline and success with PHP on the client.
Nekorosu 10y ago
> I guess that's what happens when you don't hire anyone over 30. I have arguments against that but I'll keep them to myself because your sentence isn't really relevant to the original discussion.

dclowd9901 10y ago

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 10y ago
> 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 10y ago
  We're all geniuses when we have 30 years of retrospect.
  - j1o1h1n 10y ago
    Only if you take the time to look back

wineisfine 10y ago

imagine this without syntax highlighting.

victoray 10y ago
yeah, you're right!

geetee 10y ago

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.

tracker1 10y ago
Or worse when those three files are in three different, mirrored directories.
rimantas 10y ago
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.

JTenerife 10y ago

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 10y ago
> Seperation should be by the responsibilities a component, not by language. Very well said! I'm quoting this one.
deleted 10y ago
[deleted]

throwaway2016a 10y ago

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

ajeet_dhaliwal 10y ago
Yes, given the tweet text I was looking for the css in the image but couldn't find it, I didn't want to bother looking for too long and figured it was just well hidden.
carlosdp 10y ago
Yea, I'm super confused on how this snippet of code is meant as evidence of un-separated concerns. He even says it contains styling, but it absolutely does not. Sure, if someone does React incorrectly, they will inter-mingle code that could make working on it painful, but that's true of vanilla HTML/JS/CSS as well. Having developed using React for a bit now after years of using mostly vanilla JS/jQuery, I would never go back if I can help it. It's much nicer to write code that generates markup rather than code that manipulates markup.
happycodework 10y ago
Tbh how is the one concern not the Fact they use 'let'. Gross. Fun fact: types, line numbers, and BS keywords like 'let' 'var' and * *&uint32, are only constructs of the language authors mind... a visualization of how he thinks. And are completely optional to a language (given a slightly more flexible parsercompiler)

ClayFerguson 10y ago

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/resources/public/ts/dlg/AudioPlayerDlg.ts https://github.com/Clay-Ferguson/meta64/blob/master/src/main... 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.

Jetrel 10y ago
Yeah - this, a thousand times, this. This is one of the biggest wins we've had recently over just about every prior web authoring approach - and my experience goes back to the PHP days.
hitchhiker999 10y ago
That's lovely. Beautiful, readable, elegant bit of code. (35 years experience)
- ClayFerguson 10y ago
  Thanks, it actually wasn't a great example to make my point because that file contains actually a few things I do try to avoid, but it does demonstrate that "generated HTML" doesn't have to be ugly and hard to read, using TypeScript or even JavaScript if you have a consistent architecture for how it's done.

andrew_wc_brown 10y ago

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

jsguy 10y ago
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.

hoodoof 10y ago

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 10y ago
> 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 10y ago
  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.

carsongross 10y ago

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 10y ago
http://i.imgur.com/QmrvkOl.png http://i.imgur.com/QmrvkOl.png ;-)

eagsalazar2 10y ago

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 10y ago
This is about react more than js specifically. There are plenty of javascript templating libraries that offer better separation between presentation and logic.

Jetrel 10y ago

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 10y ago
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 10y ago
  > 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 10y ago
    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.

sparkie 10y ago

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

sova 10y ago

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

bschwindHN 10y ago

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 10y ago
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.

pmontra 10y ago

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.

waffleau 10y ago

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.

tracker1 10y ago
Completely agreed... I've been building web based apps for over two decades now. React is the first framework that feels "right"... there are some things that could be better, It's so much better than what came before. Angular brought me so many WTF moments, I can't even begin to mention them all, even ng2+. With React there's been a handful, usually with a useful error that made sense. So much effort has been done with React to work with the broader JS community and its' direction as opposed to against it. ES6 class syntax, simple render function components, modules. React doesn't need much to get started, and it's unprescripted enough that just a few tools can round it out, with heavier and lighter options. I don't want to go back, and frankly, I'd rather have JSX in my JS than go back to weird template DSLs ever again.
coldtea 10y ago
>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).

jasoncchild 10y ago

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

hitchhiker999 10y ago

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.

kriro 10y ago

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.

nojvek 10y ago

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 10y ago
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)

insin 10y ago

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/

Lazare 10y ago

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 10y ago
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.
- 10y ago

Kiro 10y ago

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.

vbezhenar 10y ago

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 10y ago

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 10y ago
It's Preact, the screenshotted code is from the Preact homepage.
deleted 10y ago
[deleted]

LeanderK 10y ago

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.

GrumpyNl 10y ago

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.

fergie 10y ago

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.

jcoffland 10y ago

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 10y ago
Why do you think they are bad ideas?
- Sacho 10y ago
  I've articulated some of the "bad ideas" that Angular 1 had before - https://news.ycombinator.com/item?id=11846843 https://news.ycombinator.com/item?id=11846843 but I'm curious to hear which ideas are similarly bad in React.
- sanbor 10y ago
  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.
  - Nekorosu 10y ago
    Actually both Angular and React have it's place. I have to say here I absolutely hate Angular but it's a very good tool for Java developers in need of building some simple CRUD admin interface. Familiar concepts/vocabulary help a lot.

williamle8300 10y ago

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.

k__ 10y ago

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.

eindbaas 10y ago

Classic knee-jerk reaction to JSX.

sametmax 10y ago

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.

Nekorosu 10y ago

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

Tade0 10y ago

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.

Nekorosu 10y ago

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

msimpson 10y ago

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 10y ago
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 10y ago
  Well, given her partner, we can be sure none of their products use React.

pacomerh 10y ago

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.