6 ms·

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.

dudul 9y ago
Can't upvote this enough. Each time I try to dive into React/JSX I have some dark visions of PHP and JSP in my head.
lkrubner 9y ago
You bring up a point that was discussed 35 days ago: https://news.ycombinator.com/item?id=14925899 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.
- ageofwant 9y ago
  Developers can build whatever they want with the html/css/javascript stack we have today, and they have. 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.
- tannhaeuser 9y ago
  HTML wasn't intended as an application platform, but for hyperlinked documents. That developers are using browsers for apps has economical reasons (eg. end users not willing to pay for software). That HTML isn't a good fit for a purpose it never was intended for is hardly TBL's fault, is it?
spsoto 9y ago
I used to think that way, but then you realize that JSX ends up behaving only as syntactic sugar for `React.createElement`. 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.
camus2 9y ago
> 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. 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/Processing_XML_with_E4X https://developer.mozilla.org/en-US/docs/Archive/Web/E4X/Pro... Like someone said separation of concerns =/= separation of files.
ageofwant 9y ago
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.
- vladimir-y 9y ago
  > 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.
  - savanaly 9y ago
    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 <div> in the middle of your javascript code is simply syntactic sugar for createElement.
  - n3dst4 9y ago
    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.
    - vladimir-y 9y ago
      > It never gets turned into HTML Really? So users get the JS code in the browser rendered in the same way as the code source looks, not the dynamically built DOM model which has the native representation form of HTML? Surely JSX is an abstraction layer on top of the createElement thing, and that thing is a part of the building strict template model scenario.
baby 9y ago
spaguetti PHP has been replaced with PHP in templating. See Blade in laravel for example: https://laravel.com/docs/5.5/blade https://laravel.com/docs/5.5/blade 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?
- scarlac 9y ago
  I don't think you ever used <? and ?>. Only thing I recall is that there was a debate over double "{{" or triple "{{{" as the default for auto-escaping output.
mhd 9y ago
Well, I wonder where all the PHP programmers went...
FLUX-YOU 9y ago
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 <cavnas> 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.
arcosdev 9y ago
It's not the same thing. JSX is a user experience enhancement for developers.
- vec 9y ago
  PHP's everything-is-a-template philosophy is also a user experience enhancement for developers. React's nested components may provide a much saner rendering model than PHP's glorified string concatenation, but that's a separate question from how their templates are parsed. 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.
scarlac 9y ago
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.

dudul 9y ago

Can't upvote this enough. Each time I try to dive into React/JSX I have some dark visions of PHP and JSP in my head.

lkrubner 9y ago

You bring up a point that was discussed 35 days ago: https://news.ycombinator.com/item?id=14925899 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.

ageofwant 9y ago
Developers can build whatever they want with the html/css/javascript stack we have today, and they have. 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.
tannhaeuser 9y ago
HTML wasn't intended as an application platform, but for hyperlinked documents. That developers are using browsers for apps has economical reasons (eg. end users not willing to pay for software). That HTML isn't a good fit for a purpose it never was intended for is hardly TBL's fault, is it?

spsoto 9y ago

I used to think that way, but then you realize that JSX ends up behaving only as syntactic sugar for `React.createElement`. 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.

camus2 9y ago

> 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. 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/Processing_XML_with_E4X https://developer.mozilla.org/en-US/docs/Archive/Web/E4X/Pro... Like someone said separation of concerns =/= separation of files.

ageofwant 9y ago

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.

vladimir-y 9y ago
> 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.
- savanaly 9y ago
  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 <div> in the middle of your javascript code is simply syntactic sugar for createElement.
- n3dst4 9y ago
  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.
  - vladimir-y 9y ago
    > It never gets turned into HTML Really? So users get the JS code in the browser rendered in the same way as the code source looks, not the dynamically built DOM model which has the native representation form of HTML? Surely JSX is an abstraction layer on top of the createElement thing, and that thing is a part of the building strict template model scenario.

baby 9y ago

spaguetti PHP has been replaced with PHP in templating. See Blade in laravel for example: https://laravel.com/docs/5.5/blade https://laravel.com/docs/5.5/blade 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?

scarlac 9y ago
I don't think you ever used <? and ?>. Only thing I recall is that there was a debate over double "{{" or triple "{{{" as the default for auto-escaping output.

mhd 9y ago

Well, I wonder where all the PHP programmers went...

FLUX-YOU 9y ago

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

arcosdev 9y ago

It's not the same thing. JSX is a user experience enhancement for developers.

vec 9y ago
PHP's everything-is-a-template philosophy is also a user experience enhancement for developers. React's nested components may provide a much saner rendering model than PHP's glorified string concatenation, but that's a separate question from how their templates are parsed. 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.

scarlac 9y ago

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.