For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript.

From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so happy that I did not have to learn another template syntax as it all was just JavaScript.

Another template engine syntax? No, thank you. I stick to React.

(The reason for the name change is that old versions of JS couldn't use keywords - like "for" and "class" - as property names.)

Granted, there is still some syntax you need to learn for JSX, but it's very little. If you already know HTML's syntax, the only new things I can think of are the curly braces for using JS expressions as prop values (you also need to know what a JS expression is, lest you try to use an if statement), and spread attributes.

All JSX is doing is transforming `<div className="foo">` into `[create div element]; div.className = "foo";`. If you wrote `<div class="foo">`, JSX would faithfully transform it into `[create div element]; div.class = "foo";` - which doesn't work.

React defines `React.createElement`, `<div class="foo"/>` transforms to `React.createElement("div", { "class": "foo" })`, so React could convert that under the hood to set className correctly.

Preact does something similar to allow this. However it now seems it is now too late for React for too little benefit. And there's a downside [1]:

> The JSX transform used to do that, but we don't recommend it because it's confusing if you ever try to pass class= or for= as a prop to your own components – you wouldn't expect to access them with a different name.

[1] https://github.com/facebook/react/issues/4433#issuecomment-1...

many years later, the workarounds like class -> className were designed by whatever party exerted most control over the JS DOM API (which is not really part of "Javascript itself") at the time, and who also brought you inconsistent camelcasing such as "onclick" ...

it's neither quite "native", nor is "defined by the same standards bodies" much of a sign of good design or worthy of copying.

feels more like if someone were to build, say, a modern high perf numerical library that includes necessary workarounds tributed to the eax/ax/ah/al peculiarities of x86 assembly.

mistakes were made. then copied, repeated and finally, standardised :)

Edit: I should also mention that Mithril comes with routing built in, as well as XHR utility and streams. I'm finding streams super useful for sophisticated state management.

those are the Javascript attribute names.

> and the obnoxious attribute name for dynamically inserted html.

Depends on your taste, but this is a plus for me, personally.

> It is not immune to the criticism that it requires learning.

It's takes maybe 10 minutes if you're already a little bit familiar with XML and know Javascript.

TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language.

Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options.

I think the intense UI-demands of progressiveness/SPAs expose the unsuitability of HTML for the task. But, simply because HTML is what we're stuck with browser-wise, there's no reason we have to think or work in HTML. Use tooling to abstract it away altogether and let a translator generate it.

We have a components+properties model, driven in Python, which gets translated to HTML+JS+CSS. We also have a visual editor, and abstractions over a bunch of the client-server stuff that's typically icky on the Web.

The challenge of such a system is that the web platform is so huge and sprawling, and constantly growing - and all of it's written in JS/HTML. So we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch" for doing layout etc in HTML if you really need to. But most of our users don't need it, and we're constantly working to extend the boundary of what you can do with simple properties and components.

>the web platform is so huge and sprawling, and constantly growing

>we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch

Makes sense. And totally worth the tradeoff for the developer if it helps me flip the 80/20 rule around. And, if the component model is extensible such that, when I do have to open the escape hatch, I can plug a resulting component back into the framework (lay it out and set properties in the visual editor, etc.), that might be even more optimal. Either way, I'd rather a framework do the heavy lifting and let me deal with the edge cases than me do all of the heavy lifting and plumbing, so that's a win.

>and all of it's written in JS/HTML

And, this is the part where I do have to scratch my head a little. I'm going to guess you've heard this question 4,321,257 times, but why not support JS? It is the lingua franca of the Web (as your quote acknowledges) for better or worse, and virtually all devs already know it. There's also a rich JS library ecosystem.

The idea that I have to pick up Python just to try it out introduces more friction. I'm guessing that might slow adoption with a huge percentage of your potential audience who might otherwise have the knowledge they need to jump right in.

Thrilled to hear it! If you do try it in more depth, please do drop me a line (email in my profile).

> why not support JS?

Two reasons:

1. Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves. People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS and all these other pieces, as well as this new framework, and you've done the opposite of simplifying web development. This is the "Javascript Framework of the Week" failure mode.

2. Contrary to your assertion, "most devs" don't actually know JS. It's something people only learn because they're learning front-end web development, and it's difficult to learn it without the whole HTML/CSS/frameworks hairball. Python is much friendlier to, eg, data scientists or embedded programmers or back-end developers, who have every right to think they should be able to put together a web app without learning three new programming languages and two new frameworks.

(This is another way of putting what I said earlier about "prioritising usability for non-web devs".)

I see. Kind of a purist approach that eliminates all temptation by not offering the option to go there. Sound reasoning, as JS definitely has slippery-slope potential.

>People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS

I'm probably too biased to make a call on this. I'm so wanting to be released from that madness that I'd fight tooth-and-nail not to descend back into it.

So, I look at it the other way around: My JS would be more disciplined (and there'd be les of it), as I'd be released from the need to use it so much for stuff like DOM handling. In my ideal world, I wouldn't even know there was a DOM or HTML or CSS. I'd just use JS in event handling and, perhaps, functionality that directly supports the same.

>"most devs" don't actually know JS...people only learn because they're learning front-end web development

That's what I intended--that most web devs know JS--as I was speaking in the context of web development.

But, I missed the emphasis on the "non-Web devs" portion of your statement. I do get that and applaud you for staying with your focus. The product has to have a market and an identity. OTOH, it feels so close for guys like me in the Web dev world who know there's a better way!

>please do drop me a line (email in my profile).

Will do. And will try to reserve any web-dev specific comments. :)

Have you tried QT or Xamarin?

These are for desktop/mobile apps right? If so, yeah, there are other options as well.

Was thinking more something like this, but for SPAs.

When I last gave it a try I had to manually generated the HTML document but without a (at least of of the box) syntax like jsx. If I recall correctly graphics is still there, but it's mainly used for games

It has a clean-slate design, and there's a ton of buzz in the Elm community about it. :)

[0] http://package.elm-lang.org/packages/mdgriffith/style-elemen...

[1] https://www.youtube.com/watch?v=NYb2GDWMIm0

h('ul', [ h('li', 'one'), h('li', 'two') ])

And use native array methods instead of v-for v-if and filtering data with component methods

This is even worse as for me. Generally the JSX/React.createElement approach itself and the fact that many people like the idea make me cry. Do people like it just because it's given by FB?

Why? Because tooling. Anything that's in JavaScript can be linted with ESLint, can be typed with Flow or TypeScript, is subject to dead code elimination by my minifier, can be shared via ES6 Modules/CommonJS wihin my project or NPM with no magic. All editors that understand JavaScript will give me all of their shinies (eg: tell me if I screwed up a conditional) without needing special framework specific support.

JSX itself used to cause these problems too (but createElement and the factories of old did not), but now that they're pervasive and that anything that supports ES6 supports JSX, I get all of these benefits for free.

The moment I hop into template/DSL land, I either hope there's a plugin with all the same benefits (often there is not), or I'm sad.

Note that people who use React + JSX and make stuff like "if" or "else" components fall into these problems too, so those have to be fully avoided.

Sometimes it might be useful, for small components,something like

   render: this.menu.sort().map(item=>h('li', item.title))

JSX is another templating language. One built on top of JavaScript rather than HTML.

I don't get this complaint at all. Between map and ternary expressions, you can get both loops and conditionals in your markup, e.g.

    <div>
      {listOfThings.map(thing => thing.isX ?
        <X thing={thing} />
        <Y thing={thing} />
      )}
    </div>

_renderXOrY = (thing) => { return thing.isX ? <X thing={thing} /> : <Y thing={thing} /> }

//inside the render method <div> {listOfThings.map(thing => this._renderXOrY(thing))} </div>

I personally prefer this because when creating the top level of a component, I largely don't care about the individual elements of a list, but rather am structuring how that list will be contained etc.

And let's not discount then the value that JSX brings of being able to easily unit test that your conditional logic renders the correct output easily (Jest + Enzyme = easiest tests I've ever had to write, bar simple functional checks).

Having the ability to see exactly what's in scope right next to the markup to me is invaluable - one of my biggest dislikes in templating languages is swapping between files that define the data in the scope and the template to use said data.

React forces JSX use, so a lot of times the battle between Vue vs React seems to be Vue Templates vs JSX which never makes sense to me.

Btw you missed :

But it means you don't have to learn a library's HTML API.

Or when you want to loop through myList, but exclude a few particular items... you know how to write that in JS, but have no idea what to do in the mark up language. You could create a filteredList, but it's often not ideal

I don't really know JSX much and without a specific example this is pointless to discuss. But basically JSX is syntactic sugar over javascript. A ternary is just a "if" condition so I don't see where is the issue here. Are you really using a template language devoid of conditionals? Even mustache the "logic-less" template has a form of it.

> The XAML file, as the HTML layer, should be completely devoid of logic and should delegate the whole work to the underlying model

The role of the model is and has always been to handle /business/ logic not presentational logic. If you put your dirty presentational logic inside my models I can tell you I will /never never/ accept your pull request.

* You don't know JSX

* You have no idea of the specific example posted in this thread that I'm speaking of

* You have no idea about WPF and what is a view model

But nonetheless you feel entitled to discuss about things in which you have zero knowledge. This is the JSX code posted in this thread:

<div> {listOfThings.map(thing => thing.isX ? <X thing={thing} /> <Y thing={thing} /> )} </div>

Instead of this monstrosity in XAML would be like this: <ItemsControl ItemsSource={Binding ListOfThings} />

But of course for you is better the JSX code. Luckily for me you will never have to review any of my pull requests, I seriously doubt that you can accept something that you don't understand.

It gets really old to see people try failed experiments over and over again, which pretty much is what you are suggesting.

Also, you got some display logic in your examples there, buddy. If you can't see it then no wonder this conversation is going in a circle.

https://msdn.microsoft.com/en-us/library/system.windows.cont...

What is that if not an horribly verbose switch case for modifying the representation of different elements passed to the ItemsControl?

I am not advocating that the JSX is particularly pretty or clever. I am objecting to your crazy notion that there should be no logic in the representation layer.

<ItemsControl ItemsSource={Binding ListOfThings} />

If you are looking for exactly this feature you might be disappointed.

> Although not strictly associated with the MVVM pattern, Vue’s design was partly inspired by it. As a convention, we often use the variable vm (short for ViewModel) to refer to our Vue instance.

I am sure it wouldn't be very hard to develop such a layer within React if needed.

Easy, just create a computed property in Vue.

If your point of view is that a model is meant for more than just doing the view, then yes, adding view only fields may pollute it for others (e.g., analytics).

But if your model is meant to drive the view of the app, then the story is very different. And some times you can't even tell if the model is just there to drive the view our not, since requirements change often.

I feel like this is often the reason people dislike React, and it mostly comes out of a misunderstanding of JSX and es6 syntax and interaction. Why do I say this? Because I've yet to hear an argument that came after a statement like above which was actually true in any way. Most arguments that come after actually expose the fact that the author of the statement simply doesn't understand the syntax usually because they've never really bothered to try to use it and instead are simply turned off by something new in their code.

> It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading

This is quite simply false, it doesn't force you to do any of these things. A lot of people seem to think it does which again comes from a misunderstanding of the syntax. You're quite able to either embed your logic into the JSX or not, whichever you prefer. I most often see people lean toward the former unless the logic in question is extremely complex in which case it could be argued it's best being removed from the markup anyway. But JSX itself does not force you either way.

> It's like writing shitty PHP code without templates

I simply don't see a viable comparison here at all.

> It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc.

Again, this is simply untrue. In fact I'd argue that if you're using lots of .binds you're doing it wrong. .binds inside your render function are actually bad practice due to the fact that they mean you're adding overhead of creating new bound functions as each .bind returns a brand new function every time your render tree executes. The overhead of such is probably negligible, however it's still inefficient and cumbersome and thus is bad practice.

As for Object.keys() - While I share your dislike of the overuse of this particular method, I'd love an example of where you think this is forced on you by JSX because for the life of me I can't think of one.

> There is no official React router

This I completely agree with, it is annoying, and I too am not a fan of react-router. However it's so easy to create your own routing setup and/or plug and play other lightweight ones that I don't usually think of it as a particular plus/minus point when comparing to frameworks like Vue.

here here! This has been my experience as well

And HTML string template languages have been shown to have numerous shortcomings at scale.

SoC comes from MV* architectural patterns. In real world front end applications, people who separate based on the file extension often end up creating JS files that breach SoC - they are both handling view rendering as well as application logic inside a JS file.

If there is something that should be conditionally rendered, using JSX is no different to a template language - only thing is the variable you're using to do that isn't actually in that file either (so, over-separation of concerns?). Both of these are logic - one handles it inline and the other handles it across multiple files.

No one is advocating that JSX should break SoC (a component should never talk to an API, or implement business logic - it should be responsible for given a set of inputs, it will render the same output time and time again).

Just use ockham's razor, would you suppose he misspelt a general language construct or created a whole new one? :)

I can end this post here, but I want to mention one more thing I'm reminded of: In Sherlock Holmes TV Series (don't remember the episode), a woman dies while writing "Rache" in her own blood. Other characters tell him that Rache is revenge in German. Sherlock posits that she was trying to write "Rachel", a much simpler (I mean with less assumptions) assumption to make in the context.

"HN Pedantry" is rubbing off on me :D

Just look at any component that dynamically generates CSS classes. Template strings with ternaries? Another dependency for generating nice CSS class strings? Give me a break.

JSX falters because JS is not terse enough. You end up with templates that have neither readable logic nor readable markup. And naturally, programmers being as lazy as they are, these templates become a holding bag for -every- concern.

You could theoretically write some template components and "avoid" javascript altogether. I wonder if anyone has actually done that?

JSX isn't perfect, but I find the dirty things about it can be mitigated by keeping your components small, and if that isn't possible then keeping the render function small by breaking it out into several functions that return pieces of your markup. Writing small functions is sound general programming advice, but it seems especially true with JSX/React.

We used it, but once you start using libraries like that one or MobX, why even use React at all?

Well, you've got a point. I can realistically see some developers preferring to piece-meal their front end solution though, or build just the parts they need themselves. I like Vue, but the API seems enormous. I get that a lot of people like that about it, though.

IMO the argument that React's API is really small is a fallacy since React is but a small piece in your project. You get nowhere without a router, local and global state management, transitions, etc.

The other factor to consider after the learning curve is productivity. Vue has a pragmatic nature and in my personal experience I can get the job done faster.

I think React is idealistic.

http://objectivism101.com/Glossary/Idealism_Pragmatism.shtml

You can go through the entire docs in less than an hour and get down to business. I did not have this experience with Angular 1 (don't know about v2) or React.

I just feel JSX is too awkward and verbose to be pleasant working.

> you can write cleaner code by separating your logic/UI

That's precisely the point of using a templating language: separation of concerns.

JSX mixes producing markup with your component logic.

> This look more like a rant overall.

There is a difference between an opinion and a rant. I really won't debate whether Vue is superior to React, I'm just stating why I prefer it.

What does this mean? I have a sneaking suspicion this is a symptom of poor separation of concerns.

https://facebook.github.io/react/docs/lists-and-keys.html

Since JSX mixes logic and markup indistinguishably I'd say that's where the poor separation of concerns really is.

  const listItems = numbers.map((number) =>
    <li>{number}</li>
  );
  return (
    <ul>{listItems}</ul>
  );

  return (
    <ul>
      {numbers.map((num, i) => <li key={i}>{num}</li>)}
    </ul>
  )

The problem IMO is that it's harder to read and write than:

    <ul>	
        <li v-for="num in listItem">{{num}}</li>
    </ul>

So many initial questions that just aren't there if you just use Javascript.

v-for="item in list"

if you need idx:

v-for="(item, i) in list"

pretty standard stuffs

When I'm trying to digest a bit of code, the superficial representation of what's present on the page is only half the battle - I also like to understand what it's doing under the hood. For me, then, JSX is way easier to grok than this bit of code, since I have a mental model of how JS works, and JSX is just a very small serving of syntactic sugar to compile an HTML like template into native JS. I know the transformations that are happening, and I can envision the code that it's being transformed into.

So is this really a problem?

Classic MVVM pattern

I don't understand how

    <ul>	
        <li v-for="num in listItems">{{num}}</li>
    </ul>

    <ul>
        {listItems.map((num, i) => <li key={i}>{num}</li>)}
    </ul>

What someone has to know to parse your vue example is the exact syntax for for loops in vue, evidently the syntax in this example is quite simple but what if they want to perform extra logic in that loop to modify which elements to show? In the react example all they have to do is know javascript.... in Vue they have to go look up how to do that in Vue.

  return (
    <ul>
      {numbers.map((num, i) => (
        <li key={i}>
          {num}
        </li>
      ))}
    </ul>
  )

The advantage is that it is statically checkable with a linter, so you would get a compile-time error if you misspell the HTML tag, a variable or anything else.

If you use something Typescript, the compiler will even check the props given to components (and if you use VS Code, you'll get auto-completion for variables, methods, props and anything statically checkable). You can even apply inheritance to components for dynamic component switching.

I briefly used Vue before switching completely to React (with Typescript, Webpack and Mobx) and it finally became enjoyable to write Javascript applications.

And why are there no interest? Because it is from Ebay? I mean look at the reply and no one even want to touch on it.

I'd say there is no interest because the single file components are quite new, and before that the project was focused on being a really fast templating engine.

https://github.com/marko-js/templating-benchmarks

Check this presentation about Marko, I found it illuminating.

https://www.youtube.com/watch?v=i6eZA8Y_GgA

Marko is also the only framework that supports server-side rendering streaming. This means that your user will start to see HTML even before the page has finished rendering. Afterwards, the page is bootstrapped and components run on the client side. It's very fast.

1) It's a templating language, not JS, not ternary operators, etc. Where this really makes sense is the following (probably valid marko). I _dare_ you to rewrite this simple search-results component in your FE framework or programming language of choice. Note how "state" is transferred in to a component

.../components/my-component/index.marko ``` <await( results from component.resultsPromise(state.search) )> <ul if( state.search && results.length > 0 )> <li for( r in results )> <!-- the "a href" will be prevented in a single-page context --> <a href="${component.getLink(r)}" on-click('emitEvent_ResultClicked', r ) >${ r }</a> </li> </ul> <ul else> <li><i>no results</i></li> </ul> <await-placeholder>Loading...</await-placeholder> <await-timeout>Timed Out!</await-timeout> <await-error>Errored Out!</await-error> </await> ```

.../component/other-component/index.marko ``` <div> <my-component search="whatever user searches for" on-result-clicked('handleUserSelectedResult')/> </div> ```

2) It's like PHP (mostly the good parts) ... there's only one negative I currently have with marko and that's the deprecation of "<var />" or "<scope />", as with "really large templates" (already an anti-pattern), the lack of scope can cause variable shadowing.

3) you can break out into "just javascript" at any point ... `$ var xyz = 1 + 2 * component.functionAbc( 123 )` and then use ${ xyz } right after. I personally prefer having `scope...` in my arsenal so I don't accidentally re-use `var xyz` but it's really rare if you make small components and keep an eye on your refactoring.

4) It is _designed_ for both "virtual dom" + "HTML streaming" ... virtual dom is what helps diff trees efficiently (client side), but HTML streaming is the real genius. Given a relatively declarative template (which is what marko deals with), marko will actually take your "foo.marko" and literally compiles it into: "make_a_tree(...)" or "make_a_string(...)" which runs on client or server respectively.

Seriously.

``` $ mkdir foo && cd foo $ marko create xyz $ cd xyz $ npm start $ open http://127.0.0.1:8080/ ```

Follow along with the docs / tutorial and then humor me and run the following:

``` $ npm start $ curl -s http://127.0.0.1:8080 | wc -c 5388

$ NODE_ENV=production npm start $ curl -s http://127.0.0.1:8080 | wc -c 1678 ```

I've used angular 1.x, ember 1.x, a touch of react, and I'm most hopeful for marko, as I really see a way for an SPA to start up using the smallest-possible-html-bootstrap, marko to download after first paint, attach handlers, etc. and be "as active" but "as quickly as possible" ... harkening back to the "good old days" of PHP and JSP where the content rendered quickly ... mixed in with the "good days of today" where subsequent page renders don't just blank out the browser, but instead, efficiently load up only the changed portions (ie: the SPA / single page app / progressive experience).

It's easy to do a "progressive" experience requires a 1MB download of JS before first paint. It's actually really cool to be able to render a 100kb page in only 100kb of network traffic, but also to have all your handlers / regular JS working from the remaining 900kb ready to work automatically _enhancing_ your page, but not to have to make any tradeoffs or think about it in order to do it.

Also the scroll jank on markojs' homepage doesn't make me feel extremely bullish about the framework.

I don't think you or your team knows how React works or even PHP.

> Another problem with React is that it only really solves one problem.

You and your team hate React for the wrong reasons. You just simply don't know what React is in the first place. React is not a framework, is more like a view framework, it was never designed to solve routing, models, problems.