The difference between brain surgery and rocket surgery is in brain surgery only the patient risks death while in rocket surgery the surgeon and patient share the risk.
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..
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?
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.
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.
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 :)
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?
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?
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
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
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...)
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. (:
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)
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
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).
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.
#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.
#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: ua-cam.com/video/0ZNIQOO2sfA/v-deo.html) 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 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.
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.
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.
"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
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 :)
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?
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!
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.
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.
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 !
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
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
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.
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
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
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.
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}}).
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.
IMO your argument against template engines, specifically when you need to add a new method to the engine is invalid. Your example violates the principles of MVC - which is typically where these engines are used. IMO The presentation of the data such as formats such as currency should be processed before the template engine handles the data or the method to format the data needs to handle this particular case. The goal of a template engine is mostly to help designers who have little programming experience express how they wish the part of the view should work. I think a better argument would be to discuss the dynamics of your team. For example if you do not have to work with others how specialise in other disciplines like UX design. Your arguments suggest that other domain specific languages like those used for BDD would also suffer from the similar problems. Still good video though. I always look forward your videos on Mondays. :D
Daniel Samson but the DOM is often more messy than the actual logic! Why can't designers learn to use js? This way there's a smaller cost to switching roles in projects, and improves communication between your designers and devs, since you speak the same language!
+Daniel Samson what you describe is a common argument against React. It comes from a position that considers that HTML/CSS to be view and JavaScript to be logic. React holds the viewpoint that this is only separation of *technologies* and what is actually interesting is separating view and business logic. I.e. In React there is such a thing as view *logic* and business *logic*. It's interested in the concept separation and considers separating technologies to be an illusion. The template "ideology" also has a problem that it says that logic such as summing should be outside of the view, but at the same time allows logic such as if statements and transformations into the template logic, which in my mind are absolutely equivalent conceptually.
That is a good question Oskar Lappi. Again I come back to the concept of different disciplines. I guess it comes down to what motivates people, and what they are good at. The designers that I work with would rather not learn how to program something. Even though languages like JavaScript are ubiquitous and pretty easy to learn. I guess that they would much prefer do something that is more artistic or lean a new feature of there image editor. Also didn't say that I disagreed with @MPJ. As @MPJ clearly pointed out that template engines are much easier to read. I think this is why some people would rather learn a template engine. As it at first glance seems much easier to learn. Template engines also are used to separate the concerns of mixing languages in code. For example in languages like PHP, python, ruby and C/C++ this is perhaps a bigger issue. I personally think you should separate your concerns more. However, this is just my opinion. For me it's because I don't work solely on JavaScript. So this is a bigger issue to me. I like @MPJ's arguments, as it makes me consider ideas that I would have overlooked.
My point here was more something like this: the template languages can be just as complicated, if not more complicated, than view js. If designers can learn to use them, they can learn to use react.
@mpj - The "if statement" thing is a very good point and react is a technology that is on my "One day i will look at it" list. But I am curious how this pans out when testing. Is it better to have more separated concerns in order to provide better testing? In react should you simply only hold "view" logic in say one method or class or js object? Again thanks for making the video.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
Hey mpj. Been your fan for a very long time. Had a completely off topic question. Is UA-cam now your bread and butter now that you have left Spotify? Or are you freelancing as well :D very curious to know.
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?
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.
There is one false assertion here: that templating languages limit code usage. That is certainly not true. Take ejs for example, it allows you to use plain javascript in templating logic. And no, it's not a js-first approach like react, ejs is really a template processor. That's actually how templating languages originally developed: fully turing complete. Take PHP as another example, PHP generally use PHP for templating. The move towards logicless templating is quite recent. Generally templating languages fall into 3 categories: simply reuse the main programming language for the templating language (PHP, ejs), fully Turing complete languages (Template::Toolkit, dust) and logicless/restricted languages (handlebars, mustache). Your argument really only apply to the last category. Basically this video is for people who don't like handlebars rather than templates
+slebetman yeah, what I refer to here is custom templating languages with their own logic constructs. Embedded JS can be called a templating language (as there is no strict definition of what they are) but it's not what this video talks about.
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.
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
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.
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: ua-cam.com/video/0ZNIQOO2sfA/v-deo.html
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?
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!
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
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.
I know you're not trying to focus too much on a specific view lib, but Vue somewhat solves the "I can't use a function in my templating language" problem by exposing computed properties and methods in the template. It's among the first few things you learn about Vue in its guide, and its handled very elegantly! It not only keeps the template readable and easy to reason about, but it keeps the logic in its right place (JS), so formatting things or processing items within a loop feels pretty natural.
+Andy Merskin the example is based on vue and has the same costs and benefits as the example I give. As you say, it makes the template READable, but you lose ease of changing the code (which is ultimately what readability aims to achieve). In the native JS example a JS developer not familiar with the project can just call the function, but in Vue, you have to learn about computed properties in order to call a function. I.e. You've added a completely new concept to learn in comparison the the native JS solution, where this is not at all needed to make the change. I understand that templating languages consider this to be separation of concerns, but (apart from the fact that you can simply do the exact same thing without the templating language) I and many others consider it to not really separate concerns, but just spreading a single concern out over multiple places, making change harder to reason about because the one thing you are reasoning about (your list component) is not in one place. I've talked more extensively about this in the separation of concerns video: ua-cam.com/video/0ZNIQOO2sfA/v-deo.html
+Andy Merskin also note that the example I use a formatter. The reduce example is more subjective, but the currency formatted definitely doesn't belong in a computed property, it is in template world (which is why the plugin architecture exists in all templating languages). This touches on another cost of templating langurs that I did not touch on in the video - it (intentionally) makes it harder to add logic to templates, which makes people reluctant to add logic that SHOULD be there. In template language projects I often see people not bothering to learn the plugin structure at all all, and instead throwing formatting logic into computed properties (or whatever equivalent the framework provides)
Fair points! Also know this is coming from the perspective of a designer first and foremost--front-end development is secondary in my career--so I favor the workflow and visual appeal of Vue's single-file components, and the documentation that took me no more than a Saturday afternoon to digest and understand immediately. The learning curve, especially alongside another designer who was just getting into it, was painless. That said, there's a reason why we have so many options, it boils down to a matter of preference despite the objective differences between each approach. As you probably know already, Vue is extremely flexible in that it supports not only its own templating system, but also JSX and functional components through its rendering APIs when the situation calls for it. Ideally a handful of developers working on a project should be able to pick up each approach fairly quickly, given enough basic JS and general templating knowledge. Vue's documentation is key, and it's damn good. Though I could be making a lot of assumptions based on my learning journey here. ;) Always good to hear your perspective MPJ--thanks for having these dialogues!
+Andy Merskin yeah, my article is written from the viewpoint of a developer. Having designers poking around in the codebase is honestly a world that is very alien to me. If you're not familiar will JavaScript, then of course things written in JavaScript will be harder to get into, because you will be learning JavaScript, a general purpose language, rather than a template language which is a much simpler construct.
+Andy Merskin I understand the argument that "learning is easy" but I still repeat: if you know JavaScript and you use it as a template language, you do away with that learning in the first place. It's like saying "this jacket is so cheap, you should just buy it" when you already have a perfectly good jacket. Complexity is not free and the cost never comes in big chunks, it's always in small increments that eventually end up being a huge thing.
As a designer i really despise that the markup is created in the Js by the developer, no matter if is a template or pure Js, the markup should be left alone as much as possible and perhaps Js can just use Ids or classes that the designer and the dev agree upon. Now that I am learning react I really want to puke. I hope angular or Vue are not like that.
It depends on the output. If your output is always going to be HTML it's probably better to use native JS. If you have other sorts of outputs, and your template language is general enough then it might be better to put the effort into learning the template language. But people who do general outputs, and don't specialize likely aren't that common. Though people might be being forced to specialize because of the tooling itself. But a hypothetical generalist would benefit from the declarative, and expressive benefits of a general purpose template language. Such a general purpose language would mostly combine strings with values. It would also allow for imperative programming. EJS is the closest js template language to this, but an even closer template language is template literals. That is given the fact that template literals can output anything they are the most general purpose template language. And that too is native js, but if you use literal tags too then you would be deviating from native, at least on the outside of the tag function.
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
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.
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.
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.
Although I too personally prefer the React approach, I just want to point out that your argument about "whatever can go wrong, will go wrong" also works against you: having the full power of JS in your views increases the number of things that can go wrong, just like (as you say) adding a new templating language increases it. So I think you need to make a more nuanced argument to properly support your claim.
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 :)
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.
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.
I think that, if requirement of view rendering is quite complex, by followed your instruction to the end (make javascript declarative), you will ended up creating basically "another templating language" along the way. Which based on my experience, can be even worse than using formal templating language. You have to write doc yourselves, maintain it yourselves. This can be nightmare. But I understand your point, I think there should be balance. If you introduce templating language for only simple templating ,and for this context "simple" is quite a lot, it only cost your more because of reasons your explained in this video. But then if you find yourself digging down the hole very deep and nearly ended up with your own templating language which bunch of functions, compose with some weird composer and currying pattern, that's when you should consider introducing standard templating language into your codebase. BTW, most of us do the opposite. It is very tempting for developers to feel the opposite way. We feel like we should introducing new tool early so people can learn early, which IMO is a really bad idea. And when we don't, we have loss aversion bias. We feel like we already wrote so many lines of code so we are reluctant to replace our works with standard library, which again IMO is a really bad idea too. Write simple code, and then throw it out when it is not needed anymore. All good devs I met do not hesitate to throw the code out, given a chance.
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? ;)
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.
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 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 :)
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 ?
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
Good points MPJ, but I think you spent a lot of time just "selling" Javascript, we know you really like it. The point of adding a big deal of complexity in the project is not that big since one is not going to implement his own templating language. In my view, the only big argument in favour of something like React it exactly what you have excluded in the beginning, the virtual DOM, that saves a lot of little and slow DOM mutations. This is a true advantage over templating languages, in my opinion.
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';
I understand what you mean, and in an ideal world, everything could be done with javascript. But we can not reduce all cases to one single environment and template engines are not created just for readability. You forget many use cases where templates are necessary. For example, they help to integrate programmers, markup developers and designers. It helps quickly to make changes on the view, rather to being changing rendering functions when a redesign is needed. It helps SEO when using server template engines, etc. I wish I could just use one single tool and language for everything but in web developement its kind of dificult. We should go the direction your are point it at? may be? but you could kill some job roles on the way ;-)
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.
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?
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...
For JS, I tend to like keeping the view in JS, as described here (JSX ftw). But PHP is perhaps a good counter-argument. Something like Smarty or Twig or Blade can be nice to "protect" views from becoming a mess. Imagine someone thinking "I need this value from the database", and then they go and call the DB in the middle of a view... agh, madness! See also: WordPress templates.
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...
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.
MPJ, I have a video idea for you. Have you ever considered making a video quantifying the "cost" of introducing a new technology into your stack? I've thought about this for a while and I have some ideas, but I'd like to hear your thoughts. As you say, you value simplicity so I figure you might have thought about this yourself. I think it would go a long way to illustrate the point you try to make so often about NOT adding something new if you can reasonably do it yourself. Of course, this kind of thing is mostly subjective, but I think a reasonable case can be made if it's expressed in man hours. Another great video, BTW.
I saw that video and you made good points, but I was thinking of something more concrete, like a formula for calculating the cost of adding a new technology. I haven't thought through all the inputs, but it's got to start with something like: ( x ) + + And there would probably be other possible inputs, like if a library becomes defunct and you now have to migrate to something else. Or if it becomes non-backwards compatible. Like I said, I haven't really thought it through yet, but it might be the start of an interesting discussion.
7 років тому
Can't really agree with this one. I understand of course that the cost of anything is subjective, but I totally disagree with the argument, that the cost of templating language doesn't pay for the complexity it introduces. Starting with the fact that each of the popular graphical interface systems uses markup (at least has the feature of markup) for expressing layout. That includes QT framework, UWP (for windows), Android, iOS, etc... But why? I think it's to decrease the complexity in visualizing any kind of graphical element in the UI. While sometimes it's easier to create any kind of control or wrapper element in the code, when there's not much to lay out, it becomes almost impossible when you get to a real complex UI. Especially on the web, where you might need wrappers within wrappers, to get the desired effect with CSS and positioning. I don't even want to think about debugging some layouts without HTML. Here's what I think of your points on templating languages: 1. Expressiveness - Yes and yes, that's the most important thing here, that will pay for everything in general. Now there are some things you can, of course, do expressive enough in JS but as I said before, once the layout and the UI elements get complex enough, it becomes a nightmare to maintain it. 2. Declarativeness - While it's true that you can just do it anyway, this feature is critical for templating language. And one of the reasons is exactly the lack of tools in present and future. For the templating language is meant to help a developer or a designer to design the page/app. Build the layouts and UI elements, not for logics. And the lack of features is its strength. Because the language is so simple, it's both easy to read and write and the lack of IntelliSense isn't that bothering. But even so the most popular of languages will have quite a lot of features in the editor. 3. Complexity - Or the lack thereof. There are a lot of places your project will need if templating language is in your dependencies and the templating language will most likely not be the biggest burden. It may take few K in your bundle but it will allow for easier development of UI. And it might not take any K if it's compiled to JS before it's pushed to the browser. 4. Social cost - I think there is no more social cost than learning a framework or even your local helper functions. As described in the "Declarativeness", good templating languages are simple, even dumb, you basically get some ifs, loops, and output those concepts are easy to grasp even for a joung dev. I'd rather say "Social gains" since it enables communication and cooperation. UI Designer can build a markup with the style and even animations without knowing a bit of JS. Just putting some placeholders here and there and voila, you've got a nice looking template with all the outputs. But if we get back go the "costs", even in your example of "div" function, it had to use "className" instead of class and who knows how many more caveats like that your rendering methods have, these things any developer will have to learn, because indifference to templating languages those are your rendering functions that you or your team created. If you use Handlebars or JSX or anything else popular, chances are, the developer will have seen that or even used it if he/she is already a frontend developer. 5. Loss of tools - well this really exists as a drawback to some extent. Some templating languages will have no tools at least no tools that connect it to your JS, but as I stated before, this is usually not so bad, because there are only a few basic things you want to do there and it's not so hard to wrap your head around. You do however normally get, HTML attribute autocompletion, element completion and emmet which enables easier work with markup. That's not all though. Now when we can import our template files in JS and the editor can understand the context, we can get much more out of them. JSX already has quite some IntelliSense, especially with typescript and Angular language service provides the same functionality Angular 2+ templates. In summary, if you're bulding an app, that has anything but the most simple bare bones UI, the templating language will help a log. From visualization to cooperation with non-coder collegues it pays for it self and much more in my opinion.
7 років тому
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
Why do you never mention ES6 template literals? They are part of javascript and allow you add logic as you please. Or am i missing something about template literals that would make them not viable for production use?
+mstura that's not relevant to this topic, more than in name. What were exploring here is dedicated template languages, with logic constructs and plugin structure. ES6 template literals are just a handy way to do string interpolation.
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.
I think all business data should be handled by business logic. If your summing padding or color codes I think that would be considered view logic. But any critical data should be handled by the back end. My 2 cents.
When you say pure js, you mean that div and p are function defined somewhere or I missed something ? I'm not a pure js dev, so excuse me if I said an heresy! :-)
I noticed something on your hair. I was not able to put attetion the whole video.
The amount of likes on this comment suggest that there might be statistical correlation between OCD and software development.
I hadn't noticed until now. Now there will be 25 minutes of video and trying to hide that little thing
Thanks for the idea... was driving me nutz, scrolling down a bit helped.
there's a hole? in the video?
Time to go to the doctor!
You are the coolest JavaScripting Swede on the planet!
aww
ayyyyyyyy
Rocket surgery? Is this to express composability of complexity? Rocket science + brain surgery?
Bravo for your show
meta, this is.
Seen this a few times ^^
Love Mitchell and Webb
It's not a unique joke, it's just making fun of the silly idioms "not rocket science" and "not brain surgery"
DHH is known for saying that
The difference between brain surgery and rocket surgery is in brain surgery only the patient risks death while in rocket surgery the surgeon and patient share the risk.
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..
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?
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.
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.
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 :)
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?
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?
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
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
About currying - you have to remember that the template equivalent is creating components and plugging them into the system.
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...)
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. (:
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)
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
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).
With JSX its basically copy, paste, change "class" to "className"
Yeps!
I've found native js can look ugly especially with lots of inline if statements used. Hard to look away from pretty handlebars 😆
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.
+Christian Benseler this isn't really a benefit from templating languages, the native js solutin has the same benefit.
#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.
#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: ua-cam.com/video/0ZNIQOO2sfA/v-deo.html) 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.
The composition argument convinced me. Thank you, I believe you are right.
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.
result = items
.map(formatCurrency)
.reduce((a,e) => a += e, "")
.map(lis => lis)
.getOrElse(No items found)
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.
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.
I would replace that reduce by map to and join.
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.
Loved the pauses built in to this vid for us to think on our own about the code. Great vid!
+Brian Zelip I'm trying them out for the first time, glad you liked them!
"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
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 :)
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?
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!
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.
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.
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 !
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
11:06 "This is absolutely not rocket surgery"
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
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.
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
You know, that haircut could cost your life in North Korea... just saying
That is a really important tip.
Crossing the road could cost you your life.
Used react for a good while, but fell in love with Vue and its simplicity.
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
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.
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}}).
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.
IMO your argument against template engines, specifically when you need to add a new method to the engine is invalid. Your example violates the principles of MVC - which is typically where these engines are used. IMO The presentation of the data such as formats such as currency should be processed before the template engine handles the data or the method to format the data needs to handle this particular case. The goal of a template engine is mostly to help designers who have little programming experience express how they wish the part of the view should work. I think a better argument would be to discuss the dynamics of your team. For example if you do not have to work with others how specialise in other disciplines like UX design. Your arguments suggest that other domain specific languages like those used for BDD would also suffer from the similar problems.
Still good video though. I always look forward your videos on Mondays. :D
Daniel Samson
but the DOM is often more messy than the actual logic! Why can't designers learn to use js? This way there's a smaller cost to switching roles in projects, and improves communication between your designers and devs, since you speak the same language!
+Daniel Samson what you describe is a common argument against React. It comes from a position that considers that HTML/CSS to be view and JavaScript to be logic. React holds the viewpoint that this is only separation of *technologies* and what is actually interesting is separating view and business logic. I.e. In React there is such a thing as view *logic* and business *logic*. It's interested in the concept separation and considers separating technologies to be an illusion.
The template "ideology" also has a problem that it says that logic such as summing should be outside of the view, but at the same time allows logic such as if statements and transformations into the template logic, which in my mind are absolutely equivalent conceptually.
That is a good question Oskar Lappi. Again I come back to the concept of different disciplines. I guess it comes down to what motivates people, and what they are good at. The designers that I work with would rather not learn how to program something. Even though languages like JavaScript are ubiquitous and pretty easy to learn. I guess that they would much prefer do something that is more artistic or lean a new feature of there image editor.
Also didn't say that I disagreed with @MPJ. As @MPJ clearly pointed out that template engines are much easier to read. I think this is why some people would rather learn a template engine. As it at first glance seems much easier to learn. Template engines also are used to separate the concerns of mixing languages in code. For example in languages like PHP, python, ruby and C/C++ this is perhaps a bigger issue.
I personally think you should separate your concerns more. However, this is just my opinion. For me it's because I don't work solely on JavaScript. So this is a bigger issue to me. I like @MPJ's arguments, as it makes me consider ideas that I would have overlooked.
My point here was more something like this: the template languages can be just as complicated, if not more complicated, than view js. If designers can learn to use them, they can learn to use react.
@mpj - The "if statement" thing is a very good point and react is a technology that is on my "One day i will look at it" list. But I am curious how this pans out when testing. Is it better to have more separated concerns in order to provide better testing? In react should you simply only hold "view" logic in say one method or class or js object?
Again thanks for making the video.
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.
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.
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.
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.
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.
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.
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?
Hi, 26:50, there's no link to the currying video that I could see (as of now)
thanks, fixed!
ua-cam.com/video/iZLP4qOwY8I/v-deo.html&feature=iv&src_vid=EmGfdlixQHo&annotation_id=video%3A0742baf3-2e6c-417f-a909-b1a789f75bd4
This is actually partial function application, not currying. mpj's video explains currying correctly, I think he just got the two mixed up here.
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?
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.
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.
Hey mpj. Been your fan for a very long time. Had a completely off topic question. Is UA-cam now your bread and butter now that you have left Spotify? Or are you freelancing as well :D very curious to know.
when did he leave Spotify?
Announcements coming soon. :)
I guess you've been hired by Google... as you said you've been training for it with your friend.
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?
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.
There is one false assertion here: that templating languages limit code usage. That is certainly not true. Take ejs for example, it allows you to use plain javascript in templating logic. And no, it's not a js-first approach like react, ejs is really a template processor. That's actually how templating languages originally developed: fully turing complete. Take PHP as another example, PHP generally use PHP for templating. The move towards logicless templating is quite recent. Generally templating languages fall into 3 categories: simply reuse the main programming language for the templating language (PHP, ejs), fully Turing complete languages (Template::Toolkit, dust) and logicless/restricted languages (handlebars, mustache). Your argument really only apply to the last category. Basically this video is for people who don't like handlebars rather than templates
+slebetman yeah, what I refer to here is custom templating languages with their own logic constructs. Embedded JS can be called a templating language (as there is no strict definition of what they are) but it's not what this video talks about.
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.
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
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.
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: ua-cam.com/video/0ZNIQOO2sfA/v-deo.html
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?
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!
bind where the 2nd argument becomes the first argument because that's intuitive
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
Note that we're concerned with template LANGUAGES here, not the more general concept of a template.
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.
I know you're not trying to focus too much on a specific view lib, but Vue somewhat solves the "I can't use a function in my templating language" problem by exposing computed properties and methods in the template. It's among the first few things you learn about Vue in its guide, and its handled very elegantly!
It not only keeps the template readable and easy to reason about, but it keeps the logic in its right place (JS), so formatting things or processing items within a loop feels pretty natural.
+Andy Merskin the example is based on vue and has the same costs and benefits as the example I give. As you say, it makes the template READable, but you lose ease of changing the code (which is ultimately what readability aims to achieve). In the native JS example a JS developer not familiar with the project can just call the function, but in Vue, you have to learn about computed properties in order to call a function. I.e. You've added a completely new concept to learn in comparison the the native JS solution, where this is not at all needed to make the change.
I understand that templating languages consider this to be separation of concerns, but (apart from the fact that you can simply do the exact same thing without the templating language) I and many others consider it to not really separate concerns, but just spreading a single concern out over multiple places, making change harder to reason about because the one thing you are reasoning about (your list component) is not in one place.
I've talked more extensively about this in the separation of concerns video: ua-cam.com/video/0ZNIQOO2sfA/v-deo.html
+Andy Merskin also note that the example I use a formatter. The reduce example is more subjective, but the currency formatted definitely doesn't belong in a computed property, it is in template world (which is why the plugin architecture exists in all templating languages). This touches on another cost of templating langurs that I did not touch on in the video - it (intentionally) makes it harder to add logic to templates, which makes people reluctant to add logic that SHOULD be there. In template language projects I often see people not bothering to learn the plugin structure at all all, and instead throwing formatting logic into computed properties (or whatever equivalent the framework provides)
Fair points!
Also know this is coming from the perspective of a designer first and foremost--front-end development is secondary in my career--so I favor the workflow and visual appeal of Vue's single-file components, and the documentation that took me no more than a Saturday afternoon to digest and understand immediately. The learning curve, especially alongside another designer who was just getting into it, was painless.
That said, there's a reason why we have so many options, it boils down to a matter of preference despite the objective differences between each approach.
As you probably know already, Vue is extremely flexible in that it supports not only its own templating system, but also JSX and functional components through its rendering APIs when the situation calls for it. Ideally a handful of developers working on a project should be able to pick up each approach fairly quickly, given enough basic JS and general templating knowledge. Vue's documentation is key, and it's damn good. Though I could be making a lot of assumptions based on my learning journey here. ;)
Always good to hear your perspective MPJ--thanks for having these dialogues!
+Andy Merskin yeah, my article is written from the viewpoint of a developer. Having designers poking around in the codebase is honestly a world that is very alien to me. If you're not familiar will JavaScript, then of course things written in JavaScript will be harder to get into, because you will be learning JavaScript, a general purpose language, rather than a template language which is a much simpler construct.
+Andy Merskin I understand the argument that "learning is easy" but I still repeat: if you know JavaScript and you use it as a template language, you do away with that learning in the first place. It's like saying "this jacket is so cheap, you should just buy it" when you already have a perfectly good jacket. Complexity is not free and the cost never comes in big chunks, it's always in small increments that eventually end up being a huge thing.
As a designer i really despise that the markup is created in the Js by the developer, no matter if is a template or pure Js, the markup should be left alone as much as possible and perhaps Js can just use Ids or classes that the designer and the dev agree upon. Now that I am learning react I really want to puke. I hope angular or Vue are not like that.
It depends on the output. If your output is always going to be HTML it's probably better to use native JS. If you have other sorts of outputs, and your template language is general enough then it might be better to put the effort into learning the template language. But people who do general outputs, and don't specialize likely aren't that common. Though people might be being forced to specialize because of the tooling itself. But a hypothetical generalist would benefit from the declarative, and expressive benefits of a general purpose template language.
Such a general purpose language would mostly combine strings with values. It would also allow for imperative programming. EJS is the closest js template language to this, but an even closer template language is template literals. That is given the fact that template literals can output anything they are the most general purpose template language. And that too is native js, but if you use literal tags too then you would be deviating from native, at least on the outside of the tag function.
Playing with Elixir/Phoenix EEX templates now. I find them easy to learn... Will be interesting to hear your comments.
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
Wow, I thought the social cost was going to be that no one likes you anymore if you use templates. I think that should be the case anyway.
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.
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.
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.
Although I too personally prefer the React approach, I just want to point out that your argument about "whatever can go wrong, will go wrong" also works against you: having the full power of JS in your views increases the number of things that can go wrong, just like (as you say) adding a new templating language increases it. So I think you need to make a more nuanced argument to properly support your claim.
native and js in the same sentence makes me chuckle inside my body
We use a templating language for our end users who want to give exactly the amount of control we want. But yeah, we don't use it internally.
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 :)
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.
> obj = { class: 'list-container' }
{ class: 'list-container' }
> console.log(obj)
{ class: 'list-container' }
What? You have to use className why exactly?
+TRGWII it's allowed in later JS versions, but is was disallowed earlier so they've most likely do t for backward compatibility reasons.
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?
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.
I think that, if requirement of view rendering is quite complex, by followed your instruction to the end (make javascript declarative), you will ended up creating basically "another templating language" along the way.
Which based on my experience, can be even worse than using formal templating language. You have to write doc yourselves, maintain it yourselves. This can be nightmare.
But I understand your point, I think there should be balance. If you introduce templating language for only simple templating ,and for this context "simple" is quite a lot, it only cost your more because of reasons your explained in this video.
But then if you find yourself digging down the hole very deep and nearly ended up with your own templating language which bunch of functions, compose with some weird composer and currying pattern, that's when you should consider introducing standard templating language into your codebase.
BTW, most of us do the opposite. It is very tempting for developers to feel the opposite way. We feel like we should introducing new tool early so people can learn early, which IMO is a really bad idea. And when we don't, we have loss aversion bias. We feel like we already wrote so many lines of code so we are reluctant to replace our works with standard library, which again IMO is a really bad idea too.
Write simple code, and then throw it out when it is not needed anymore. All good devs I met do not hesitate to throw the code out, given a chance.
Great analysis. Simplicity power is almost always underrated. Simple is elegant 8)
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? ;)
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.
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?
What I use for fff.dev is SolidStart
@@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 :)
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!
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 ?
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
What's your current opinion about this? Since now you can use variables in template and so on.
Good points MPJ, but I think you spent a lot of time just "selling" Javascript, we know you really like it. The point of adding a big deal of complexity in the project is not that big since one is not going to implement his own templating language. In my view, the only big argument in favour of something like React it exactly what you have excluded in the beginning, the virtual DOM, that saves a lot of little and slow DOM mutations. This is a true advantage over templating languages, in my opinion.
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';
What about Razor in ASP.NET? Well it's probably not templating language or is it?
Simple, stop using ASP.NET ;)
@funfunfunction what do you think of preprocessors when creating static / semi-static sites?
I understand what you mean, and in an ideal world, everything could be done with javascript. But we can not reduce all cases to one single environment and template engines are not created just for readability. You forget many use cases where templates are necessary. For example, they help to integrate programmers, markup developers and designers. It helps quickly to make changes on the view, rather to being changing rendering functions when a redesign is needed. It helps SEO when using server template engines, etc. I wish I could just use one single tool and language for everything but in web developement its kind of dificult. We should go the direction your are point it at? may be? but you could kill some job roles on the way ;-)
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.
So cool to see people with all kinds of backgrounds subscribing! Welcome to the channel, Dan, and thanks for your support!
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?
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...
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
For JS, I tend to like keeping the view in JS, as described here (JSX ftw). But PHP is perhaps a good counter-argument. Something like Smarty or Twig or Blade can be nice to "protect" views from becoming a mess. Imagine someone thinking "I need this value from the database", and then they go and call the DB in the middle of a view... agh, madness! See also: WordPress templates.
+darkowl9 but if you have a developer like that, they will just do that dumb crap one level up, which doesn't really gain you anything.
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...
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.
MPJ, I have a video idea for you. Have you ever considered making a video quantifying the "cost" of introducing a new technology into your stack? I've thought about this for a while and I have some ideas, but I'd like to hear your thoughts. As you say, you value simplicity so I figure you might have thought about this yourself. I think it would go a long way to illustrate the point you try to make so often about NOT adding something new if you can reasonably do it yourself. Of course, this kind of thing is mostly subjective, but I think a reasonable case can be made if it's expressed in man hours.
Another great video, BTW.
This is a great idea!
I kind of did this in coding and cooking and throw out your tools, but it's always worth revisiting.
I saw that video and you made good points, but I was thinking of something more concrete, like a formula for calculating the cost of adding a new technology. I haven't thought through all the inputs, but it's got to start with something like:
( x ) + +
And there would probably be other possible inputs, like if a library becomes defunct and you now have to migrate to something else. Or if it becomes non-backwards compatible.
Like I said, I haven't really thought it through yet, but it might be the start of an interesting discussion.
Can't really agree with this one. I understand of course that the cost of anything is subjective, but I totally disagree with the argument, that the cost of templating language doesn't pay for the complexity it introduces.
Starting with the fact that each of the popular graphical interface systems uses markup (at least has the feature of markup) for expressing layout. That includes QT framework, UWP (for windows), Android, iOS, etc...
But why? I think it's to decrease the complexity in visualizing any kind of graphical element in the UI. While sometimes it's easier to create any kind of control or wrapper element in the code, when there's not much to lay out, it becomes almost impossible when you get to a real complex UI. Especially on the web, where you might need wrappers within wrappers, to get the desired effect with CSS and positioning. I don't even want to think about debugging some layouts without HTML.
Here's what I think of your points on templating languages:
1. Expressiveness - Yes and yes, that's the most important thing here, that will pay for everything in general. Now there are some things you can, of course, do expressive enough in JS but as I said before, once the layout and the UI elements get complex enough, it becomes a nightmare to maintain it.
2. Declarativeness - While it's true that you can just do it anyway, this feature is critical for templating language. And one of the reasons is exactly the lack of tools in present and future. For the templating language is meant to help a developer or a designer to design the page/app. Build the layouts and UI elements, not for logics. And the lack of features is its strength. Because the language is so simple, it's both easy to read and write and the lack of IntelliSense isn't that bothering. But even so the most popular of languages will have quite a lot of features in the editor.
3. Complexity - Or the lack thereof. There are a lot of places your project will need if templating language is in your dependencies and the templating language will most likely not be the biggest burden. It may take few K in your bundle but it will allow for easier development of UI. And it might not take any K if it's compiled to JS before it's pushed to the browser.
4. Social cost - I think there is no more social cost than learning a framework or even your local helper functions. As described in the "Declarativeness", good templating languages are simple, even dumb, you basically get some ifs, loops, and output those concepts are easy to grasp even for a joung dev. I'd rather say "Social gains" since it enables communication and cooperation. UI Designer can build a markup with the style and even animations without knowing a bit of JS. Just putting some placeholders here and there and voila, you've got a nice looking template with all the outputs. But if we get back go the "costs", even in your example of "div" function, it had to use "className" instead of class and who knows how many more caveats like that your rendering methods have, these things any developer will have to learn, because indifference to templating languages those are your rendering functions that you or your team created. If you use Handlebars or JSX or anything else popular, chances are, the developer will have seen that or even used it if he/she is already a frontend developer.
5. Loss of tools - well this really exists as a drawback to some extent. Some templating languages will have no tools at least no tools that connect it to your JS, but as I stated before, this is usually not so bad, because there are only a few basic things you want to do there and it's not so hard to wrap your head around. You do however normally get, HTML attribute autocompletion, element completion and emmet which enables easier work with markup. That's not all though. Now when we can import our template files in JS and the editor can understand the context, we can get much more out of them. JSX already has quite some IntelliSense, especially with typescript and Angular language service provides the same functionality Angular 2+ templates.
In summary, if you're bulding an app, that has anything but the most simple bare bones UI, the templating language will help a log. From visualization to cooperation with non-coder collegues it pays for it self and much more in my opinion.
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
Why do you never mention ES6 template literals? They are part of javascript and allow you add logic as you please. Or am i missing something about template literals that would make them not viable for production use?
+mstura that's not relevant to this topic, more than in name. What were exploring here is dedicated template languages, with logic constructs and plugin structure. ES6 template literals are just a handy way to do string interpolation.
You didn't mention search engine optimization impacts when you are using client side javascript to render HTML
What about ES6 template literals? Doesn't that bring it closer to templating?
Most templating languages also handle escaping variables to prevent injection of malicious code.
+dsego84 this is not a feature that you need a templating language to have. The native JS library can have it too (and all libs like this does)
'Rocket Surgery' - brilliant!
Can you list some examples of "templating languages" please? Do you mean React and Vuejs?
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.
@mpj Talking about React are you trying to have as less classes as possible and how do you style your react components?
These days I have been using rule engine, which uses declarative programming's power very well, and I definitely feel, it rocks :)
I think all business data should be handled by business logic. If your summing padding or color codes I think that would be considered view logic. But any critical data should be handled by the back end. My 2 cents.
That at the end was actually partial application, not currying.
When you say pure js, you mean that div and p are function defined somewhere or I missed something ? I'm not a pure js dev, so excuse me if I said an heresy! :-)
+Jimmi V yes!