This is a video about soft power reparations. In March 2018, Rajiv Malhotra gave a speech to members of the British Parliament and made a very strong case for Britain to pay reparations to India. His concept of soft power reparations is both original and unique and is a perfect example of a strategy that would result in a win-win situation for India and Britain. Instead of the traditional request for monetary relief, he articulated the need for soft power reparations and explained how it would have a transformative effect of changing the grand narratives of British colonialism, highlight Indian contributions to Britain's heritage, promote mutual respect and propel future collaborative intellectual, technological, cultural and economic ventures between the two nations. Rajiv Malhotra also explained why he is not in favour of financial reparations. Money alone will not erase the deep psychological, political and physical imprints of British colonial rule. Malhotra's proposal for soft power reparations offers Britain an opportunity to acknowledge its debt to India. Also, Indians need to heal but not through resentment or fake narratives about their history and culture. Decolonisation requires a conscious effort by Indians to reclaim their educational system to not only reverse colonial discourses but also rebuild their technological, economic, intellectual and spiritual foundations. Before we listen to excerpts from Rajiv Malhotra's speech, let us first understand the purpose of reparations. What are reparations? Reparations have become the legal means to recognise and rectify past injustices against an individual, group or country. Reparations can take many forms. For example, the perpetrator may offer a formal apology to the victim. After apartheid ended in South Africa, for example, truth and reconciliation commissions were set up to bring closure by uncovering the atrocities committed. Reparations could come in the form of financial compensation. And a well-known example of this model is German reparations to the Israelis after World War II. Sometimes reparations come in the form of social and economic reforms to resolve issues that resulted from the crimes committed. Rajiv Malhotra's speech in the British Parliament is remarkable, not only because it includes a unique proposal for reparations but also because most former colonial powers avoid such discussions. Although many post-colonial nations have demanded reparations from their colonisers for past injustices, former colonial powers have consistently rejected such demands by questioning the legality of reparations. The common argument is that colonial rule was not illegal at the time it occurred and current governments cannot be held responsible. Let's listen to Rajiv Malhotra's speech at the British Parliament. It is important that we revive our narrative. When you look at Britain, Britain was beneficiary of a large part of Indian knowledge and Indian power because until, if you look at Cambridge history of world economics, it tells you that until 1750, India had about 25% of world GDP. And it says that the West, comprising of Europe and North America combined, had less than 20%. The rest was mainly China. So these are the three big slices. So what happened? And also, when you look at the early European scholars of India, they called themselves romanticists and they had a huge romance for India. So it's only later on, 100 years after this romantic period for India, that things became negative. So you can go back to these people and you have tremendous resources. I mean, they respected India's, you know, mathematics, astronomy, philosophy, linguistics, botany, medicine, all kinds of stuff. And the East India Company really studied steel production in India. Dharampal has, the late Dharampal spent a lot of time in libraries in the UK to look at reports from the East India Company measuring steel production, quality of steel, cost of steel and so on. And even arguing why some of the Indian steel was better and cheaper and should be sent to UK. And some of the major construction projects requiring a lot of steel in Britain were with Indian steel. And Indian textiles, legendary. So if you look at the first two products that made the British Industrial Revolution successful, what are they? Textiles and steel. And what were some of the most important things the East India Company was engaged with in India is textiles and steel. So you see, we have to rethink history. We have to rethink history of what happened and to what extent Britain benefited, not just expropriating capital out of India and not just using it as a large captive market, but also in some of the knowledge transfer. And this knowledge transfer in those days, we did not have patents and intellectual property and we didn't have lawyers wanting royalty. So it didn't happen that way. When I speak to my American educators, one of the questions I ask is, why was Columbus looking for India? Hardly one out of a hundred will kind of tell me. They don't know what, you know. So I said he was not, he was not certainly going there to teach human rights. I mean, most Americans, you see, and the narrative of India I'm talking about is not like you got to do some new research and come up with new things. The dots exist, but they haven't been connected. So for example, the Arabs acknowledged and respected a whole lot of mathematics and astronomy coming out of India. In fact, many of the Arab texts start by giving the name of what text in Sanskrit or Malayalam that they are translating. And then, you know, 100 to 100 years later, some of these texts are translated to Latin. And then we know that they go from there to Northern Europe. And so people like Leibniz and Newton were not out in a vacuum. There were, for instance, the whole theory of infinite theories is very well known and respected by historians of mathematics, where it came from in India. The theory of infinitesimals, and these are all pre-calculus. These are all the foundations for which calculus is made. So we need to come up with a global history of how ideas have traveled. How ideas have traveled from West to East and East to West. And we're all human. It's a network. It's sort of like a very slow version of the Internet. Things didn't happen in milliseconds. They took a long time. Somebody had to go in a boat somewhere. But they did happen over a long period of time. And we have to acknowledge that. So all of this, connecting the dots and redeveloping a true history of India and India's soft power would be a very important thing that Britain can collaborate with Indian thinkers. And this would be something the Indian people would really, really appreciate as a tremendous gift coming back from Britain. And this, I think, is an important proposal I would like to leave. There is a proposal I do not agree with, which says that Britain should give financial reparations to India. Now this is not an original proposal. This is every few years some politician, some slick politician, comes up with this to get some applause. Because it's emotional. But let me tell you, and this has been around since Indira Gandhi's time. When I was in school, they used to talk about it. And we all kind of, wow, wow, wow, you know. But we must move forward in a win-win way, in a positive way where everybody wins and put the past behind us. We have to acknowledge the past. We have to write the correct history like I just described. We have to honor each other, help each other rebuild and reconstruct a positive grand narrative for ourselves. And then move forward into the future rather than us versus you, rather than anger, rather than kind of blame, kind of a mode. So the problem with this financial reparations issue is that it sort of says, you are guilty and I'm going to get you. It's punitive damages. It'll never happen.  It's not going to happen. So the rabble-rousing over-emotional bombastic people in India just looking for some instant populism. I would replace that with something far more important, far achievable, and I call it soft power reparations. That's a term I'm introducing for the first time today. What we should ask for is soft power reparations, not financial reparations. Soft power reparations means the narrative of India, what we teach in our textbooks, what Britain teaches in its textbooks, the ideas of history, these all to be said correctly, not exaggerated but said correctly. And this kind of intellectual exercise is just honesty. It's just a sign of being honest and it doesn't cost money. It just costs heart, just the heart in the right place. So I have a few ideas. First, I think this whole Aryan invasion theory needs to be dismantled. And this Aryan invasion theory was first, this was the early British orientalists never proposed such a theory. I mean, they were fond of Sanskrit. From William Jones onwards, they loved Sanskrit text, but never they said, you know, that we are some Aryans who brought it to you and all that stuff. It was never done. This happened later with Max Miller. He's the one who kind of fathered this theory and this was encouraged by Queen Victoria. But it was great news saying, wow, this is a discovery. If we brought civilization to them in the ancient days, we are just bringing more civilization now. So the Germans, what they got out of this Aryan theory is a sense of nationhood. That we, wow, we are the ancestors of all these great Sanskrit texts for we are a nation. That's why we are so great. So it built the German nation in terms of the German grand narrative. And of course, then Hitler took it into a different turn, which is a horrible thing, because he appropriated this idea for a very nasty purpose. So that's another reason to dismantle such a theory. What the British got out of it is saying, thank you, Max Miller, this is good, because while you guys get a sense of grand narrative for your nation, what we get is legitimization for the empire, because we can say, you know, this is like colonialism 2.0, because once before we went there as Aryans to civilize you anyway, then we didn't have cricket, but we brought you Sanskrit. And now we can give you cricket and we can give you English language, we can give you more. So this business that started in the 1800s needs to be dismantled. And if Britain were, if some good honest scholars with an open mind were to collaborate with their Indian counterparts and publish some works and we could have a few conferences, I would love for my foundation to have a partner here and do a Swadeshi Indology conference right here on this topic and set the record straight. You know, in World War I, 1.3 million Indian soldiers fought on the side of the Allies. More than the combined number of soldiers from all other countries put together. And there is no memorial to them in Britain. The same sort of statistics also for World War II. Now what a great soft power move it would be for the British government to say, let's work together and let's produce a real solid monument. It's not out of blame, anger, guilt or any of that stuff. But just to honor those people, 75,000 Indian soldiers died in World War I fighting on the British side. And another 70,000 were seriously injured. This is very high casualty. And let me also tell you this, many military historians feel that if it weren't for such a large number of brave Indians, Britain would probably have lost the war. And Britain would probably have, this means, ended up as a German colony. And today we would be sitting here speaking German. So this is pretty serious stuff. That a huge event twice in the 20th century, we, our community did. Our ancestors did this. Most of them Hindus. We did this. And they ought to be at least for emotional, psychological reasons. They ought to be in nice memorials some way. So this is another kind of an example of what I'm talking about. Very concrete soft power reparations. I believe that next year, April 19th, 2019 will be the 100th anniversary of the Jalyanwala Bagh massacre. That was a huge massacre that General Dyer ordered a peaceful gathering in Amritsar. And a large number of people were brutally killed, fired. What we also need to be ashamed of is that the actual bullets were fired by Indian Sipois. Indian Sipois killed their fellow Indians in very large numbers throughout the British time. And this Jalyanwala Bagh is not just a disgrace for one man, General Dyer, but also for all the Indians who sold out to do this dirty work. And we generally don't complain about these Sipois, but we should. Because the modern intellectuals who are colonized, who are bringing the same kind of anti-Indian grand narrative, are basically Sipois 2.0. That's who they are. They are the breaking India forces. So this business, so what could we do? So something positive could be done. We should have a conference or we should have something to kind of memorialize what happened 100 years ago.  We don't take ownership of it. Something in the past happened. It won't happen again. Let's move on. In the United States, there's a lot of white-black reconciliation where they teach slavery. It happened in a previous generation. It was a horrible thing to happen and we've now made sure it won't happen again. So having set the record, let's not have this undercurrents of anger and hatred and all that. Let's move on. Let's just move on together. I think it's time that the Indians got out of this old negativity towards the British. It's time that the British acknowledged what has happened. It's time that we worked together and that is what I'm calling soft power reparations. And the benefit will be we will move forward in a win-win way positively as collaborators. That's what I would like to happen. There are certain negative things that Britain should stop doing because these things were part of the old Indian elite, intellectual elite wanting these things. And those people have been thrown out and Britain should stop. For example, this whole overdone caste oppression, we got to fix their caste problem. Well in the United States, there is this US Commission on Religious Freedom and I had a closed door meeting with them recently and I told them about oppression in the United States. And they never mentioned one sentence of that in any of their reports over the last 15 years. And I mentioned that some of this overdone support for Christian evangelism in India is very nasty because that kind of evangelism is not a true change of the heart towards another faith, which is fine. But it's really a pejorative hitting. It's sort of like a militancy to denigrate and bring down the traditions of the country. And I showed them some evidence and they were surprised because they had never heard of this before. No one told them this before. They were being fed things through their channels which were self-serving. So I think there are certain networks, institutional alliances that need to be dismantled. And so Britain should also take with a grain of salt any reports you get from Christian evangelists in India. Basically they want to expand their numbers, expand their market share and they want to do it by claiming that they're bringing human rights. So this whole human rights business is feeding what I call breaking India forces. And it's bringing Britain a bad name and Britain should not be involved in that. Be realigned with those who are trying to build a positive India for all Indians including every kind of a community, every faith, everything. All Indians need to be part of a good positive grand narrative of India. And we ought to construct that rather than breaking each other apart. So that's a project we can do. You know, Britain missed the boat on the globalization of yoga. Americans did it first. Now in the 60s, the Americans discovered that this is a great thing and then they, they've taken them a couple of decades and now there's this globalization of a kind of an Americanized yoga. But Britain had 200 years to do it. Could have been more open-minded and said, you know, these guys, they got something nice also about them. And so it's not just money we can take out of them, but also they have some very nice culture. And this is very good for humanity.  Perhaps Britain missed the boat on the yoga revolution and let the Americans do it. And now there is more happening. The cutting edge of mind sciences, cognitive science, neuroscience is basically taking lots of Indian techniques, advanced meditation, you know, chakra techniques and tantra techniques and so on, and really doing a neuroscientific empirical studies on it. My foundation has done, for 15 years we've been doing research on Indian contributions to mind sciences. I'm writing a book on that on the unacknowledged Indian contributions to mind sciences over the last 50 years in the West, looking at citing Western evidence. And in March we're doing a conference in Delhi University on the Indian mind sciences. So a lot of Westerners are actually already involved in this. A lot of people in Britain and US and various places are very much involved in a new paradigm of mind and how to move it forward which is very Indian when you look at it. So there are areas of collaboration. There is vegetarianism which is becoming popular. There are social theories of aging, of multi-generational families. There are so many areas of traditional Indian knowledge which are relevant today. And Britain can actually be part of that and help build those grand narratives together with us and this would be good for humanity. This could be probably jointly exported. So I will conclude by saying the Americans also did something else that Britain should have done. The multi-trillion dollar technology-led American economy is built, it runs on Indian brains. There is more Indians when you look at Microsoft, IBM, Google, Facebook, Apple and you look at the old technical giants like Bell Labs or NASA. There is more Indians than any other single ethnic group including white Americans. In fact when you look at Indians and Chinese and Japanese, the Asians are majority, most of these places. And I am not talking about low level coding type jobs, I am talking about billionaires, entrepreneurs, leaders, CEOs. Now Britain could have done that but instead Britain is a consumer of Made in America things and these Made in America things are really made by a lot of Indians. So in a sense, I am being a technocrat, I am grateful you guys are good consumers and you are a good market for us. So you see, the Indians supplied the brains but did not have, the Indians have a weakness, this is a tremendous problem for Indians. Indians did not know how to institutionalize. Indians are brilliant as one man here, one there, one there, one there. So the Americans figured out that we give them a home, we give them respect, we give them all the facilities they need and we institutionalize them and we get the best out of them and not hold them below a glass ceiling and then they will flourish. And so creating this kind of an atmosphere which made the USA, the chosen, the most preferred destination for every bright Indian wanted to go there in the last couple of generations was brilliant success for them. But UK could have done it and UK had the knowledge about India and had the clout and the political capital to do it and should have done it and earned a lot of money out of it. So I will conclude by just saying that there is a clash of grand narratives which has been going on since early part of history. You cannot dismantle these grand narratives as a way of getting rid of the problem. You have to develop their cooperation with each other with mutual respect. That is the challenge that we all have to do. And there is a technology-driven narrative of the future. The one thing that won't go away is technology. You can argue left or right or whatever, but whatever you're arguing, it has to be pro-technology. And the fact that Indians have a lot now invested in this and are a big resource should not be ignored. So given these opportunities for cooperation and collaboration between Britain and India, I'm hoping we can take some ideas, take some of these ideas further in a concrete way. And my foundation and I are available and very happy to take the lead with any British organization that would be interested in working with us. Thank you and Namaste. Thank you. Let's briefly examine the justifications for British reparations. Britain led the Industrial Revolution and emerged as the wealthiest nation in the 19th century. Because British textile factories required a steady flow of cheap raw materials, Britain colonized large parts of Africa and Asia. The British considered India as the jewel in the crown because India provided abundant labour and resources. British colonial rule in India was extremely exploitative and racist. Essentially, British industrial development took place at the expense of the oppression of Indians. The Industrial Revolution also made Britain the largest supplier of factory-made products. Consequently, the British transformed India into a market for British goods by destroying India's traditional agricultural sector and economy. Before British colonization, India controlled approximately 25% of the world market. In 1947, when India gained independence, India's market share had been drastically reduced to approximately 3%. According to Mike Davis, millions of Indians died due to starvation in the late 19th century and he characterizes these tragedies as colonial genocides. And what is even more horrifying is that these famines happen at a time when India was exporting vast quantities of food. So to recap, Rajiv Malhotra's proposal for soft-power reparations includes the following. A war memorial in England to honour Indian Army heroes who won World War I and World War II for the Allies. No financial reparations for India. British support for Swadeshi Indology. A total rejection of the Aryan invasion theory and Dravidian's hypothesis. Collaboration with Sanatan Dharmis on neuroscience, yoga, meditation and consciousness studies. Withdrawal of British support for the Indian postmodernist left and breaking India forces. And bilateral collaboration on cutting-edge technological advances and product development.


MBTR June Mark-1, designed and developed by CBRDE Chennai, DRDO, and manufactured by HVF Awadi, is presently serving the Indian Army with valor and vigor. Steered by the visionary leadership of the honorable Prime Minister, new avenues are constantly opening up in the country. Self-reliance in development and production are the pillars of Atman-e-Barbharat. We are committed to building a defense industrial complex that has room for everyone, public sector, private sector, as well as foreign firms. We are committed to establishing two defense industrial corridors, one right now here in Tabelado and one in Uttar Pradesh. One such is the advent of Arjun Mark-1, Alpha, a state-of-the-art main battle tank developed by DRDO with support from academia, OFP, DPSUs, and many industrial partners, Arjun Mark-1, Alpha, is a contemporary tank in the world with battle-winning efficacy. Infused with 71 new features, MBTR June Mark-1, Alpha, ensures effortless mobility to outbeat the enemy in all terrains to size-target engagement during day and night, static and dynamic with remarkable first-ground hit probability and invincible fortification. After extensive trial evaluation, this tank backed fullest satisfaction and recommendation for induction by the user to meet the requirement of the Indian Army and indent for the production of 118 numbers of MBTR June Mark-1, Alpha, will be placed nurtured by the emphasis of the government on self-reliance in defense manufacturing. The 8,500 crore production order on HVF Avali opens up a large avenue in defense manufacturing for more than 200 Indian industries and scores of MSMEs with employment to 8,000 personnel. At this important juncture, a vulnerable Prime Minister is dedicating MBTR June Mark-1, Alpha to the nation. MBTR June Mark-1, Alpha is the shining example of Atman Ibar Bharat.


This study investigated the effects of low-intensity pulse ultrasound, lipos, combined with lipid microbubbles, LM, on polylactic glycolic acid copolymer, PLGA, tricalcium phosphate, TCP, 3D-printed scaffolds. The results showed that lipos combined with LM could increase the proliferation of bone marrow mesenchymal stem cells, BMSCs, as well as the expression of type 1 collagen and alkaline phosphatase activity. Furthermore, it also promoted the formation of mineralized matrix and osteoblastic differentiation. This suggests that lipos combined with LM may be a promising approach for bone regeneration in tissue engineering. This article was offered by Lin Jin, Jelly Sean, Yan Honghao, and others.


All right. Hi, everyone. Thanks for coming. I hope everyone's having a really great Google I.O. My name is Justin Finiani, and I'm the tech lead for the Polymer Tools team, which means that right now we are going to talk all about developer tooling for web components. So the Polymer Tools team maintains a whole suite of tools for web components, developers, and users, from linters to test runners to an entire build system. So obviously, we're going to talk a lot about tools, but tools aren't used in isolation. Tools are used on things, and they're used to accomplish certain tasks. So we really can't talk about tools in isolation either. We have to talk about all three, tools, tasks, and things. Things like web components, obviously, and Polymer, but also progressive web apps, service workers, testing, the purple pattern, bundling, offline, ES6 compilation, HTTP2 push, and something that's maybe the hardest task for some developers sometimes is just getting started. So that was a lot of concepts and words I just flashed up on the screen. And that's not even the complete list. So what does all this mean that we have all these capabilities and responsibilities to deal with? Well, on the positive side, it means that the web is now a capable application platform. We can build amazing and truly native app-like user experiences. But all these capabilities also means that there's a lot of complexity to manage, and this can be pretty challenging. So this is where tools can help. Tools can help make this manageable, and they can help guide you towards harnessing these features effectively and easily. And so on the Polymer tools team, we develop our tools with a few goals in mind. First, we need to meet the unique needs of web components, users, and developers. And when I say that, I do mean web components developers, not just Polymer developers. Our tools are designed to work with all web components. So these needs include things like linting in a world of extensible HTML, documenting all of an element's API surface like attributes and events and styling, or bundling HTML together for production. Then we want to take advantage of the new features the web platform has to help deliver a great user experience and a great developer experience. Features like service workers, native imports, HTTP2, the template tag, and so on. Next, we want to enable and automate the best practices that the community and our teams have been putting together to develop and deploy great apps. Our tool should guide you down the best path by default. And finally, we want to make all of this extremely easy. Our goal is to make our tools as powerful as necessary, but as easy to use as possible. Anyone should be able to create a fast loading HTTP2 pushing service worker enabled offline capable progressive web app with web components that delights their users with a few simple commands. And that's where Polymer tools come in. So now let's do a quick overview of the tools we maintain and how they relate to each other and some of the tasks that you need to handle as a web developer. Here's a little diagram I drew of how our tools are put together. Our tools are organized around a set of core libraries that are task-specific, things like initialization, linting, local serving, building. Empowering many of these libraries is a static analysis system built specifically for the web called the Polymer Analyzer. You'll notice that these tools are laid out here roughly chronologically in the order that you're going to need them during development. And this matches your development cycle from getting started into your editing and running and testing cycle and then through building for production. So we can take a tour of these functions and the tasks they handle going through the development process step by step. Let's start with the Polymer CLI since most of our libraries are integrated and brought to you via the CLI. The CLI is our multi-tool for web components and progressive web apps. It has a number of commands to help you through all phases of development. And we put this tool together and we put everything together into one tool to make these commands easy to discover and easy to use together. And I'm very, very happy to say today that we released version 1.0 of the Polymer CLI earlier this week after a year of development. This was a lot of hard work put in by a great team of people, and we think it really helps web developers. Thanks. OK, so the CLI can be installed from NPM by running npm install dash g polymer dash CLI. And this gives you the global Polymer command. From there, you can run Polymer Help and get a list of all the commands that are supported. So I'm going to go through the most important of these commands. But before I do that, I want to go over a couple of key concepts that we're going to refer back to as we go along. Things like the Polymer Analyzer that I mentioned, the AppShell architecture, and the purple pattern. The first is the Analyzer. So I mentioned earlier that our core libraries are powered by the Polymer Analyzer. The Analyzer is an engine that can parse and understand HTML, JavaScript, and CSS. And it follows the imports between these files to determine your entire project's dependency graph. And by doing that, it knows exactly what you use and where you use it. We then use this information for linting, building, generating docs, and so on. Next is AppShell architecture. So this is a pattern for structuring single-page apps so that they're well-organized, fast, and can be loaded incrementally. Within our tools, we break this down into three special types of files. The first is a single entry point, which is the initial file that's loaded by the browser. The entry point bootstraps your application. And in client-side, routed applications, it's typically loaded from many different URLs, maybe slash home, slash profile, a blog post URL. And it has to be very, very small because this file might not be cached well because it's served from all these different URLs. The entry point then loads the shell. And the shell contains your common application logic, maybe shared UI components like headers, and footers, and menus, but also the router. And when the shell loads, the router boots up, looks at the URL, and decides what view to load. And then we have fragments. Fragments are usually these lazily loaded views, but they can also be other lazily loaded components or libraries. Together, these pieces let you build an app where you load just the files needed to render the page the user is currently looking at. And last, we have the purple pattern. This is a pattern that the Polymer team developed as a way to describe how to serve and render lightning fast progressive web apps. Purple stands for push your critical resources, render your initial route, then in the background pre-cache the remaining routes. And finally, as the user navigates your app, lazily load the routes they go to on demand, either from the cache or from the network. And if we put all of these concepts together, we can look in an example app structure. So here we have the app shell up at top, which lazily imports a couple of views, which then import the rest of their dependencies. And some of our tools need to understand a little bit about this structure. So we let you describe it pretty simply in a file we call polymer.json. And we have fields for the entry point, for the shell, and for the fragments. And then when we talk about purple loading, what we mean is that when a user visits a particular view, you want to push all of the resources that view depends on. These ones highlighted in pink here. And that way they load as fast as possible. And then in the background, you want to pre-cache the remaining views and their dependencies. OK, so that's the end of the key concepts. Now let's get into the actual tools. And let's start off with the init command. I'm going to go to a little demo here and pray to the demo gods. OK, so switch to my computer. All right, hello. All right, so I'm going to start off with an empty directory here. And we're going to initialize a new application with the Polymer init command. So you see we get a menu here of different kinds of templates. We have the element template, the application template, Polymer starter kit, and a template called shop. We're going to choose the Polymer 2 starter kit, which is a really good starting point. That's why it's named starter kit. And you probably didn't see there quick, but it created some files. And now it's installing all the dependencies with Bower. And this is somehow working over the network, so I'm really excited. All right, so there you go. It installed everything. And we can look at the, yeah, yay for the network. So we can look at the files on disk here. It's kind of hard to navigate there, so we'll open it up in my editor. And we can see that it gave us, let's see, a source directory. This looks like we have some elements. It gave us an index.html. This is the entry point I was talking about. It just sets up some metadata, and we have our polyfills and imports the app, creates the app. You can see we also create a manifest for you. This is required for progressive web apps. So by default, we're creating a progressive web app for you. We even have a service worker down here. And then as I mentioned, the Polymer.json file, where we describe our fragments. So looking at the files on disk is mildly interesting, but what you probably care about is looking at how this template actually looks in a browser. So we're gonna use our local dev server with the Polymer serve command. And that's gonna start up a server for us. We're gonna take this URL here and copy it into our location bar. And here we have an app. So this is the Polymer starter kit. You can see it has a number of different views. These are lazily loaded views, so when I click on them, they're being fetched over the network. And if we open up dev tools, we can see here that the app is progressive. That's nice. The menu turns into a drawer. And we can go into the elements panel and introspect what the app created for DOM when it booted up. So here's the main application element. So one nice thing about web components being native to the platform is that Chrome's dev tools now becomes a web component developer tool. Because Chrome understands web components, the dev tools understand it too. So we can see here, if we drill into the application element, that we can see the shadow root. So now we can see how the internals of our custom elements are put together and how they compose. And we can also interact with these elements in the JavaScript console. So $0 would get us the last element and print it on the console. We can see that this element, it's not just a unknown HTM element or a div or something like that. If we look at the constructor, we can see that it's actually the custom element class defined in our application. And because this element, oops, there we go. Because this element has an API that actually lives on its DOM node, we can interact with it. So notice how we can change pages here. We go to view one and view two. That's driven off of property on the element. And we can go ahead and set that to view two. And when I hit enter here, this is actually gonna change pages and change to view two. So dev tools now gives you a way to interact with the structure of your app as custom elements. It can be very powerful. All right, so that's a knit. And let's go back to the slides. There we go. So that's a knit. You saw the built-in templates that it has, but we also allow you to install third-party templates. So this is based on the Yeoman Generator and any MPN package that starts with Generator, Polymer, and Knit that's installed locally will show up in that menu there. And we have some really nice templates that are available on MPM. One that has a custom build, so you can use Gulp. Another that doesn't even use Polymer just shows you how to use vanilla web components. One that shows you how to use Redux with Polymer. And another one that shows you how to use the Vadin elements.  All right, next, let's move on to Linting. So Linting is done with the Polymer lint command. And I have another demo for you if we switch back over to my laptop. There we go, awesome, thanks. So we can run the Polymer lint command and we can see here that, well, we didn't ship you a template that has Lint errors. So that's good. Yeah, yay. So we can go ahead and make some errors and see what the Linter does. But seeing Lint warnings on the command line isn't that exciting. What I'd rather do is show you how we've integrated the Linter and the Polymer analyzer into the IDE with our set of IDE plugins. So here I've opened up the project and I'm gonna go into one of the elements that we have. This is the main application element. And so we can look around and one of the features that our IDE plugin has is hover over documentation, not only for JavaScript, but for HTML. So here I'm hovering over DOM module, which is a built-in element. And we can see we have nicely formatted docs with syntax highlighted samples. So that's DOM module. We can come down to the main template for the app and see if we can look at app header layout and get the documentation for that. So that's really, really useful when you're using elements for the first time. And so one thing you might wanna do when you're editing is use a new element. So we're gonna use one of our favorite elements here, paper button. And hopefully you can see that on the screen, but we have a green squiggly for a warning there and it tells us the element paper button is not defined. And the plugin knows this because we haven't imported that element yet. So we need to go fix that. We're gonna go up to the top of the file here where our imports are. And I'm just gonna copy this paper icon button import and change it to paper button. All right. Oh, but you see we have a warning here too. This says unable to find the file because I didn't remove this last paper icon button. So let's do that. And hopefully you notice how fast that was. The Polymer analyzer and the ID plugins are built to incrementally analyze your files. So we're not reanalyzing the whole project here, just the file we edited. And now if we go down to where paper button was used, we can see that there's no warning. And if we hover over it, we get some documentation. So this will tell you how to use the element and we can see that there are some attributes here. So we might wanna use one of those attributes like raised. All right, so if we start typing raised, we see that we get documentation for the attributes including the data type. And if we hit return, we get the code completion for that too. So this is a really nice productivity booster for when you're writing HTML templates. Okay, so you're using this new element paper button. You might be curious about how paper button works. And so we've also added jump to definition. If you hit F12, we're gonna be brought into the paper button definition here. This is actually in our third party dependency folder. And this even works for attributes. So if I highlight raised and hit F12, we're gonna go to the definition of that attribute within the element. So this brings a really advanced level of ID integration even to HTML template editing. And this also works with all web components, not just Polymer, if you use JS doc and your web components, they too will show up in your IDE this way. Okay, and that's the IDE demo. Back to the slides. All right, so you saw some of the features there. We lent HTML and JavaScript, produce errors and warnings. We have hover over documentation, code completion and jump to definition. For the warnings that we produce, we have undefined elements, properties and attributes. We'll tell you about invit valid binding syntax and invalid HTML imports. We also have rule sets, which we've introduced recently. So we have a Polymer one rule set and we have a Polymer two rule set. We also have added this Polymer two hybrid rule set. So in the Polymer team, we tried to make it very, very easy to upgrade from Polymer one to Polymer two. And as part of making that transition easy, we invented this thing called hybrid elements. And these are elements that work in either Polymer one or Polymer two. And the way they do this is by using that subset of features, which is available in both versions. So this Linter rule set right here will warn if you're using anything that's only available in Polymer one or vice versa. So this should be a big help when you're upgrading from Polymer one to Polymer two. The Polymer ID plugins are right now available for VS code and Adam. And you can install them via the normal methods for installing extensions. And that does it for the Linter. Okay, next move, let's move on to serving. So we have a development server built into the CLI. We do this because when you're developing from a local file system, loading things from the file URL hits a lot of security roadblocks. So most people need at least a static file server. And we added a couple of conveniences on top of that. The first is for reusable components. So HTML imports work a lot like ES6 modules where you have to import by path. And the way we do this is we import by relative path that reaches up out of your package and down into a sibling package that's your dependency. And so if you have a URL that reaches up out of your package that might not actually exist. So what we do in PolyServe is we remap everything to look like they're siblings so that you can access your dependencies without having to do a build step. The other convenience we add for applications. So if you have a client-side routed application with nice URLs, you might have some URL with a long path that the client can handle but doesn't actually exist on the server. So rather than sending a 404, what we do is we send back that entry point file that you set up in your Polymer JSON. And it gives that file a chance to boot up, load the router, and handle the URL, and try to render that URL if it can. And finally, we've added auto ES6 compilation. So all browsers these days, all the current Evergreen browsers, support ES6. But we also support some older browsers that don't in turn support ES6 like IE11. So what we do is sniff the UA string on the server and if we detect that your browser does not support ES6, we'll automatically on the fly compile all of your JavaScript using a very standard preset to ES5. And if this isn't working for you for some reason, Chrome DevTools can do some funky things and pretend to use another browser, be another browser. You can always set a flag to either use the auto compilation or always compile or never compile. All right, so that's the server. Next, let's move on to testing. Everybody should be testing. So we built a test framework into the CLI.  And this uses one of the oldest tools we have on the Polymer tools team, Web Component Tester. And this is a series of helpers that are designed to make testing web components more convenient. So we bundle in popular libraries like Mocha, Chai, Lowdash, and a few others just to make it convenient to write tests. And then we also have this concept in Web Component Tester of HTML test suites. So because custom elements live in the DOM, they're often created by actually being in the markup of your application. And so it's very natural to write tests where you want to write actual markup to test how your element operates. And so we have HTML test suites. And then on top of that, we've added a declarative test fixture helper called, appropriately enough, Test Fixture. So here we can look at what an example test suite looks like. And you can see that at the top, we set up our environment. We import Web Component Tester, and we import the element that we want to test. And then next, we have a test fixture. And this has a template with an element in it. And here we want to test that an attribute sets a property in that element, so our markup contains the attribute. And then when we run our test logic, we call this fixture function, which looks up the fixture by IDs, stamps it to the document, and then returns your reference to the content of that fixture. And then finally, you can run whatever test logic you need. Here, we're testing that an attribute set on the element actually reflects to a property. So this makes it very, very easy to write Web Component Tests. You can launch it with just Polymer Test, which will try to find every browser on your system and run it in all the browsers. Or you can choose one browser with a dash L option. And this will get the test runner started. Launch a browser window, which combines all the results of all your test suites into one window, and then gives you a fairly standard report where, yay, all your tests pass. And hopefully, you have more than two, which I have here. OK, so Web Component Tester is actually built on the same web server as Polymer Serve. So this means you get those same conveniences, like packages being mapped to siblings, or the entry point fallback routing for applications, and auto ES6 compilation so that it's easy to test on IE11. OK, now let's get to building for production. This is the largest or most complex part of the CLI that we offer. And you do this by running the Polymer Build command. But before we get into the details of Build, I want to talk about some principles that we have in the Build system. The overarching principle here is that Builds are optional optimizations on your project. We want your project to work as it is as source on disk. And this is so that you can have a really fast edit refresh cycle without building. So one reason why we do this is because we want to get out of the way. We want this to be fast. But another reason is because you might be using other tools that require building in order to run your project, something like a compiler, like Babel, or TypeScript, or maybe a SAS, or some other processor. So we don't want to have any kind of conflict there, so you'll be able to use those. And our tools don't have to run. Also something that's kind of unique with our tools is that we don't build based on the file locations on your system. We don't build based on globs or some complex configuration. We build based on the dependency graph. So once we're able to find the entry point of your application, we can find all the files that we need to process in the Build.  We want these to be easy to use best practices for progressive web apps. So we have minification, bundling, compilation, and then fancier stuff like service worker generation or push manifest generation. And our Build system forms a pipeline, somewhat like what you would use in Gulp. In fact, we let you use our Build system from Gulp. And the way it works is that the files in your project come through into the analyzer. And that actually discovers all of the files that are part of your project. It then splits them out into your first-party sources and your third-party dependencies, just in case you want to process those differently. And then it feeds them into an HTML splitter. We like to write scripts and styles inline on the Polymer team. So this lets us extract those out into separate files so that they can be processed per file type. So then we go into those per file type optimizations. We rejoin the split files that we created. And then finally, we feed them to global optimizations like bundling or service worker generation. And we control all of this with the Build section of our Polymer JSON file. Here, you're able to specify one to many different builds that you can create while you run the build command. And we have options for all of the different optimizations here. And they're pretty simple. You can just turn them on and off. And next up, I'm going to run through all these options and show you what they do. But while I do that, I want to show you why they matter. Why is it important to run these optimizations? What do they do for you? And in order to do that, we're going to measure. We're going to measure how long it takes to load an example application after we've applied these different optimizations. And of course, for that, we need a test subject. And so we're going to use the shop example application. This was a demo built by the Polymer team. In order to show off and prove out these best practices that we determined are good for PWAs, shop makes a great example because it's a full-fledged e-commerce site. It has a home page, it has product listing pages, product detail pages. It even has a shopping cart in a complete checkout flow. It pretty much does everything but actually ship you the shirt. And so we're going to measure things in Chrome DevTools. And I want to mention something that's really, really important if you're using DevTools for performance measurements. And that's that your development workstation, even your notebook, is likely a lot more powerful and has a lot better internet connection than your users. Most applications these days, their users are possibly mostly coming from mobile devices and are on pretty bad networks. So it's really, really important that if you're going to measure in DevTools, that you turn on network and CPU throttling. So here I've chosen the regular 3G profile, which gives us 100 milliseconds latency and 750 kilobit per second download speed. And then very, very importantly, I turned on CPU throttling, 5x slowdown here. And this is important because your mobile devices just can't parse and execute JavaScript nearly as fast as your laptop or desktop. So before we start diving into numbers, we need a comparison point here. So I took the shop application, and I actually de-optimized it a little bit. And I made it so that it eagerly imports everything. It's no longer lazily importing the views. So this is kind of like a naive structure for building an app. And it doesn't have any minification, and it doesn't have a service worker. So I ran this through DevTools, and I got some numbers. We have 5.9 seconds for first meaningful paint on the initial visit, and 4 seconds for first meaningful paint on a reload. So we're going to apply some optimizations one by one and see how well they do against this baseline. And the first one we're going to do is minification, because pretty much every app does minification. You would be kind of crazy to go to production without doing it. So this is kind of like the standard optimization. It's great because it makes all files smaller. And in our system that splits apart HTML, we also minify inline scripts and styles too. And so the theme I'm going to go with here is that we try to make all of these optimizations as easy as possible to apply. And so we have a couple of options that you can add to your Polymer JSON, which will turn minification on for the different languages. And if we turn minification on, we can see that we've brought our initial load first paint time down to 4.4 seconds, which is 25% better than what we started with. So this is a no-brainer. That's a big advantage, and we should definitely do that. OK, next we're going to look at an optimization we call insert prefetch links. This adds link rel equals prefetch tags to all the entry points and fragments in your application. And the benefit of this is that when you're about to load a view, and it has a bunch of dependencies that need to be loaded, this tells the browser up front the entire list of what it's going to load, so it can download them all in parallel. This reduces a lot of round trips that would be required to load a resource, parse it, find an import, load another resource, and so on. And so you can get some of the benefits of HTTP2 push by doing this, not all of them, but some. So this is good for environments where maybe your server doesn't support it. And again, this is very easy to apply. You just turn the insert prefetch links option up to true, and then we can measure the results. And you see we've gone from 4.4 seconds down to 3.1 seconds. This is another 30% improvement, so this is a great optimization that's easy to apply to your project. Next, let's look at service worker prefetch. So service workers are a really, really powerful tool. They're essentially a background worker, a network proxy, and a programmable cache. But with all that power comes very little guidance and structure on how to use them. Coding one of these by hand would be very complicated and tedious, so we auto-generate one for you. And the one we generate does two things. First, it pre-caches all the dependencies of your application in the background, so you get very fast transitions when your users navigate. And second, it makes your application automatically offline capable. And the way we do that is we do the same entry point fallback routing that we do on our dev server. If the user goes to a URL while they're offline, that's not in the cache. Instead of sending a 404 as a response, the service worker will send the entry point, which allows the router to boot up and to handle that URL and render the view you want to. Again, we want to make this as easy as possible, so you just put add service worker true in your Polymer JSON. And if you do that, you see that, well, our first meaningful paint number didn't really change. It went from 3.1 to 3.2. That's basically in the noise. It's the same. But look at what happened to the first meaningful paint repeat visit. That went from 2.6 seconds down to 0.9 seconds, which is a 65% improvement there. That's huge. And this is a benefit for some of your most important customers. These are your repeat visits or your signed-in users, people who like your app, people who maybe have installed it to the home screen and are tapping on the icon expecting a native app-like fast load experience. Maybe faster than native app, actually, sometimes. OK. Next, let's take a look at lazy loading. Lazy loading is not so much of a tool but a technique. But I want to talk about it here because of how much work we put in our tools to support lazy loading. And the idea with lazy loading is that you only import what the current view needs to render. And you import everything else on demand as you need them. And in Polymer, we have a couple APIs to do this. One is the import href function, which adds a new HTML import to your document. And the other is a thing we've released recently called lazy imports, where you can declaratively describe the lazy structure of your application. And if we apply this to our other optimizations, you see that we've now brought down the first meaningful paint number to 1.9 seconds. And this is another 40% improvement over previous. And the first meaningful paint on the repeat visit stays there at 0.9, lightning fast. So that's good. And finally, I want to talk about bundling. So here's where we've taken care to play well with lazy imports. We do smart bundling. So bundling normally merges all your dependencies into one bundle. And then the more advanced tools like us and Webpack will actually bundle things into multiple bundles if they can detect the lazy structure of your application.  It generates multiple bundles depending on this lazy structure of your application. And the way it works is by analyzing the dependency graph here. So what we do is we look for every file, what is the combination of entry points that require that file to load. And then based on the unique set of entry points that we discover, each one of those becomes a bundle. And so now we can get a very fine-grained bundling that works well with your lazy import structure, no matter what you're lazy importing. The only problem with this is that it's possible to create too many bundles and have a negative impact on your performance. So what we've added on top of this is this idea called bundle strategies. And a strategy takes a bundle manifest, and it modifies it and returns a new bundle manifest. And the one we've included in the CLI has a heuristic where it says, if any entry point is required by more than, say, two, or any bundle is required by more than, say, two entry points. It combines those all into a shared bundle. So you get one per view plus one shared bundle. And this ends up being a pretty good option. And we also make this incredibly easy to use by just simply setting the bundle property to true in your Polymer JSON. And if we apply this on top of all your other optimizations, we get our first meaningful paint number down to 1.5 seconds, which is really fast on the 3G network with a slow CPU. And we still keep that blazing fast 0.9 second repeat visit time.  OK, so next, I want to talk about compilation. It's not really an optimization, but it's required for older browsers. So with custom elements, we have this interesting situation where custom elements have to be ES6 classes. But we support some browsers that don't support ES6. So on one hand, they have to be ES6. And on the other hand, they can't be ES6. And let me show you why this is true. When you write a custom element, you extend HTML element. This is a built-in class very similar to array or map. And when you extend a built-in element, you have to have a real constructor with a real super call so that the system can initialize that built-in object properly. And when you compile a constructor to ES5, you don't end up with a super call. You end up with something like this where you're calling the constructor, the super constructor, like a function. And if you try to do this in a browser that actually has that built-in, it'll throw an error. So again, we have this thing where custom elements have to be ES6, but you can't run ES6 on IE11. So we try to take care of this for you in your tools, in our tools. And what we do is we recommend that everybody write their elements and distribute their elements to Bauer and MPM or whatever as ES6. And then you only compile them, if necessary, at the application level. And this is because the app is the place where you know what browsers you need to support, what environment capabilities you're targeting. And so the app is the thing that knows what compilation needs to happen. And the Polymer Tools help you do this because since we're based on the dependency graph of your project, we can compile all the JavaScript that's reachable from your application. So you can create two builds, one that's ES5, one that's ES6. And if you have a smart server, you can serve ES6 to all the modern browsers and ES5 to browsers like IE11. But not everybody has a smart server, so we've made it possible to produce universal builds that you might deploy to a static file server like GitHub Pages. And we do this with something we call the ES5 adapter, which patches up the custom elements environment on browsers that natively support it and forces them to kind of accept ES5 subclasses of HTML element. And again, we want to make this extremely easy to do, so all you have to do in your build configuration is set compile to true for JavaScript. OK, so that's what build does. It does minification, bundling, compilation, all this stuff. And even though we've tried to make each individual item here as easy as possible to turn on or off, it's still a lot of things to understand, keep in your head, and to configure. So we want to make this even easier. And so recently, we introduced build presets. And we include what we think are the three most common and useful presets for you to use. We have ES5 bundled for your older browsers or for the universal build. We have ES6 bundled for newer browsers, but maybe your network or your server doesn't support HTTP to push. And we have ES6 unbundled for that full purple incremental serving. And so this is what happens to your Polymer JSON file when you use presets. You can go from specifying each one of these individually to just specifying the preset. And again, the theme here is we want to make this as easy as possible. It shouldn't be difficult to build an incredibly fast app even for emerging markets. OK, so that takes us through our whole development cycle from getting started all the way through building for production. Or does it? You can't just build for production, right? You have to actually put your app into production. And so we're adding a new step to the tool chain now, which is targeted at deploying your app. And so now I'm happy to announce that we have a new initiative that we're calling Purple in a Box. And this is a series of purple reference servers. They're smart servers that can do differential serving and serve ES6 to the browsers that support it, ES5 to those that don't, and use HTTP to push depending on whether the browser supports it. We're building out configuration that's generated based on the CLI and your dependency graph for these servers. And we have initial versions for Node that works well on App Engine and also for Firebase. The Node version is the first one we're releasing. It's in a preview state, but you can look at it now. This works for Node and App Engine. And you can look at it at the GitHub organization Polymer and purple-server-node. And you can also install it right now on NPM, just NPM install purple-server. So this server is CDN and edge cache friendly. So even though it serves different resources to different browsers, they all exist at different URLs so they can be cached aggressively at the edge cache. And it also is designed to work with HTTP to push proxies. This is what App Engine does, where it takes an HTTP one server. And if you specify certain headers in your response, it'll automatically turn those into HTTP to push requests. All right, so now that really brings us to covering the complete development cycle. All the way from getting started through editing and testing through production. And that's basically my talk. And if there's any one thing I want you to take away from this talk is that Polymer tools make it really easy to start, develop, and build with web components and Polymer so that you end up with a fast, purple-enabled, offline capable, progressive web app. And that does it for me. Thank you, everyone, for coming out.


Dear students, it is a great pleasure for me on behalf of the University of Siena to welcome you at the beginning of your Erasmus Mobility Programme. The University of Siena is one of the oldest universities in the world with records of its presence in the city of Siena dating back to almost eight centuries ago. Since then the university and the city that hosts it have grown together and now the medieval city center represents the natural campus of the university. The University of Siena proudly participates to the Erasmus program since the very beginning of the program more than 30 years ago. And since then thousands of students from all parts of Italy have come to Siena as well as many students from the University of Siena have moved to several universities around the continent. Here in Siena 1500s of international students enrolled to undergraduate and graduate programs mix together the Italian students and the Erasmus incoming students and creates a fantastic environment in which students from all parts of the world interact with each other. They exchange their experience, their different cultures, their habits and by doing these they improve the knowledge of each other. We are very proud of you coming to Siena in this particularly year and we hope that this will be the beginning of a new post-pandemic moment. I am sure that you will have a fantastic memory of your period spent in Siena and I wish you all a fantastic stay here at the University of Siena. Thank you very much for coming and good luck.