Sumo Logic, AMD, Aws Services discussed on Software Engineering Daily


These sumo logic continuous intelligence report contains statistics about the modern world of infrastructure structure. Here are some statistics. I found particularly useful. Sixty four percent of the businesses in the survey were entirely the on Amazon web services which was vastly more than any other cloud provider or multi cloud or on Prem deployment that's a lot of infrastructure on aws. Another factoid. I found was that a typical enterprise uses fifteen. Aws Services and one in three enterprises uses aws. Lambda appears server. List is catching on. There are lots of other fascinating. Statistics in the continuous tenuous intelligence report including information on database adoption Cooper Netease and web server popularity go to software engineering daily Dot Com sumo logic and download the continuous intelligence report today. Thank you to sumo logic for being a sponsor of software engineering daily Kevin Ball welcome software engineering daily. Hey Jeff good to be here. I'd like us to take a tour through the modern world of Java script and the place I'd like to start is es modules explained es module as well. Let's start by going back a little bit to talk about how modules in javascript sort of evolved over time so unlike some languages that start with this concept concept of code isolation modules and things like that javascript when it originated everything was in global scope. There was no concept of a module in separating things in pulling these out because it started as is a play language on the web and then as people started to do more serious software engineering with javascript. They wanted to use good practices like code isolation and things like like that and so initially there were a bunch of what you might call user space solutions to that folks who basically built up using the language as existed ways raced to create modules. That's where you get things like. AMD which was one of the the first sort of specifications you could call. It was essentially like once again user space space specification. If you write your code in this way it will work with this tooling and we can loaded dynamically you get nice isolation things like that over time the language which became more mature and folks started saying. Hey we should actually have a first class solution to this. The first thing we got to that was when no J. US came around and they said. Hey we're reading Service side packages. We need a way to do this. We're not going to be shipping stuff up to the browser. Were not an isolated. In the same way we don't have as as limited scope in the same way we're we're just GonNa make something happen and that was based more or less on. AMD and common jazz which is another sort of specification that came on that and that became the the defacto standard as node and require which is common approach and then it went up one more level and it said okay node while very very large and very popular and able to drive this defacto standard. That's not actually the language we need a language level solution for Howie encapsulated slate code and allow it to load in different ways and that was when. Es Modules kind of evolved so this is something coming down from the TC thirty nine specification community the script specification nation where this is how modules function in the language of Javascript as defined at the SPEC level. So it's no longer user space. This is actually baked into the language language and accessible. Now because it's the web and it's messy and all these other things there's been all these back and forth about okay. What about file extensions? How does this change different things? Because many of those defacto standards around node had built up lots of tooling and magic around the Senate in lots of ways that turned out to not actually work when you try to do them in cross environment situations like. How does this work browsers compared on a server? So there's a lot of stuff there that has really been getting hammered out and still coming in. But that that's the high level lizzy s modules are the language level. Now we're bringing it down into the actual specification solution to a problem. That's been solved in user space. For years there's a classic example of a module that we needed is J. Query right like J. Query is this big blob of things that we need out of our Java script infrastructure and historically we would just import it on a global basis and we would have it available to our entire Java script application and that was not perfect but it did the trick. What is wrong with that architecture? Why is it problematic to have a global variable? Why is it problematic architecturally global variable? I mean this is actually an interesting question. Because I think that's a lesson that gets over applied and it gets fought about a lot in the web world when you start talking about CSS which is still in many ways global in different ways the fundamental challenge with having having things that are global is. It's really easy to break them. If you're trying to pull in code from lots of different places that have perceptions options about what this thing is in. Is it going to be there or not going to be there and can I manipulate if there's just one than those things can mess with each other and break with each other and it especially if you look at the javascript ecosystem today. The trend is towards lots and lots of small packages the tooling rolling around packages and package installation dependency. Management is so good that people said why have large packages when it's just just as easy to do ten small packages than each one of those as a tiny surface area. I can test and do things. That ecosystem doesn't work if everything's global because if I'm installing a thousand packages it is and each one is depending on something global that they can actually mess around with and mess up very quickly. I'm going to end up being a territory where one of those is expecting one thing. The other one has already manipulated in some way and so it's not quite matching expectations. If you're going to be integrating different pieces of code where you don't control everything at which is fundamental to modern software development general right like old days you look back browser applications. They're relatively simple. They're small the entire code base can be owned owned by one person or one team whereas nowadays if you look at a modern web application look at your g mail or facebook or one of. He's really advanced products. They've got maybe half a million lines of Java script if each team that's working on that that's probably spread across five six ten twenty teams like if each one is able to muck with these variables. You'RE GONNA shoot each other in the foot real quick just to revisit what problem problem do. Es Modules solve. Yes Ma tools solve. How do I isolate code into its own package? Essentially whether it's within within a single application or package or an external one and reliably pull that into my own application or into another package to us. It's the same problem problem. That essentially like gems. It's actually. It's a little complicated because it's also how you do code imports so like you could think of a package. Any yes module is the equivalent of like even just importing code it built into the language of python or go or something like that where you can import code from one file Allie to another file that literally did not exist as part of the language before it was packed together with user space tools. That would sort of put that together for you right right. So it's this fundamental problem that most languages had built in from the start like you wouldn't imagine writing a python application where you couldn't import code owed from one file into another file but that was all user space solutions that wasn't part of the language prior to guess module why have. Es Modules been controversial. Well partly because they're in the web and the web. It's probably the I. I don't think it's out there to say that the web is sort of the widest and most diverse set of software. Stuff that exists right. Gets you have things that are running a distributed environment across every device known into man. You have no control over how this thing is running where this thing is running other than it in the browser and so people did all sorts of crazy stuff on top of you've got server side solutions javascript with node where you have that more traditional environment there were already solutions that existed there that had been built up that are subtly incompatible with yes modules. So you have the javascript. Language being specified by folks were mostly concerned about the web. They're mostly people coming from rob Browser companies thinking about that use case. And they're trying to build something that is also going to be utilized on the server where there are already subtly the different approaches being used. I think they're also just missteps along the way there were you'll waste of people trying to make them kind of different aren't than just being javascript. So there is an introduction of okay. We're GonNa tell what the module and what's not by having different file extension and that was problematic because in the node world where where people were mostly thinking about packages like everything is just file extension. It deals with do that for you. Don't even have to include it file extension because note. Has this magic about looking up. Is it here is it there. And what have you so it you created these situations where you had had could have discrepancies. From the way people were used to thinking about the world one other aspect that I think is worth bringing up here is pretty interesting in also relates to why EH. US modules have been very controversial is in the Java script world. We've gotten used to using features before they are fully specified because there is incredible tooling that essentially allows you to transport within the language so you can extend javascript at new functionality and transparent trans pilot back to older functionality. The tooling for this is called babble. And it's a transporter and the original use case was okay browsers. Thor's are slow to update and in fact looking back five years many of them did not automatically update so a user had to go and actually do something to update their browser which meant that even though Oh javascript was moving forward in adopting features that were valuable turn bringing it from being a toy language into a first world are high productivity extremely powerful language. You couldn't write code in that way and run it on those little browsers unless you had a way to translate that new tax in this new code back discipline. Those browsers could understand so John Has Gotten used to using features and compiling them back to older browsers now. This meant that when people started talking about Yes yes modules and they said Hey. This is a really cool syntax. We're GONNA do this. They could use it before it ever got specified or built into any platform. It was not built in any browser. It was not built in to not at all and people started using it by using babble to Trans file it and using web pack to and.

Coming up next