Templating languages: The hidden costs - Fun Fun Function

[@RealToughCandy]

You are the coolest JavaScripting Swede on the planet!

[@funfunfunction]

aww

[@marcustulliuscicero9512]

ayyyyyyyy

[@mishelashala]

I noticed something on your hair. I was not able to put attetion the whole video.

[@funfunfunction]

The amount of likes on this comment suggest that there might be statistical correlation between OCD and software development.

[@danilorechi7998]

I hadn't noticed until now. Now there will be 25 minutes of video and trying to hide that little thing

[@BillChmura]

Thanks for the idea... was driving me nutz, scrolling down a bit helped.

[@codenamesteeveknight673]

there's a hole? in the video?

[@sheriffderek5333]

Time to go to the doctor!

[@wh33lers]

What about the benefit when involving designers or non-scripters/developers. They can design around logic and understand the template without knowing any programming. Isn't that the main reason they came up in the first place?

[@klepas]

Yea, this was my main thought while watching this - eg. as a former designer I found something like Liquid far more approachable than trying to learn JSX. Also, while we’re in the domain of JS web development, I’d happily take another dependency that does something [templating] well, considering your average node project has fuckloads of dependencies already (or, ditch node altogether :P). *hides* (: Thanks mpj

[@ingliss]

I agree with this and @siRtobey 's remarks below. I may be personally sold that pure JS and function composition is a huge win for stack simplicity and flexibility, but there are other scaling issues when less technical resources are brought into the mix. I can probably sell someone managing a few Jade/Pug templates with an automatic rebuild, but I won't get far asking them to brush up on currying (admittedly a more advanced case). Once I've accepted this, it's a short step to mandating templating DSLs by default in a project. I love projects where I can dictate these things - and fortunate to work on quite a few like this - but it's not always the case. This is a very clear explanation of the benefits and trade-offs of each approach though - thanks to mpj

[@funfunfunction]

About currying - you have to remember that the template equivalent is creating components and plugging them into the system.

[@SPCPerez19Delta]

I suppose you'd run into that in smaller shops but once you get into larger companies, roles are clearly separated so a designer will NEVER need to touch code (as they shouldn't. They're creatives...)

[@klepas]

ScoutsOut! I hold the view that everyone benefits if designers can engage with your frontend team; designers are best at their job when they better understand the medium they are designing for. (:

[@brianzelip1852]

Loved the pauses built in to this vid for us to think on our own about the code. Great vid!

[@funfunfunction]

+Brian Zelip I'm trying them out for the first time, glad you liked them!

[@AndreiHognogi]

I think you left out one big reason to go for a templating language: plain html works inside a view. Most of the time I do front-end before back-end, such that the client can approve the layout before I actually implement the functionality. Creating the view in the framework means just copy-ing the html, and adding the interpolation statements. To do this with plain js would mean converting a lot of html to js, and any subsequent layout change to make, means editing js, and not html. Although using plain js seems a brilliant idea, for me, the advantage of doing front-end outside your framework, it's the main reason I use an html-like templating language (doT.js)

[@StephanHoyer]

Copy and pasting might solve your issue in the first place, but than you have to maintain both versions. A better solution would be using same engine for frontend and backend. And this than also solves the other issue quite elegantly

[@funfunfunction]

Yeah, this is one of the reasons why JSX exist in React. It's a thin layer with low complexity that gives you the "pasteability" among other things. So it's not really a benefit of templating languages per se (the actual language parts of template languages don't parse in browsers).

[@DeepDarkier]

With JSX its basically copy, paste, change "class" to "className"

[@funfunfunction]

Yeps!

[@gycom]

Rocket surgery? Is this to express composability of complexity? Rocket science + brain surgery? Bravo for your show

[@funfunfunction]

meta, this is.

[@DigitalMonsters]

Seen this a few times ^^ Love Mitchell and Webb

[@error.418]

It's not a unique joke, it's just making fun of the silly idioms "not rocket science" and "not brain surgery"

[@dsego84]

DHH is known for saying that

[@tylerwaters3384]

Thoughts on EJS? Many of the arguments on complexity due to bringing in another language is a bit moot - it's quite literally html with javascript spliced between strings delimited by

[@ChristopherOkhravi]

The composition argument convinced me. Thank you, I believe you are right.

[@HumanoidTyphoon91]

9:00 Just a question, couldn't be `class`, a reserved keyword, be used as an **object property**? It's not a variable. x = {class: 1, private: 2} works perfectly in my browser.

[@sirtobey1337]

What I feel is completely ignored here is, that for UX designers, this is a lot harder to understand. And with big apps, I suspect that it'll turn into a spaghetti like cluster in no time aswell.. Just feels like we remove some downsides of templates, and introducce a lot of other hidden costs elsewhere. I'm not sold on the idea, really..

[@funfunfunction]

Yes, if you don't know JavaScript, then of course you will have a hard time understanding something written in JavaScript. That said, I think JSX (written in a simple way) and a templating language are VERY similar in understandability for a designer. For the other parts, you are expressing fears, but you're not actually expressing your reasons for feelings those fears. Can you talk about why you think it will turn into spaghetti? Can you talk about the hidden costs elsewhere?

[@sirtobey1337]

First of all: I have never used Handlebars outside of EmberJS, and I do very much like the concepts of EmberJS. Let me try to phrase my concerns: I am not a very seasoned veteran in development. But so far, every project I caught a glimpse into or worked at, every single time things tend to get messy when you introduce more and more functionality. You talked about this or similar issues a lot and also ways to deal with it. But in reality, this still happens again and again. At my job I work with Java in several projects. Java is not very opinionated (and most frameworks aren't, since it kind of contradicts the idea of extendability - which I personally find to be a myth btw), so what basically happens is one of two things: Either some senior developers really think a lot about some a reasonable way to organize a project (.java files, maybe template files, .xml files (yikes), etc., where to put entitie-classes, where to put logic, and so on..), or you'll have a half-baked, improvised project structure that varies for each and every project. If you're lucky, you may have similar structures in project, but since you will learn a lot everytime you structure a project, each newer project will be a little different. But even here, you inevitably will run into (let's call them) placement issues, where it will become hard to find what you are actually looking for - especially for juniors. Why this is relevant for working with "native JS templates": Well, you will most likely begin to isolate generic functions (like some of your examples in the video) for lists. You will try to order them in a meaningful way - and most likely fail due to changing requirements during the project, or just as often lack of time. While I really love the idea of currying all those functions, you will build up quite a chain of dependencies on other functions elsewhere. So, much like in most Java projects, you will either have to duplicate code, deal with too generic classes (and thus too many layers of abstractions than actually necessary) or run into funny side effects. (I am aware of this not happening, when you stick to actual pure functions, but let's just say, that temptation is a bitch to just change something because it's easier under pressure) And then you've lost most of the benefits of actually using JS instead of something like Handlebars. Maybe this is too pessimistic of a view, but I ran into similar problems, and not just in Java projects, also PHP, Python, etc. in my short career. As I see it, shifting to native JS for templateing seems elegant, and surely is tempting. But so far, I feel like it will introduce so much arbitrary project structure, splitting of generic, pure functions (you will also have to import in JS, making a small component file a lot bigger than a small handlebars snippet) that it will be just as hard to change and hard to read, as some slightly extended but well structured EmberJS handlebars template snippets. This maybe has less to do with the idea of "native JS templates", but my dislike for loosely structured, unopinionated frameworks. But many of your points seem to not really apply to an opinionated framework like EmberJS, or Phoenix (although I haven't seen a "real" Phoenix project). I just feel like "native JS templates" as you've shown in scream for wild, arbitrary project structures, which in the end consume a lot more time and brain matter for juniors as well as seniors in development, than learning some handlebars will. I am giving this the opinionated-vs.-loosely-structured spin, but not by accident. As far as I can tell, most opinionated frameworks tend to be much, much easier to learn and in the end have much more impact than using "the right tooling" ("native js" vs. Handlebars). I'm not trying to argue, that Handlebars is perfect. It's not, otherwise there wouldn't be extensions for ember-handlebars that provide Handlebars in Ember with functions you can just program in JS natively. But your argument against plugins really falls short when using Ember. It's simply not an issue, because it is handled by Ember. It just feels like Angular and React try to solve problems over and over that Ember, imho, has solved a long time ago. And no, Ember is not perfect, but I'd prefer Ember over a React Application probably anytime, because once I know how Ember projects work, I can understand what's going on in very short time - with any generic React/Angular app, there is a high chance I don't even within the same company tl;dr: I'm trying to make a point for opinionated frameworks. I'm not against "native JS templates" in general, I just don't think they add the promised benefit within such loosely structured environments - whereas the criticized template languages in a more structured, well designed environment like Ember actually don't suffer most cons but match many pros of "native JS templates". So, imho, we'd be much less concerned with all the reinventing React does, if we'd use it in a saner environment. :) I hope you can follow my somewhat chaotic train of thought. BTW: And let's be real, this is about JSX mostly, and JSX just simply isn't native JS. It has some upsides, and I wouldn't mind using it - but it just keeps and keeps attracting bullshit like styled-components or JSS. If you don't know it: It's basically "natice JS CSS". Y'know, taking the JSX-approach of bundling components with their representation in (virtual-)DOM to the extremes - putting any styling into JSX components. Ironically adding more plugins, making it impossible to reuse components in another app without changing them, and also making it even harder for UX designers to implement certain parts of the interface themselves.

[@funfunfunction]

I understand where you are coming from, and I'm not trying to invalidate your viewpoint. I understand the desire to impose structure, especially if your team consists of many junior developers. I have seen the horrors you describe, and I don't want to imply that I ignore them. However, the approach you describe comes from a different place than my values. I value simplicity and culture very, very highly and I'm also the kind of person that wants to fix problems at the core. I largely feel that my opinion on templates often boils down to those values - if you're doing weird bullshit in your team, my philosophy is that your team should WORK ON LEARNING TO NOT DO WEIRD BULLSHIT. There is another group that feel that it's more effective to add safeguards, process and structure to prevent your team from doing weird bullshit. I do not subscribe to this notion and do not feel that it's a sustainable way of creating quality software. I value culture and dislike when I see things that look like trying to fix culture problems with process or structure. I think those safeguards are like taking paracetamol instead of finding out properly why you're in pain.

[@sirtobey1337]

Interesting. I can follow your arguments, and I believe, that in a perfect world, this will absolutely work. (I also do not want to invalidate your point, btw) But there are circumstances, like the team I am currently working in (consisting of mostly seniors), that moved or got pushed into this groove mainly because there simply never is time to actually work on learning not to do weird bullshit. There are absolute valid reasons at the moment for doing things like they did and currently do, and doing otherwise would be based largely on personal opinion, not best practice (exceptions obviously occur), but there simply is never time to actually refactor bad parts, reconsider decisions. But this culture is forced upon them by business. You could argue, that this is also a culture problem, but that's the reality I had to face in most teams I worked in so far. So, I don't believe, that strict structure and process saves developers from bad culture, or even writing bad code. You can absolutely do that in Ember or any other opinionated framework. I believe however, that by fixing problems at the core, you are very likely to "fix" problems that have already been fixed over and over, and very likely better than most developers would try to fix them. And this is simply utopia in many business environments. So I'd rather stick to some convention that a framework (more or less) enforces, rather than fixing all the problems such an opinionated framework has already solved for 95% of the use cases over and over in a bad way because we lack experiance and time to do it right. And, to jab at Java one more time: When doing everything "the right way at the core", you won't necessarily get to a particularly good solution, as has been proven by many oh so over engineered Java projects that tried to do it the right way from the get-go. ;) But because I forgot to mention it in the first post: Keep up the good work! I might disagree with you on many topics, especially when it comes to React's philosophy, but I still do enjoy a good argument and your very well thought out arguments :)

[@funfunfunction]

Thanks for the great discussion, and thanks for your kind words! Yeah, I think this is two different viewpoints that are useful depending on context. I'm mainly concerned with building a team and largely view the product as a consequence, and in some contexts that is really great and in some context that makes me an unproductive obstinate idealist. In the teams I worked in over the years, the quality culture was very strong and there was an solid discipline around code review, testing, and it was a lot stronger than external pressures and we largely maintained quality while balancing business pressure (respecting and managing it, but not letting it indiscriminately hurt the product quality). We did have mandatory code review enforced by tooling, but for the projects where it wasn't enabled, people did it anyway. Services were kept small and simple even though nothing enforced that beyond culture. I firmly believe that this is how you build world-class software. I understand that this is far from the norm, but there was no magic involved in getting to that point, it was intentional improvements over the years that any team can do. And just to be clear, when I say fix things at the core, I'm mainly referring to cultural habits and issues, not anything related to what Java tried to do with it's "pure" OOP model, or anything technical really. I don't think there are much known "core fixes" for programming yet, except possibly some basics like minimising state, writing tests, and keeping things simple and easy to reason about (and HOW to reliably achieve the latter is not really known :)) A thought: If we could reduce cultural and knowledge issues with tooling, shouldn't we by now be able to observe at least some correlation between tooling choice and quality in software?

[@stevepascoe]

I've found native js can look ugly especially with lots of inline if statements used. Hard to look away from pretty handlebars 😆

[@harrypehkonen]

I think what's going on around 26:00 is partial application, not currying. I'm *really* liking the topic in this video, by the way! I have never really been comfortable with any templating language, but always felt like they (along with binding of some sort) were somewhat necessary.

[@chrisbenseler]

Another benefit of using a template language is that the way the view is implemented is standardized. Using some language/engine for it, all the team (seniors developers, juniors, newcomers, etc...) will have to follow its documentation/standards.

[@funfunfunction]

+Christian Benseler this isn't really a benefit from templating languages, the native js solutin has the same benefit.

[@ingliss]

Hi, 26:50, there's no link to the currying video that I could see (as of now)

[@funfunfunction]

thanks, fixed!

[@erickvoodoo1993]

kzbin.info/www/bejne/n4uvgWenhNyMbqs&feature=iv&src_vid=EmGfdlixQHo&annotation_id=video%3A0742baf3-2e6c-417f-a909-b1a789f75bd4

[@shaydenmartin4848]

This is actually partial function application, not currying. mpj's video explains currying correctly, I think he just got the two mixed up here.

[@sirtobey1337]

Using Handlebars in Ember is a charm, because Components provide everything you need, no need to worry about adding more tools to the chain, etc.

[@0mnilord]

#1. Complexity - Yes, you are including more code, but that code operates behind the scenes to bring in a helper language to *simplify* the work programmers need to do to craft UI. This is important because when debugging you are not looking at JavaScript, you are looking at real HTML, and debugging by comparing apples(DOM rendered HTML) to apples(HTML in template) will save huge leaps of time over trying to compare apples(DOM rendered HTML) to oranges(JavaScript). Whether templating languages are declarative and how well the separation of concerns are achieved are not important consideration. Templates simplify working with views. Writing a with "declarative" javascript style still requires learning a "new language," it's just an extra layer of abstraction AWAY from how the view is rendered that all developers (regardless of seniority) must come to terms with. #2. Social Cost - You will ALWAYS have to learn the new tools associated with the project stack. A good templating language doesn't take time to pickup, it's obvious what it is doing just by reading the templates. This is why React with JSX is so powerful, because it integrates the logic and the view markup in a meaningful and easily readably way, but it ultimately gets transpiled down to raw JavaScript for native client speeds. Whether you have to learn the DSL for a templating language or the API for your library, you still have a time cost associated with learning. The best choice is to choice an option that closest resembles the end result: HTML, this will result is the fewest surprises. #3. Loss of Tools - This is a moot point. Any time you implement ANY library, you are making trade-offs in flexibility by adopting the conventions and API of that library to the exclusion of similar libraries.

[@funfunfunction]

#1. Complexity. The only thing I tried to convey in this point was that you were pulling in yet another tool, and that pulling in another tool is a cost that you can avoid by not having a template language. Whether or not you think that the benefits make up for the costasis up to you. All I wanted to say is that you need to be aware of the cost. That said, about "simple"... I understand that you are of the opinion that a template language simplifies your code, but I don't think that is correct. I agree that it's more *expressive*, but not *simple*. Just to be clear what I'm talking about, I use Rich Hickey definition of the word simple (www.infoq.com/presentations/Simple-Made-Easy). Even if you consider HTML and JavaScript to be different domains (I don't: kzbin.info/www/bejne/ZouxeoSFhJemnKM) the template language is just as intertwined with the HTML as JavaScript is. #2: Social Cost. What I tried to convey that just because you can READ a template language doesn't mean that you can write it. It feels like one has learned it by looking at it, but in reality, you need to do quite a bit of learning in order to get how to work it. And yes, all kinds of stacks have learning costs, what I tried to illustrate in this segment was that templating languages add a little bit of it that you can avoid by using something like JSX instead. Note that when I say "templating language" I AM NOT referring to JSX! (Nor do I consider EJS to be a templating language) In the video, I talk about the "native js" solution but I might as well be talking about JSX - I just decided to leave it in an attempt to make by point cleaner, not sure if that worked... Many people think JSX is a language, but I think calling JSX a language is a VERY long stretch of the word language. The JSX transformer takes ... return Hello {this.props.toWhat}; and transforms it to: React.createElement('div', null, `Hello ${this.props.toWhat}`); That's ALL it does. It doesn't even change your line count. It's a silly-simple transformation. It's a LOT simpler than something like Handlebars. It doesn't have any concept of loops, plugins, data, or pretty much anything really, so it doesn't hold any of the extra costs that templates have that I talk about in the video. #3. The point that I was trying to convey is that introducing a custom language into your stack has a *bigger* tooling impact than introducing a js lib. For example, If you do a typo in a native js "template", chrome dev tools will give you the correct line number and you'll also have all other debugging perks, while that is lost if you use handlebars for instance.

[@WMTeWu]

result = items .map(formatCurrency) .reduce((a,e) => a += e, "") .map(lis => lis) .getOrElse(No items found)

[@FenrirRobu]

WMTeWu This is why template languages were invented in the first place. Just because higher order functions let you pack this logic in a tiny number of characters doesn't mean it's easy to reason about.

[@WMTeWu]

Actually the whole point of using pure functions is that they make reasoning about your code very easy. What could suffer in this snippet is readability. I can understand it just fine, but i someone less technical, who don't know what 'reduce' is about could struggle.

[@Aramizyera23]

I would replace that reduce by map to and join.

[@aleffsouza8736]

All my experiences working with template engines were really frustrating! I can't stand them. Awesome video! Hope to see you on Brazil.js this year again :D

[@FenrirRobu]

I really enjoyed this video even though it's not what I expected. However, my issue with the discussion that's happening here is that of merging at least 3 if not 4 approaches into two. From my early personal experience with both console applications (for example a calculator in basic) and entry into AMP stack, level 0 isn't React. It's printf("%d", price); Hence why most people will argue for level 1 (sorry that levels are kind of huge) which is a template engine: serialization, escaping, compilation, static checking, helpers. Yet this video isn't level 0 vs 1 but 1 vs 2. Level 2 is the crazy awesome place where you've merged the grammar of target language (XML) with your development language, and naturally provide means to have or introduce most of template engine capabilities whilst still supporting your native language. Which is actually where it gets really tricky for those who have worked with opaque massive frameworks, which ran the risk of failing to conform to language intuition with unexpected results. For example, Edge browser that has issues printing numbers to PDF: a complete nonsense that is hard to even imagine. But in that context: What happens if you pass this imaginary div factory an HTML literal as children. Will they a) render b) be escaped c) fail altogether because the children cannot be string encoded. And this is a feature that you can't really avoid because you need to include actual textual information into the templates otherwise they are useless. But if this library falls into c), you are at the mercy of serialization into the libraries format. Therefore, you are now looking at an extra layer that is imposed because you are merging the grammar of these languages. Though of course this issue occurs with regular template engines as well. The fourth aspect of this discussion, a sort of level 0.5 is code writing vs generation. Because what tends to happen is that people would learn HTML, without knowing the full clarity vs abstraction battle. So they are not familiar with the possibility that what they spent all this time studying could be used as a simple assembly language - one that is fully generated by the abstract engine. Neither would they recognize the arguments that sound pro-HTML or whatever direct method they are using, which are actually about clear code to the proverbial metal. Or as Linus put it - knowing how your C looks in assembly. That's why from a learning perspective and natural occurrence in new developers, templating extensions to the source language are very tempting as there's a very well hidden downside to them. Heck, give them WordPress or some other prerolled system and they might start coding as such in template engines. Which isn't great but that's level 0.5, with it's organic occurrence.

[@lnplum]

Just a nitpick: you *can* use reserved keywords as property names, even without quotes, you just can't use them as identifiers, i.e. variable names. The reason React uses className is that that's what the DOM calls it.

[@lnplum]

Note that ES3 and earlier *did* prohibit use of reserved keywords in nearly all places, though. So for oldIE you're not wrong and this may have influenced React to use the DOM name instead.

[@fernandocanizo8267]

Totally agree with you (@mpj) about the costs of adding extra tools to the process. Another point I believe you can add to the summation of costs is the *cost of copy-pasting*. I was sold Jade once and used it on a couple of projects until I found that every time I has some doubt about how to do this or that with Twitter Bootstrap and looked for it on Internet, then I had to reformat whatever I want to copy to the Jade format. Something which shouldn't been an issue if I were using plain HTML. BTW, you blew my mind with the usage of `.bind()` to do currying. I'm relatively new to the use of functional techniques in my code and so far I've always relied on some third-party library to provide me with currying ability. You've opened a new world to me now that I know I can just use `.bind()`. I'll watch your currying video again to see if that was mentioned there, maybe I just didn't pay enough attention the first time I saw it. Back to the theme of this video: excellent presentation. And don't mind the people that says: "What's the problem, just add some extra stuff". They're not aware or concerned about the growth of the projects.

[@morgunkorn_]

In my company, our framework outputs all the data as an XML document. Then we use XSL Transformation to render the HTML. There are many tools to make operations inside the templating language and it's very standardised. We end up also having to decide whether things should be pre-calculated and put into the XML (price formatting for example), or if the XSLT template itself should do the transformation. It gives more flexibility to the Front-End team, since they can do what they want in the template, otherwise they need to ask the Back-End team to add the info they need. It also helps to keep the framework relatively clean because small changes needed for 1 single project can be made of the template level without having to change the common base of the software. But we struggle to recruit people who know the technology and everybody learns from scratch. That was my 2kr :)

[@funfunfunction]

Thanks for sharing this, very interesting. I see some issues with your setup, I hope you don't mind that I muse a bit. XSLT has the same costs as what I mention in the video, except that it actually doesn't have the benefit of expressiveness, and also a pretty massive social cost compared to Handlebars (reflected in your hiring). > We end up also having to decide whether things should be pre-calculated and put into the XML (price formatting for example), or if the XSLT template itself should do the transformation. It gives more flexibility to the Front-End team, since they can do what they want in the template, otherwise they need to ask the Back-End team to add the info they need. Is XML your only data source? You don't have computed properties in the view layer or anything like that? If everything has to be calculated and put into the XML, doesn't that mean that the front-end team has to go to the backend team as soon as they need changes or additions of simple formatting logic? Isn't this pretty ineffective during development, that front-end has to ask back-end developers whenever they need to make a simple formatting change? Also, doesn't this arguably break separation of concerns - formatting currency is view logic in my mind and doesn't belong in the backend (illustrated quite well by the fact that you have to send client locale preferences down to the backend in order to pull it off). > It also helps to keep the framework relatively clean because small changes needed for 1 single project can be made of the template level without having to change the common base of the software. Well, for very small changes that only touch the very upper html layout perhaps, but for pretty much any reasonable change you'll need to involve more people because you're breaking separation of concerns spreading the view concern out over so many different places/technologies. Let's say that you need to calculate the total of the items in a cart, for example. Some other questions - How do you manage animations with logic in this structure (let's say, if you wanted to create a grid similar to the iphone home screen, where things flow around), or complex style states in general that cannot be expressed in HTML/CSS alone? I.e. what is your equivanlent of reactcsstransitiongroup?

[@morgunkorn_]

You are absolutely right, the back and forth between the Front-End and the Back-End teams has a huge negative impact on the productivity. In the end we mostly constrain ourselves to work with the existing data source and framework to avoid the roundtrip. It also means that we will avoid making design decisions potentially impaired by this limitation. Our software ended up having a very static structure with a few basic UI elements used over and over, at the cost of the usability. I can only dream of features like ReactCSSTransitionGroup in our current framework... I'll definitely present your arguments in our next meeting. There is so much legacy in our process, it is time to review a lot of thing :) Thank you for taking the time to share your insights!

[@LehelVass]

It's not fair calling JSX native JS, because it's not. So I don't really see the difference between learning a templating syntax vs learning the Elmish JSX. On the other hand Elm did a good job integrating DOM in their native language.

[@funfunfunction]

Sorry if the video was unclear - is NOT my intent to refer to JSX as native JS. With native JS I'm referring to react without JSX (i.e. this facebook.github.io/react/docs/react-without-jsx.html). That said, I think people overall think that JSX is waayyyy more than it is. It's not native JS, but it's VERY, very close. JSX literally just does this: It takes ... return Hello {this.props.toWhat}; and transforms it to: React.createElement('div', null, `Hello ${this.props.toWhat}`); That's ALL it does. It doesn't even change your line count. It's a silly-simple transformation. It doesn't have any concept of loops, plugins, data, or pretty much anything really.

[@niKolasBedoya]

Hey man, I am a graphic designer and videographer who has most of times found his way around the coding when is time to work with web...until now...I am working with a template within shopify and been struggling to change the functionality of this template in something apparently simple as change the catalog behaviour from pages to endless scroll down...don´t know how much of a warm and carrying heart u r but just by watching your video i can c how passionate u are about your craft...was wondering if u can give me a hand with the predicament that i am facing these days, which, Im sure is more like a joke to u or any of your followers and colleagues but represent a massive obstacle in my way...hope u find not just the sincerity but also the desperation on my request...great video by the way...is just enjoyable when someone speaks about what is close to his heart and sparks passion as well as inspires... stay strong and keep the good work Mr. MPJ !

[@kevinb1594]

Thank you for this. I am one of those developers who doesn't quite 'get' the separation of concerns and currently have a project I'm required to use Handlebars on. I cannot express my frustration learning Handlebars and getting it fully integrated in my project. Understanding the contexts, what THIS refers to and how to get data out of THIS took me a stupid number of hours to figure out when I could have simply wrote a JS function and stuck in the markup. I know that after this project is 'completed' if I sit any amount of time without revisiting Handlebars, everything I wrote will look foreign to me. I just don't see WHY template engines are necessary. Do you have a video on the whole separation of concerns / MVC? If not, I'd like to request one.

[@funfunfunction]

Learning proper separation takes a very long time, and you will, over time. Don't sweat it. :) But I have a separation of concerns video here: kzbin.info/www/bejne/ZouxeoSFhJemnKM

[@tiozz]

Well done! Nice video as always. Subscribed recently to your channel and love it. I have a background with Java and Objective C languages. It's always good to learn new topics from other frameworks, languages, stacks. Your functional programming playlist is an eye-opener. Keep it up.

[@funfunfunction]

So cool to see people with all kinds of backgrounds subscribing! Welcome to the channel, Dan, and thanks for your support!

[@David-iq1kd]

At 10:18, it looks like a "div" function has been created elsewhere correct? JS doesn't have a built in div(). What's the modern way to create these kinds of html-as-function functions? String template literals? Do you need a tag function? Or are people using libraries for this like Van.js?

[@funfunfunction]

What I use for fff.dev is SolidStart

[@David-iq1kd]

@@funfunfunction Thanks! Does solid start / Solid provide HTML DSL/Functions then with things like div() as a function? The solid and solidstart docs seem pretty JSX focused, so I was curious how you personally go about doing your functional html-in-js like the video's pseudocode seems to show, such as the div() shown in the video as a js function not jsx. Could it be Hyperscript? Thanks :)

[@jkennethking]

Long-time lurker of your channel, first time commenter. :) One thing you didn't cover was performance. I'm not too familiar with the front-end but I know that on the server side where we've worked with template languages for a couple of decades now it became apparent that they were useful for performance reasons. It required fewer allocations and and resulted in faster rendering times if we compiled the templates beforehand and implemented an interpreter to render them. I'm curious why some projects are trying to move their JSX rendering on to the server. I suspect that performance may have something to do with it.

[@matheusazzi8272]

Congrats for the video, that's a good subject! In Vue you can use render functions too if you want, like: ``` render: (h) => { return h('div', [ h('h1', 'Hello world') ]) } ``` However I feel more productive when using templates. I think the problems you mentioned by using a template language are easily avoided, especially with Vue. I understand your point of using just javascript and I like that too, I've worked this way and I've played a little with Elm, it looked very interesting, but I wouldn't use it on every project, because as I mentioned, I feel less productive and it has a learning curve to the team I work with. Templates are easier to reason about IMO, and JSX looks really odd to me. A typical JSX view is fully of ternary operators and especial syntax (e.g. className, htmlFor), things like that happen often: gist.github.com/GianlucaGuarini/a3a95ad996d5bdf20970adf68922d059#file-routes-jsx As you mentioned in other comments JSX isn't so bad when written in a simple way, but usually I don't see that. I've saw some JSX large codebases and it seems hard to maintain. When using React I would prefer going with just plain JS as you demonstrated rather than JSX, and with Vue I'm using and enjoying the templates. You've talked about how Separation of Concerns are confused with separation of technologies, I agree again, one thing I really like is the Vue Single File Components vuejs.org/v2/guide/single-file-components.html If you're interested in seeing it applied you can check one experiment I made: github.com/matheusazzi/shop-vue

[@arsal123]

MPJ What is your opinion about typescript as compare to native javascript? In an angular 4 project, would you prefer to use typescript or would you use simple javascript?

[@JoshuaHeagleDev]

I love that obvious remark: "Just don't put Imperative, elaborate logic in your views. Just stop." I am employed as a PHP developer and this is always a MAJOR contentious point. Everyone wants to implement their own enforced framework with opinionated syntax and unique flavour of templating language. On my own time, I am actually a JS developer because it is much more enjoyable. I am always trying to convince my peers to watch your videos, but not everyone wants to be a better developer on their leisure time I guess. Thank you for your very informative and entertaining videos. It is nice to know I am not the only one who has these feelings and views about programming and being a developer.

[@TheKievsash]

Hi! Light sources on both sides is a good solution! Adding some big tree in the flowerpot on the left side will be good a well I think

[@mybigbeak]

Been using golang html/template. Had a similr problem with summing. I am now seriously considering tryinng a more dom building lxbrary. Will take. Peek an. Consider options.

[@dovh49]

You can used reserved words in objects in JavaScript. I don't know what the technical reasons that were used to exclude 'class' but it works perfectly fine! Maybe it was because the React guys came from different languages and didn't realize how flexible JS is?

[@abc-yg6tk]

14:10 Exactly. I use both react and vue and I like both. Each has goods and bads but I really dislike the v-if-else-if stuff in vue. Just why??? Just don't write a lot of logic in your react views! This is why we have code reviews. It's so much easier now to separate view from logic in react using React Hooks.

[@GothAlice]

Up to the halfway mark at this point. It's unfortunate, but there do exist "template languages" that neither introduce a new language wholesale, nor restrict imperative use, nor have a syntax specialization focused on one particular type of markup, sacrificing neither power, nor declarative simplicity. You also seem to conflate transactional isolation (the primary form of isolation most template engines strive for) and declarative behaviour; very separate things. Templates serve two functions beyond merely rendering themselves: isolation and componentization facilitating re-use and maintainability. Readability is a huge part of that maintainability, and the native examples given are… patently unreadable-ternary operator?!-and a testament to the willpower of those willing to accept such a syntax. A little abstraction goes a long way, similar to asking users to search and replace text in a document. Most users will use a graphical text editor with search and replace, while some really just want that extra bit of performance or geek cred involved in using sed and awk in a BASH shell. This is a difficult presentation to extract specific points from. This whole thing seems to be a major issue in JS because runtimes don't expose interpreter details such as parsing, AST, and dynamic compilation (beyond eval), requiring advanced template engines to utilize pre-processing steps (e.g. handlebars precompilation) whereas in other languages (Perl, Python, etc.) the runtime is more introspective, mutable, and amenable to light-weight alterations of behaviour during runtime, while also offering rich object behaviours that lend themselves well towards this use. Case in point from your example around 6:50 in: ${item.price >> formatCurrency} or similar might show up as ${item.price | n, formatCurrency} in Mako, a real Python engine. Both, I can agree, are sub-optimal. Objects should know how to render themselves; JS has .toString(), Python has .__str__() (called via str() type invocation with an object having that method as the argument). Of three options ${item.price} is the only one I find visually acceptable, and variable substitution is something we've somewhat ironed out in the last 40 years-this matches BASH and Makefile syntax. DRY: do you define that "pipe" filter chain every time a .price is referenced? Having an engine that knows to utilize such methods means that's one less thing for a front-end developer to worry about; no more "which i18n function do I use for this" or accidental inconsistency ever again. As others have mentioned, front-end designers and integrators (the integrator title often being generalized under "designer" to counter the counter-arguments mentioned so far that designers don't deal with HTML) _need_ to be able to work with the resulting code. No integrator I know would look at the native JS example and find that acceptable. We have these abstractions and simplifications for more reasons than preventing people from shooting themselves in the foot-which is faster to write? For a designer capable in HTML and CSS, and not JS? Which allows opening the template itself in a browser to see an un-interpolated preview? (Some XML engines are fully "design-able" without actually rendering, up to and including the use of WYSIWYG editors, which is neat.) I do agree entirely that having a substantial distinction between the two is unfortunate. I see this as template engines "solving problems" that are already solved at the underlying language level, at every level of engine design. That engines typically involve a chain of events like "new Template().fromFile(path).render({… data …})" disturbs me, when underlying languages that know how to require/import/include other modules already represent that exact chain of events. What is a template but a module containing a function to render the template? (In the same way that basically all programming languages boil down to RPN stack evaluation, especially bytecode interpreted ones.) Lastly, there is actually an optimum processing approach (regardless of initial storage representation) for a given template process. This can be worked out and backed by benchmark evidence. In many this revolves around array or list extension and eventual joining. In others, string concatenation. What I truly care about is that the final executed product, whatever that may be, utilizes that optimum approach, and that my front-end folks don't need to also be back-end folks, and don't require a complete back-end in order to develop and test. I would really love your input on the design of my own engine, github.com/marrow/cinje#readme - It's still Python, not JS, but takes an approach based on Tenjin (which is available in JS) and the presentations the author of that engine gave on optimal approaches to engine design. Notably, however, it exploits as much native language support as is possible (e.g. it does not contain a language parser, AST manipulator or code generation, source file saving, or bytecode caches, as all of that is handled by Python,) and treats templates as native modules containing rendering functions for direct import and use by the back-end. It merely flips the script: where Python code uses indentation to denote scope and line-trailing colon markers to denote block control flow (e.g. if …:, else:, etc.), cinje colon-prefixes all Python lines (with minimal transformation for functions, no transformation for other lines), ignores indentation, and treats all others as implicit buffer.extend() calls with constant strings or ${} variable expressions. It's faster than Tenjin, the translated code simple and debuggable, seamless import unique, as declarative or imperative as you want in either direction, and can be wrangled such that production deployments don't actually require the engine itself be installed at all. Thinking of templates as "templates for functions which generate the text" vs. "templates are the text" can be a subtle distinction, and as anyone in Java can attest we use code generation a lot in the modern era. Have the IDE refactor a class name and all reference for you, or sed/awk again? ;)

[@GothAlice]

TL;DR - Search and replace / IDE refactor your code, or sed/awk it yourself? (Use advanced electronics designed to hit tiny targets, or trust in the force?) This isn't a problem in interpreted programming languages that expose language tools, such as parsing, to the runtime, and my cinje engine in Python is a demonstration of one I feel counters every single point made.

[@maxtaylor3531]

Is it considered bad practice to add methods to the basic objects prototypes like Function or String? I recently added a format method to the String objects prototype that works as follows: "Hello {0}. I am {1}".format("Geoff", "Happy") would return "Hello Geoff I am Happy" However, something about modifying these objects seems wrong. I also added an inherits method to the Function objects prototype. Is this bad or can I get away with it?

[@Powerslacker]

@funfunfunction what do you think of preprocessors when creating static / semi-static sites?

[@HappyCheeryChap]

This video is excellent! And very much confirms why I'm switching back from Vue to React. I wanted to love Vue, and it was easy to get started (and probably still will recommend it for small projects that used jQuery in the past)... but as a long term (mostly backend) programmer who is used to decent tooling and error reporting, too many things just silently fail (or give very inaccurate traces/errors) with templating languages... whereas you get proper errors and tracing in regular JS/JSX. Also very excited that Next.js v9 is out now, and includes 1st class TypeScript by default out-of-the-box. After about 20 years of mostly hating it, I'm finally starting to enjoy frontend dev now that things are being done more with proper traceable code features rather than the old ways of copy & pasted strings everywhere, and the constant existential pondering about whether those pasted strings are pointing to undefined values. Keep up the awesome work man! These kinds of videos confirm you're making not only the best programming videos on all of youtube, but also teaching important general principles that stand the test of time!

[@BogdanMariusCalapod]

I agree that templating languages are limited and most of the time they are overkill, but I do see one use case for them - E-mail templates. The simple plug & render nature of templating languages lends itself very well to that.

[@DrRobrez]

it's worth mentioning that the HTML spec contains templates... it is as native as it gets. plus, browsers are optimized for such markup... native custom elements have been demonstrated to outperform rx and offer imperative or declarative operations just like any other native element

[@funfunfunction]

Note that we're concerned with template LANGUAGES here, not the more general concept of a template.

[@firehawk895]

Hey mpj. Been your fan for a very long time. Had a completely off topic question. Is KZbin now your bread and butter now that you have left Spotify? Or are you freelancing as well :D very curious to know.

[@noureddine2228]

when did he leave Spotify?

[@funfunfunction]

Announcements coming soon. :)

[@jean-guillaumeburet1068]

I guess you've been hired by Google... as you said you've been training for it with your friend.

[@TheQueue841]

I view templating languages as being in the same family as Sass or TypeScript. They're more of an extension of HTML, in the same way that Sass/SCSS and TS extends CSS and JS, respectively.

[@leonk6950]

Coming from a java background, could this be compared to swing ( where you create your windows and window-items in your java classes directly, using things like JPanel.add(new JLabel("label")); and such) Vs something like javaFX or how you design android Interfaces, describing the layout primarily using XML and then connecting the interface logic to it?

[@georgburgstaller9985]

@mpj Talking about React are you trying to have as less classes as possible and how do you style your react components?

[@PankajPatel1]

It always happens that I going through some brainstorming in past 1 or 2 weeks and there you come up with video on same or similar topic. I had been diving into WebComponents and the main effort is the HTML rendering; if you go native JS, you end up creating too much ugly code and if you choose templating engine, you end up with a burden on your webcomponent. The solution I thought of was to use native for small components and thin templates like hyperHTML, DoT etc for others. And keep the templating engine plugable to web component so that it can fit into the regular project flow. This video helped; gonna use native as much as possible, because as a JS developer we are already on the edge of having new tools and libs every(day||week) and native will only last longer.

[@microflow2929]

Playing with Elixir/Phoenix EEX templates now. I find them easy to learn... Will be interesting to hear your comments.

[@WTHBrou]

What's your current opinion about this? Since now you can use variables in template and so on.

[@TodorPavlov]

You forgot to mention that Angular and Vue have their logical structures (ngFor, ngIf, v-if, v-for) and even if you decide not to use html (which is a lot simpler than jsx) and use another templating language you are still going to use framework's logical structures which you already know. And by the way the composition in html is done using custom elements, which is the reason we started using frameworks on the first place :)

[@waltermelo1033]

Hey man, so what do you think about compile-to-js languages like Livescript .. i found it very good for functional programming but it worths learning?

[@Max-bh8tg]

Used react for a good while, but fell in love with Vue and its simplicity.

[@ReinadeVainilla]

"the more things you add that CAN go wrong, the more things will go wrong" ...omg, I say this everyday when I see "spaguetti-wanted-to-try-something-new-in-production" code at work. I'm like the crazy person at the office screaming "this could have been done in a much simpler way!! why the hell!!" (and I'm not a programmer...my brain refuses to work like that) lol love your videos

[@joemiller1057]

Great video. This talk mostly discussed these two patterns in terms of developer productivity. There are some also performance differences. When you begin to do more js heavy logic on the client, (making more api calls, having lots of rendering logic) your load time can increase, it makes it more complicated to cache your site, and it can be more difficult for search engine bots to crawl your site. These reasons have been why for example news sites pre render everything with a server side rendering engine and interactive apps like gmail that also do not need to be indexed by search engines use client side rendering with js.

[@funfunfunction]

These are not related to the issue at hand though. Templating languages or the native JS approach doesn't have any performance difference on an architectural level - that's just an implementation detail. Both approaches have existing high-performance implementations that are great at both server-side and client-side rendering. React applications have great support for server-side rendering and can deliver the initial view pre-rendered to the client.

[@joemiller1057]

That's a good point, but logistically there is still more of an ecosystem and more established technologies, (especially when you consider non-JS frameworks) for templates if you want server side rendering. Ex: If you are creating a mostly static, content driven site, rendering react on the server when your backend is in python to avoid using one of the many python template frameworks seems like potential overkill.

[@alexkey9372]

Very clearly explained and you made your point. I think the main benefit of react is being able to be a better programmer and build large scale apps. However, I find react quite horrible when it comes to small projects. If you want something quick and easy, templating languages will help you avoid delays.

[@SlimShaggy62]

At last, I got to understand what currying can be usefull to!. Thanks, MPJ ;)

[@maksymlysenko3761]

Great episode, thnx) But I'll be nerdy about the "currying" thing, that thing with bind, actually not currying))) Partial application often considered as currying...

[@sentjojo]

I use a templating language (velocity) to generate large amounts of XML through Java. In my case , it's a benefit. Instead of writing XML through strings in Java, I can use simple templates to get the job done. The only requirement is an extra jar dependency and five minutes to learn the syntax.

[@fruitbat36]

What about ES6 template literals? Doesn't that bring it closer to templating?

[@fsacer]

What about Razor in ASP.NET? Well it's probably not templating language or is it?

[@error.418]

Simple, stop using ASP.NET ;)

[@sators]

11:06 "This is absolutely not rocket surgery"

[@rockywright4237]

What do you think about HTML/CSS preprocessors like scss and pug

[@AlejandroBachi]

I agree on the main point, but the examples choices were totally incorrect. For example the formatCurrency is meant to be done before inserting in the template, you argument is invalid here, i'm not sure if you are complicating the example on purpose just to support your point or you don't really know how to work with a template. Same applies to the sum of item example, you are using the template from most of the times so do the sum in js and diplay it in the template with a variable (for example in mustache Total Cost:{{sumOfItems}}).

[@jean-guillaumeburet1068]

What do you think about Elm?

[@QotsaStrokes22]

If you're interested in Elm, you should try it out. I find it really enjoyable to use. The community surrounding it is very supportive and despite what some think, it's definitely growing. Functional languages in general are pretty niche anyway for now. Also, when Web Assembly is widely supported, Evan (the creator) plans on making it compile to that rather than JS, which will likely make it run even faster than it already does.

[@waveFunction25]

Elm seems awesome, I'm just not sure I'd use it for anything other than personal projects.

[@mazyvan]

I really really like your videos. I'm a big fan of you BUT ... I think that yeah, you have great points about the cost of using templating lenguages, however I see that the community is moving forward in that direction. Before any standardization there's always chaos. And I really think that some day in the future ECMA and W3C will create a beautiful htmljs baby haha. A nice really STANDARDIZED language. And when that happens then there will be no cost. Now in today's time, the complexity is real. I agree But the benefits are huge. The social cost is minimum. There is a lot of good and well organized documentation for the biggest template languages today. "Programs must be written for people to read, and only incidentally for machines to execute." Harold Abelson. 19:13 As a developers we need to read a lot more than write. We waste our time trying to figure out what other developers tried to do. And, as you say, TL are more declarative. So trust me. The time you spent trying to understand the pure js code is enough to check the docs and learn. And now the biggest benefit I see working with TL, that you didn't mention is that you can see exactly what is interacting with your view. For example, you can create an element and with js add a event based on a query selector. But is really hard to find that declaration on your code. Or let say you have a div with an specific class and you're rendering some html inside based on a fetch() result. how do you know where that html was created, in what file, what function? this are important problems that TL solves really well. P.S. Rocket surgery haha that's great XDD @funfunfunction @mpj

[@charlesrosenbauer3135]

Have you watched Jonathan Blow's new talk on his Jai language? What do you think of it?

[@VladaJanosevic]

Can you give us a link of that video? Thanks

[@kesuskim6072]

These days I have been using rule engine, which uses declarative programming's power very well, and I definitely feel, it rocks :)

[@QuentinLurkin]

When do you release your DOM render library ;) ?

[@MatheusSousaALenda]

You are absolutely correct. I agree 100%. But, unfortunately, I need a template language right now. I got to "transpile" all the views from an legacy project (angular 1.6) to be compiled as a service. Using js it would be completely cool, but it would take a lot of time. For speed purposes I'm using pug. Not to mention de DECLARATIVE nature from the angular views. I loved the solution, and probably after finishing the problems in PUG, I'll migrate to JSX. I feel a little trapped, but sometimes we are trapped by the due dates

[@christianhorauf9958]

Your are making very interessting points. Thanx a lot for that. But what if you have to use Angular (I know you do not like it very much) because of the Java-Affinity of your Teammates. Would you in this case really encourage write some render functions like this in the controller? Unfortunatelly I also had to make the experience, that my teammates did not understand my functional code and rewrite it in imperative style, which relly made me feel sick...

[@funfunfunction]

If you are doing Angular you should do things as Angular-ideomatic as possible. The ONE thing that beast has going for it is that it kind of offers a predictable way of doing things. If you start writing Angular in non-angular ways you're throwing away the only real benefit Angular has over it's competition. If you have junior devs on your team that don't understand functional programming and reject it to the degree that they rewrite it as imperiative, and you have little recourse in spreading knowledge in the team, I think you should consider switching teams or workplace.

[@GregBailey71]

Would you consider Angular to be a templating language?

[@moistbrownypoints]

Does this specific social cost add arguing in a team context? I think this could lead to unsatisfied, discouraged developers?

[@nitinjena5785]

I never understand the template engine section, is it worth to learn ejs?

[@agasarang]

Another great video! I mostly agree but what about CMS that allows content entering/editing that must flow through a templating language like Twig?

[@nyambe]

Templating languages are great for prototyping and fast developing. You can refactor to KS as needed. BTW in your ja example div, ul, lo, and p are functions you had to create, right?

[@funfunfunction]

I don’t understand why there would be any difference in speed between the two. It certainly isn’t to me, assuming I know the two equally well. Div, ul, p etc are functions that *someone* had to create, just like someone had to create the templating language.

[@nyambe]

Fun Fun Function I mean a bit is the JAM concept. JavaScrip, API, and Markup. You can create very complex solutions that you can play around in days. These can later redefined or rebuild as needed.

[@MarcelRobitaille]

What about server side rendering? Any node packages you recommend for this?

[@funfunfunction]

React has fantastic support for server-side rendering.

[@pakast1n]

Check out RE:DOM (redom.js.org) - you can for example add classes in many different ways: const p = el('p.hello', 'Hello world!'); const p = el('p', { class: 'hello' }, 'Hello world!'); // uses .setAttribute('class', 'hello'); const p = el('p', { className: 'hello' }, 'Hello world!'); // uses .className = 'hello';

[@nazimleulmi1765]

You didn't mention search engine optimization impacts when you are using client side javascript to render HTML

[@TimothyWillis1981]

riotjs - has elements of React in it, but super simple, ultra light weight, low learning curve, no jsx to learn, and I can call whatever functions in the template like I would a normal js function. {triple(double(test))} this.test = 'test'; this.double = (str) => { return str += str; }; this.triple = (str) => { return str += str += str; }; gives us: testtesttesttesttesttest +funfunfunction / mpj - have you checked out riotjs, what do you think of it?

[@patrickren7395]

Single best invention in the last 10 years, jsx has intuitive api, fit well among other js code, 100% typescript coverage. In a way, the difference between a programmer and an engineer is whether he can create abstraction/syntax sugar that makes people's life easier

[@jamesluckhurst4798]

Half the reason template languages came about was the argument to separate designer code and developer code. But in realty a full-stack dev just ends ups doing all the coding making the reason a complete waste of time. I totally agree it makes no sense when you lose functionality. Reminds me of the days of replacing PHP with another inbuilt tempting language, when PHP is actually a tempting lanuage. But wait cant you break things? No not if you follow MVC properly.

You can use plain JavaScript functions in Vue/Svelte/Riot templates, maybe it's possible in other frameworks too. I like the versatility of JavaScript views though

[@mybigbeak]

"Pure" functions on the observable data need to be available. And can be considered part of the view.

[@pierrem2983]

Hey MPJ ! What about developping DApps (decentralized applications), smart contracts, on the Ethereum blockchain ? I'm a junior dev and i wonder if most of developpers are aware of the "web 3.0", is it popular in the JS community, your opinions guys ?

[@cheeseburger1884]

Where do I learn to make my own templates and views? I'm new to this stuff.

[@StephanHoyer]

First: Great video. I will definitely refer on this, when I got in a discussion about the cost of templating languages. When using mithriljs (mithril.js.org/) the expressiveness-arg also falls apart, because you can just use css-selectors to create html-elements. m('.list-container', items.length ? m('ul', ...) : m('p', ...)) One other thing I really like about JS-to-HTML-approach is debuggability.

[@TheOlian04]

Could your make a video on Elm?

[@draco_2727]

For once I (kind of) agree on a few things here: 1st, I see many friends (developers) and "random" functions/tools in repositories that provide really complex solution even for trivial problems. I've friends that are good developers to some extend but I wouldn't hire them because I've seen how the provide such an overly thought solution to things that could be really straight forward. I seek simplicity and believe me (or do your own research), only shitty ideas comes first. 2nd, consider the nature of the masses, most people are just followers, therefore developers tend to go with the trend and some just don't give a f*ck on how a new framework internally works as long as it make their life easier (not realizing the cost of learning curve and introduced issues for which effort might have been directed into mastering the base language in the first place). 3rd, deep down some devs must admit that (for certain cases) using template engine is not matter of providing efficient solution, is a matter of not embracing the language. I know devs who hate JavaScript, but they swallow easier now because it is wrapped in react/vue/handlebars.

[@alegutierrezmusic]

I think that Vue.js solves the problems you mention because it's in the middle of Angular and React so i'ts very easy to learn, read and write from novice to expert.

[@funfunfunction]

+Alejandro Gutierrez vue uses a templating language and as such has all the benefits and costs that I elaborate on in the video. It's actually the main reason why I made the vid. ;)

[@ehza]

funfunfunction LoL.. clever mpj

[@Maurob45]

funfunfunction Vue has also rendering functionality vuejs.org/v2/guide/render-function.html

[@DeepDarkier]

Vue also adds a big complexity with events, using @event and $emit is a pain, where in React you just use plain old callbacks

[@DeepDarkier]

Another thing that I think Vue is way behind is the "cost" of extracting components, on React you can just extract parts to a function and that is it, where in Vue you have to create a whole new .vue file with lots of boilerplate (I know that there are other ways to create components but .vue files seems to be the standard)

[@JAlfredoPacheco]

I was 50% and 50% with angular.io and mithril.js.org , after watching this video, I will go with mithril! Great video as always!

[@davida4697]

so...how do you feel about flux/redux...?

[@proclaimm]

always pump me up after seeing your video, time to write more code!

[@lucaban]

Can you list some examples of "templating languages" please? Do you mean React and Vuejs?

[@funfunfunction]

With templating languages I'm referring to languages that invent a new syntax that (often) looks very similar to HTML. Handlebars, Mustache, Jade or the language that is used by Vue, are examples of such languages. The "Native JS" approach that I refer to as the "versus" is similar, but doesn't invent a new syntax, it instead just uses JavaScript. An example is HyperScript (github.com/hyperhype/hyperscript). This is also the approach that React uses but it's easier to see this if you remove JSX from the equation: facebook.github.io/react/docs/react-without-jsx.html.

[@dealloc]

I like how the camera view became less and less rounded :D

[@unel86]

Declarative - it's more than "without mutating state". You talked about DSL, but did not mentioned about their more important benefits: independence from platform (gives possibility use one template language for php or js for example) and independence from realization (gives possibility optimize some constructions under hood template engine depending on some internal requirements). And yes, even SQL and RegEx have more than one standards. Yes, template language - it's language and if you need write some code, you need learn it before this. But if you just reading template, it may don't need it (if it is not, then probably this is a bad template language). But developers often read the already written code, than write it; and it is necessary to optimize the possibility of easier reading of the code, rather than the speed of its writing

[@gillianseed4419]

native and js in the same sentence makes me chuckle inside my body

[@salvage_frequency]

I've written my own template language based on C# cshtml that is being translated directly into corresponding javascript :)

[@Kiev-in-3-days]

I see another potential cost you didn't mention. The long term refactoring cost. After a few years your templating system is obsolete or not cool anymore and you have to refactor your code.

[@hossamsamir5365]

what software do you use for recording desktop and webcam in a custom shape like this?

[@funfunfunction]

+hossam Samir it's the setup I show in the behind the scenes video.

[@funfunfunction]

+funfunfunction (basically its fcpx)

[@hossamsamir5365]

Thanks a lot

[@nerdiloo9863]

Agreed 1000%. Just to use any of engines requires researching which one suits your way of thinking. It frustrates me to have to unlearn html markup, for less markup when it's going to be full blown markup in the end anyways (and because of my familiarity with both html/js the productivity increase is not that different). It's like taking a few weeks to learn short-hand (dictation) when you know full well you can type faster as is (lame example). I'm definitely a close to bare metal, simpler-is-better (way of life) kind of guy. Another side effect - coders start forgetting how a 'real' forEach is syntaxed (or at least drawing a blank for 10 sec switching gears). IMO each engine tries to be jquery/revolutionary/cute adding their flare but the programmer has to wade through fodder (paradigm that won't be used on another team/project). All the time could be used learning 'bare-metal-javascript'. There is definitely a rise in 'engineers who like to over engineer', taking the real tools away and saying 'Use this, just add water!' but I remain 1 mile behind the bandwagon.

[@TheNewton]

bind where the 2nd argument becomes the first argument because that's intuitive