For what it is worth, the project I'm primarily using TSX in isn't using React either. It's built with Cycle.JS which uses competitor virtual DOM Snabbdom.
https://medium.com/@alexkrolick/writing-react-components-for...
"Overall it's not a bad experience. JSX makes HTML feel more at home, but tends to obscure the underlying Javascript. Composition and higher-order components are more obvious in plain JS. If I was writing a library using those patterns heavily I might be tempted to go JSX-free even if bundling with Webpack + Babel."
Before hyperscript, there was Templatizer which also compiled templates to JS functions. There are numerous good reasons to be able to manipulate templates easily as functions. Nevertheless there are numerous good reasons for templates (e.g. my designers don't need to know JavaScript, template languages last longer than JS trends, etc.).
Personally, I find JSX much more readable, and there was little love for hyperscript on the team.
Doing it the Lispy way, though, you'd likely use sexprs directly, with maybe some normal macros, so you wouldn't have HTML-like syntax but would have something that worked nicely in your editor.
http://www.red-lang.org/2016/12/entering-world-of-macros.htm...
(BTW, have a look at red for desktop apps, it's not even at 1.0 and already fucking amazing)
But on topic; Are Macros a well-defined "thing"? Since a macro in C, seems to be rather different from a RED or LISP Macro.
Or is it just that C macros are essentially the same, just more restricted?
https://github.com/babel/babel/blob/master/packages/babel-pl...
And most lisps don't have unfettered reader macros which would allow embedding macros using non-lisp syntax (aka JSX).
A macroed JSX wouldn't make much sense in Lisps really, and AFAIK isn't used with most clojurescript vdoms using either hiccup structures or regular function calls.
I've opened a github issue[2] to suggest to integrate the Klipse plugin on react.js official documentation. If you like the code interactivity, feel free to express yourself on the github issue[2].
1: https://github.com/viebel/klipse 2: https://github.com/facebook/react/issues/10646
https://github.com/mlmorg/react-hyperscript/blob/master/inde...
javascript?
I have been using JSX quite a bit and this is helping me get a better understanding.
If you have that clear, JSX is only syntax for the pure JavaScript you end up writing. Diving in the toolchain and ecosystem also helps you note that. Adding Webpack loaders to the mix, and then your application ends up only consisting of JavaScript files, where you abbreviate `React.createElement` with the old HTML tags.
https://news.ycombinator.com/item?id=14925899
Tarikyn said: "Most developers I knew in person didn't care about CSS or didn't 'get' it."
Part of my response was:
"Some people looked at the chaos of non-standard HTML and decided the Web was successful because it had been broken from the beginning, and it had learned to work well while broken. I reached a different conclusion. It became clear to me that what developers wanted to do simply had nothing to do with HTTP/HTML. We don't yet have the technology to do what developers want to do. HTML was an interesting experiment, but it suffered from a dual mandate. Sir Tim Berners Lee wanted HTML to both structure data and also present it in graphical form. Almost from the start, developers were conflicted about which mandate they should obey, but the preference, since at least 1993, if not earlier, was to give priority to the visual. For all practical purposes, developers saw HTTP/HTML as GUI for IP/TCP. Previous IP/TCP technologies (email, gopher, ftp) had lacked a visual component, but HTML finally offered a standard way to send things over Internet and format the end result visually (emphasis on "standard"; I could insert an aside here about X window systems and some cool software of that era, but every app implemented their own ideas about visual presentation. X-Emacs, for instance, had its own system for visual formatting over a network)."
The point is, HTML was an interesting experiment, but we now know that it doesn't work for what developers want to build. So it is time to get rid of HTML and move on to something better.
Its up to you whether or not you write semantically pure html using display agnostic <div>, <article> etc. structural elements and only use css for styling. That is, after all, what they are for.
You can have what you want by simply pretending that browsers do not have default rendering rules, and not use the html elements that are arguably presentation only things, like <h1>, <table> etc.
JSX is the template language of React. Angular and Vue use a template language on top of HTML. Neither of the 3 intermix business logic with presentation.
We shouldn't kid ourselves by talking of "code" not being a part of the templating as if SPAs magically come to life without code. Presentation has become more complex over time.
JSX combined with an editor (Visual Studio Code + plugins) is nice because it does all of that highlighting and checking for you.
The difference is that PHP+HTML is basically just templating. The HTML you put in PHP isn't a type that the interpreter is aware of and PHP isn't going to validate anything about.
Javascript used to have E4X in Firefox until it was removed when ES4 effort failed.
https://developer.mozilla.org/en-US/docs/Archive/Web/E4X/Pro...
Like someone said separation of concerns =/= separation of files.
So it totally makes sense to continue with this trend. Unless you have a very static website you don't really have a choice.
edit: woot, you don't use <? and ?> in Blade anymore?
And why the hell you have to write code in JS that will be ultimately represented as HTML? Is it because it simplifies some processes for the React's VDOM implementation? Don't you make your life harder in order to make React's life easier? If you say it's because you get template code linted in the same way as a regular JS code, I say that other frameworks also validate the templates doing AOT compilation.
PHP templates advertise, and do in fact provides, most of the same benefits as JSX. There are almost no new concepts to learn, the syntax is the same as the language proper, and developers have the full expressive power of that language at their disposal wherever they want it.
In practice, however, this seems to fail more often than not in a couple of ways. First, inexperienced developers (i.e. all developers at some point in their career) have a hard time resisting the urge to inline their business logic into their presentation logic. And second, the resulting templates are as often as not illegible, often requiring a reader to trace substantial chunks of tangentially related procedural logic in order to understand what will actually be rendered.
It's important to remember that PHP templates seemed like a good idea at the time. They did, and do, have real short-term benefits, and talented developers can leverage those benefits to great effect. But it turns out those benefits come with real long-term penalties, and besides, many developers are too green or too pressed for time or just don't care enough about the task at hand to wield that power consistently well enough to reliably reap the benefits in the first place. The PHP community has spent the last decade painfully crawling out of that tar pit; I'm not thrilled to see the JS community happily diving into it.
