It's funny how, for years, we've been trying to get away from HTML mixed with code (specially in spaguetti PHP), just to get back to something similar again.
Well, I wonder where all the PHP programmers went...
JSX in detail
41–50 of 73 posts
Re: JSX in detail
#42It's funny how, for years, we've been trying to get away from HTML mixed with code (specially in spaguetti PHP), just to get back to something similar again.
The struggle has been getting away from writing HTML in strings just like getting away from SQL in strings (excluding security/SQL injection reasons) which do not have handy IDE features like telling you that is not a valid HTML element.
JSX combined with an editor (Visual Studio Code + plugins) is nice because it does all of that highlighting and checking for you.
Re: JSX in detail
#43It's funny how, for years, we've been trying to get away from HTML mixed with code (specially in spaguetti PHP), just to get back to something similar again.
It's not the same thing. JSX is a user experience enhancement for developers.
Re: JSX in detail
#44It's funny how, for years, we've been trying to get away from HTML mixed with code (specially in spaguetti PHP), just to get back to something similar again.
This is actually the misconception.
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.
Re: JSX in detail
#45It's funny how, for years, we've been trying to get away from HTML mixed with code (specially in spaguetti PHP), just to get back to something similar again.
JSX is not HTML. You are not writing HTML when you write JSX, you are writing Javascript. You are using a more convenient syntax to generate the virtual dom. All this hand wringing, navel gazing cargo-culting JSX gonna eat my baby bs is unnecessary. The PHP/html templating lessons of yonder simply does not apply.
> You are not writing HTML when you write JSX, you are writing Javascript.
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.
Re: JSX in detail
#46Has anyone else made the switch from JSX to hyperscript? JSX works well enough, but I love the consistency and composability of building views with plain old functions and data structures.
There are a number of template languages that compile to hyperscript, I use jade/pug [0]. I haven't had to change my templates in years but I can still take advantage of virtual DOMs like React.
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.).
Re: JSX in detail
#47Earlier quoted context omitted.
JSX is not HTML. You are not writing HTML when you write JSX, you are writing Javascript. You are using a more convenient syntax to generate the virtual dom. All this hand wringing, navel gazing cargo-culting JSX gonna eat my baby bs is unnecessary. The PHP/html templating lessons of yonder simply does not apply.
> You are not writing HTML when you write JSX, you are writing Javascript. 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 ot…
Huh? If you want React to render a div somewhere you presumably have to say the word "div" to it at some point. Would you be happier just saying React.createElement('div')? Because saying in the middle of your javascript code is simply syntactic sugar for createElement.
Re: JSX in detail
#48Earlier quoted context omitted.
JSX is not HTML. You are not writing HTML when you write JSX, you are writing Javascript. You are using a more convenient syntax to generate the virtual dom. All this hand wringing, navel gazing cargo-culting JSX gonna eat my baby bs is unnecessary. The PHP/html templating lessons of yonder simply does not apply.
> You are not writing HTML when you write JSX, you are writing Javascript. 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 ot…
It never gets turned into HTML. It gets turned into JS, which, eventually causes calls to `createElement(...)` etc. to happen.
You are writing declarative code that says what the UI should do. It is NOT - and I cannot stress this enough - a "template langauge" in the same way as Handlebars or PHP. There is no string interpolation anywhere.
Re: JSX in detail
#49Earlier quoted context omitted.
JSX is not HTML. You are not writing HTML when you write JSX, you are writing Javascript. You are using a more convenient syntax to generate the virtual dom. All this hand wringing, navel gazing cargo-culting JSX gonna eat my baby bs is unnecessary. The PHP/html templating lessons of yonder simply does not apply.
> You are not writing HTML when you write JSX, you are writing Javascript. 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 ot…
>And why the hell you have to write code in JS that will be ultimately represented as HTML?
If an analogy helps, the React virtual-DOM is philosophically similar to the very old and industry-accepted technique of double-buffering[1].
Your question would be similar to asking, "why the hell do you write pixel data to an invisible memory buffer if you're going to ultimately display it on the screen?"
The plain old HTML specification invented by Tim Berners-Lee and the traditional HTML rendering engines do not have the concept of an invisible "compositing layer" with a formal API standardized across Chrome/Firefox/IE/etc exposed to programmers.
The vdom is the computer science abstraction to bolt on that "compositing layer" to HTML. The React loop then renders the invisible composite layer to the real DOM.
[1] https://en.wikipedia.org/wiki/Multiple_buffering#Double_buff...
Re: JSX in detail
#50Earlier quoted context omitted.
JSX is not HTML. You are not writing HTML when you write JSX, you are writing Javascript. You are using a more convenient syntax to generate the virtual dom. All this hand wringing, navel gazing cargo-culting JSX gonna eat my baby bs is unnecessary. The PHP/html templating lessons of yonder simply does not apply.
> You are not writing HTML when you write JSX, you are writing Javascript. 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 ot…
> And why the hell you have to write code in JS that will be ultimately represented as HTML?
I only use React for React-Native, so my JSX gets turned into native objects.
Have you ever written a non-web program though? The default mode for almost all native GUI kits is for developers to define the UI in code.
I've never, ever seen a UI designer or a high level DSL (like HTML) that works better than code for non-trivial programs. With JSX, HTML has finally caught up to the rest of the GUI programming world.