Placeholder Image

字幕表 動画を再生する

  • I never heard so much enthusiasm for a top called Make It.

  • So here we go.

  • Um, so as Paris said on Thank you, Paris, my name is Jeremy Wagner.

  • I am a Web performance consultant and a sort of General Webb tinkerer on.

  • I'd love to thank the organizer's for such a great opportunity.

  • And for you, for your willingness to come to a talk called Make It Boring at a job.

  • A script conference.

  • Okay, turn on.

  • Presented remote.

  • I'm an adult.

  • Okay, so this talk is the live version of an opinion piece that I wrote earlier this year by the same name S O.

  • If you've read that post, you probably already know what you're getting into and before warned, there's not much actual code in this talk.

  • So, like the post, it's based on It's kind of this melange of thoughts and philosophies and opinions.

  • So if you're like, as they close the doors, who are like, you know, I really kind of just wanna like, maybe see something Cody wth e hp track has an awesome talk by Simeon on on chrome extensions.

  • But if you're here, cool, I won't be offended.

  • But thank you for a chilling out anything in case.

  • I hope you like it.

  • Okay, so we have a little echo on us, like Okay, I originally wanted to open this talk with a boring story or anecdote, but that would be boring.

  • So instead, I'll kick things off and talk about an exciting thing And how that exciting thing ended up being so risky and destructive that it wiped out trillions of dollars of wealth.

  • Most of you probably remember the subprime mortgage crisis which played out between 2007 and 2008.

  • Um, before I continue, I'd like to assure you that this is a talk about Web development, not finance.

  • The subprime mortgage crisis was an entirely avoidable economic catastrophe that began with the creation of the mortgage backed security.

  • Exciting, right.

  • The mortgage backed security is a financial product backed by home mortgages that was created long before the crisis ever occurred.

  • And a big chunk of home loans get bundled up into this product which investment banks then offered to investors.

  • It's generally considered a very safe investment.

  • Most people don't default on their loans.

  • This limits the risk.

  • So while returns are relatively modest.

  • They're dependable.

  • Seems pretty boring so far, right?

  • Here's where it gets exciting.

  • When Congress deregulated investment banking in the nineties, investment banks got all jindo.

  • The lack of proper regulations allowed banks to offer high risk subprime mortgage loans and sometimes even these disgusting interest only loans.

  • And then on the investment side came credit default swaps, where investors could bet against the US housing market, effectively rooting for and ultimately profiting from the downfall of the U.

  • S.

  • Economy.

  • And that's exactly what happened as the Fed raised interest rates and an attempt to cool things down.

  • Adjustable rate subprime loans adjusted accordingly, which spurred defaults on a massive scale.

  • And then markets tames taking the economy with, um, all because investing wasn't risky or exciting enough already.

  • This is a perfect example to me of when boring would have been preferable to exciting.

  • If markets and banks have been properly regulated and yielded boringly predictable returns, things would be different today.

  • People would have been set who are set to retire, would have been able to at that time, instead of having to rebuild their portfolios, some people would have been able to keep their homes and just as an aside, and it's a total aside, this is why ethics and regulations are critical, because just because you can flee someone for everything they've got doesn't mean you should.

  • If it sounds like I'm drawing a parallel between the state of modern development and this kind of crisis, it's because I am.

  • But I acknowledge that we are not hurtling toward a comparable crisis with even remotely similar consequences.

  • But we are headed towards something, and the trend doesn't look so great.

  • And part of the reason why this trend persists at least, I believe, is because we're not operating with sensible defaults, and more and more Web development has become more like software engineering.

  • In some respects, I believe this is a welcome and logical progression.

  • But I do sometimes wonder in the dead of night if we're ready for all the responsibility that that entails, because rather than evaluating each individual projects requirements and adapting our choice of tools to them, we tend to dive right into what makes development exciting and fun for us.

  • So, to that end, what do we do when we start a new project?

  • We MPM install a preferred framework.

  • And then we might install a client side router for that framework and then maybe even a state management library for the framework, of course.

  • And before you know it, ah, project has started with an amount of overhead that's baked in until you decide to migrate away from it.

  • Somehow, your preference for what makes development more exciting or perhaps I should say more convenient or comfortable has forced you to make trade offs that could make your app slower, less accessible and less usable.

  • When it comes to software development, there's a word that I think is really important in that Word is constraints.

  • Think of your favorite video games from your childhood.

  • Most Super Nintendo games all the time, could fit on a one megabyte cartridge, sometimes even in 1/4 of that size.

  • This point has been done to death, I know, but it endures because it demonstrates how much could be done with so very little.

  • Yet I don't think it fully acknowledges that the Constraints game developers faced a TTE the time were far more fixed than ours are now.

  • So when developers made console games, they knew every consumer had the same hardware.

  • Those were the constraints, and they were very predictable.

  • Our constraints, however, make our job uniquely difficult.

  • People access the Web on a variety of devices with wide ranging capabilities such as this affordable but slow moto G for android phone.

  • And this is to say nothing of the varying quality of the networks these devices access the Web through.

  • This is a reality which requires us to make architectural choices that are best for people.

  • Because while our tools are convenient and they help us to be productive, they do sometimes confer an external cost on users that we must acknowledge and redress in some capacity.

  • This is relevant because, for example, here in the U.

  • S.

  • While many people live in large cities, which are typically well served by fast broadband and mobile Internet connections, there are gaps even sometimes chasms in this coverage that we must be mindful of.

  • This 2016 article by the M I T Technology Review revealed that 58% of the households in the Cleveland metro area with yearly incomes under $20,000 had no broadband Internet access.

  • These are people who rely on mobile Internet connections, often with data caps and over jizz toe access.

  • The Web Internet access is not a luxury, it's a right.

  • And more striking is this passage in which Pew Research found that 1/3 of Americans don't have an Internet connection in their homes faster than dialogue.

  • I sincerely doubt this is significantly improved since the article was written.

  • The economic and infrastructural challenges have not been sufficiently addressed to broaden broadband access in these areas.

  • And to me, this is a compelling reason to make things boring.

  • Again, I can empathize with wanting to make Web development exciting.

  • It's a big reason why I started doing this stuff in the first place, and when I started, I wanted to do everything.

  • My first experience with making Web pages was in a wiz e wig editor in middle school, and once I hit the limits of what that thing could do, I had a novel thought, which was Hey, the hell happens when I opened this here index dot HTM and a note pad that thought clearly changed my life for the better.

  • I think it's fair to say that I wouldn't be standing here in the state if I hadn't done that everyone in our industry has an origin story.

  • And for many of us, that story begins with the making of the fan page, for whatever thing we're obsessed with at the time.

  • And for me, that obsession was fixed on the just fixed on the popular first person shooters of the day, like Doom and Hexen and Quake and the obsession itself was irrelevant.

  • But But it gave me an excuse to propel myself down a path of relentless and sometimes reckless experimentation.

  • I wanted to do everything everything, I mean everything.

  • I wanted to put every last bit of new knowledge I acquired about making Web pages to work right away and in the most glaringly obnoxious way possible.

  • Apparently, yeah, that's that's mine.

  • Don't go look for it.

  • And in my fervour, I was inspired to make countless garish sites with horrid color schemes, scrappy animated GIFs guest books that no one ever signed.

  • Webb brings that.

  • No one ever joined.

  • And then there was a flash.

  • Oh, Flash.

  • Three operations of my personal website were crappy to advance knockoffs, where cosmetics and flashing animations won out over literally any kind of sensibility.

  • And like anyone, my inspiration was just a conduit through which I developed my skill set.

  • But what I didn't develop for the longest time was disciplined.

  • I didn't understand basic design principles, accessibility, performance, user experience were literally anything that would help me to make websites anyone would want to use.

  • And that's not to say that my excitement for the medium or our excitement for the medium is ill motivated.

  • I was just inexperienced, but the work that we're paid to do requires us to build boringly usable things.

  • Sometimes that work is the equivalent of creating digital push brooms.

  • Their ordinary is hell.

  • But yes, they're also tools that help people accomplish tasks.

  • Online banking, job applications, buying essentials for the home you name it.

  • When our excitement for building for the Web's coupled with our thirst for pushing it to doom or all the time we could inadvertently build heavy, unusable things that can hinder rather than enable people to complete the tasks are work enables them to achieve.

  • And so to that end, many new developers these days aren't entering the industry with a decade of learning and experimentation under their belts or even a four year degree boot camps are a big thing.

  • They're people who are both new to and really excited about, building stuff for the Web and making a living from that work.

  • And we need these people among us.

  • They're going to be the next generation of developers That brings renewed fervor to this industry, and I can't wait to see what they do.

  • But this isn't an experience that I can speak to you.

  • As my path was so radically different, I didn't join a Web developer boot camp and make a living off of my skills.

  • Within a year, I had 10 years of unfettered experimentation before I could make anything that anyone would want to use or consider usable.

  • It takes time and continuing education to develop these sensibilities.

  • And because employers favor skill sets that prioritize the fastest way of building applications, that means they're going to hire people who know today's frameworks.

  • And so the fastest way to start getting paid after you graduate from boot camp is to apply for jobs that match the framework based skills they taught you in boot camp.

  • Thus, hiring in the industry has become an aural boroughs where employers want applicants with framework specific centered skill sets.

  • And consequently, developers learned those frameworks to get gigs because hiring managers want to tick off the boxes and get Debs to ship code fast and often.

  • And so in this seemingly infinite loop, frameworks become the scaffolding upon which we build our careers.

  • This isn't the worst thing that can happen.

  • Framework and library specific knowledge can propel you tow, learn their underpinnings.

  • I would never would Have Went is deeply into JavaScript as I have, if not for the awesomeness.

  • That was Jake worry in the late to thousands.

  • But I believe that a sole reliance on these abstractions can eventually become a limiting factor in your long term growth.

  • And unless your curriculum sufficiently covers the fundamentals where you had to learn them on your own, you'll always be reliant on the abstractions to do the work front.

  • And development has been this way for about a decade.

  • More so.

  • Read the resume of any veteran front and developer, and you'll quickly see that it resembles like a geologic column of different skills.

  • This industry has always chased what's so hot right now, and we're set up from Day one of our careers to feed into that.

  • Arguably the worst part of this is that our continuing education in HTML CSS and platform AP eyes gets relegated to someday or worse after hours where you have to sacrifice some amount of work life balance just to keep up.

  • And by the way, not everyone has the time to devote in their off hours to do that work.

  • They have families, they have responsibilities.

  • In my opinion, we shouldn't compel them to, but rather enabled them to explore and learn on the job.

  • And all of this is ostensibly done in the name of productivity, sometimes at our own peril.

  • This constant churn, as Rachel Andrew suggests in this very brilliant post I suggest you read, has us bound to a cycle of never ending sight rebuilds and framework migrations that can seem counterproductive in hindsight.

  • And so, without careful consideration for which abstractions air truly beneficial for the purpose you're trying to serve, being lashed to this wheel becomes a brutal affair where progress becomes difficult to sustain over the long term.

  • Whether it was Jake, hurry then or react.

  • Now, these tools are designed to make us more productive, and they Dio.

  • But if we were pressed to admit it, this constant Sharon is at least in part due to our desire to make our work more fun and exciting.

  • And it's something I like to call laptop sticker culture, something.

  • We can't see it from here, but something I'm clearly guilty of, where everything we do outwardly appears bad ass or glamorous.

  • And if I didn't know any better, I'd swear some of us are on tour.

  • It's also like even in the year of our Lord 2019.

  • You still see job postings every so often with these superlatives like Rock Star, Guru or ninja like a my supposed to pack some schurick ins with my laptop.

  • But, hey, why shouldn't our work be more fun and exciting?

  • A lot of career fields of boring drugs work shouldn't shouldn't be more exciting, right?

  • Ah, we're all propelled by our interests, and for you that interest could be Java script and friends.

  • Could be HTML could be CSS, or it could be the various abstractions of these technologies.

  • But if you could for a second, put aside your interests and ask yourself what what's the purpose you're trying to serve When you build something for the Web, what do you helping people to accomplish?

  • The varying answers we give to that question should form a curve around which we adjust our philosophy for how we build for the Web.

  • Because if you're in charge of any remotely critical resource on the Web, your desire for a rich developer experience simply must take a back seat to the task.

  • People depend on the Web from more than just buying shit.

  • The Web is a portal for many.

  • Critical resource is stuff like job applications, public assistance, crisis intervention and other service is we tend not to think about until we need them.

  • Ours is a job done by people.

  • Four people.

  • Plumbers might get excited about pecs piping, but they also understand that their job is to ensure that the water gets from the main to the faucet, the same as before.

  • Pecs Pipe confers a material improvement for both installers and end users without hampering functionality.

  • Can we consistently say the same thing about all the conveniences that we rely on?

  • Data flows through pipes of sorts, but the environmental constraints imposed on us by the network and the devices people use demand.

  • Our most careful consideration factors, like network bandwidth and Leighton see, are quite evident.

  • But others such a server protocol or device capabilities are a little more subtle.

  • And then there's the person holding the phone or tablet or sitting behind a laptop, each of which is an individual case study of capabilities and limitations that demand our attention.

  • And so, knowing this, I think it's important we avoid one assumption, like the plague, which is that our convenience is always confer equal benefits for user's.

  • Your enthusiasm for virtual don frameworks probably doesn't benefit someone who's been thrown out of their home by an abusive partner when they turn to the Web to find shelter.

  • Someone trying to find public assistance information or apply for a job in spotty WiFi isn't helped by your client side router.

  • Someone are.

  • Our conveniences have a time in a place, and that time is not always every time.

  • Nor is that place always every where, and I'm not shaming anyone here for their choice of tools I use.

  • I use tools.

  • I love them, but to stress that simply using them won't do the difficult work of design and user experience for you.

  • And so as developers, our ethical duty isn't limited to identifying and removing.

  • Excess is in code.

  • We also need to challenge excesses, which may look nice and design coms, but only served to frustrate people in practice.

  • Excesses and design and development are necessarily intertwined.

  • Every interaction you can simplify every boondoggle you can remove represents a benefit for the end user.

  • So let's make it boring.

  • The Web is frustrating when it creates obstacles for people.

  • An obtrusive nous in websites are the result of every project manager, designer and developer unwilling, or most the time unable to question ill conceived business requirements, design decisions or architectural architectural choices?

  • It's on all of us, And Josh Clark wrote an article about design systems a while back, and what struck me was his emphasis on the role of boring and you ex.

  • I'd be lying if I said I wasn't inspired by this.

  • Talk wasn't inspired by this a little bit.

  • He discussed how when he helped his clients to create design systems, he stressed the importance of simplicity and unquote, the more common the problem, the better design systems should prioritize the mundane and in a world where everyone feels like they just want to disrupt shit without considering the consequences.

  • This is sage advice, and for me it's a kind of revitalizing tonic.

  • Avoiding obtrusive nous and design is the very soul of designs that work best for people.

  • Without acknowledging that we can on Lee, create fast, accessible and usable websites entirely by accident.

  • A perfect example of obtrusive design was a little known visual ization project developed by Apple's research division called Hot Sauce, which was an attempt at visualizing site maps for websites.

  • Instead of presenting this data in a very straightforward way, it was presented as a three D special field.

  • To its credit, Hot Sauce was a novel presentation of this data.

  • It was need.

  • It's a fun experiment, but no one wanted to browse a spatial rendering of a Web Sites hierarchy as if they were on the Holodeck.

  • They wanted a boringly predictable and utilitarian way to access that information.

  • A new ordered list, maybe examples of obtrusive designers they exist on the Web are a little different.

  • I don't know about you.

  • I don't even like one hamburger menu, let alone three of them.

  • It's not excitement that produces patterns like this.

  • I don't think maybe I God, I hope not.

  • But a sort of unwillingness or inability to address the unsustainable growth of an application over time.

  • Eminently usable designs and architectures result when simplicity is the default.

  • It's one of the iron laws.

  • It's why unstylish HTML just works.

  • It's so beautifully solves the problem of presenting documents to the screen that we don't consider all of the careful thought that went into its jaw, achingly boring presentation.

  • Now I'm not holding a torch aloft and marshaling the village people on demand that we transport ourselves back to the aesthetics of 1994.

  • That would just That's absurd, and it's antithetical to the spirit of progress.

  • But I do think that this ideal is something that we can carry on in our daily work, especially when more websites are consumed as Web APS.

  • We could make APS more resilient by adhering to semantics, platform solutions and progressive enhancement.

  • And as it stands, we're accustomed to serving heaps of DIV burgers on silver platters of Java script that not everyone can access in all the places they may need to.

  • Accessibility advocates aren't lecturing you screaming at you to use semantic html because it's just like so much fun you'll pass out, but because it's well understood how people benefit from it.

  • The built in functionality you get from those semantics allows you to travel lighter as you won't need to build or install accessible alternatives.

  • Does this mean your choice of tools are in direct opposition to the goal of creating good user experiences?

  • That depends depends on how you use those tools.

  • It at least requires us to understand the trade offs we might be making if we choose to use them.

  • So we need to buy for Kate, are focused on what we learned.

  • We should learn frameworks in abstractions, yes, but we also need to learn the platform AP eyes that server that serve as their foundation so that we can adapt more nimbly as the wind shifts.

  • The long term health of the Web cannot be sustained if we ignore what the Web platform brings to the table solely for our own convenience.

  • And underscoring the importance of those fundamentals is the fact that we're wired to want things to be boringly predictable.

  • We not only want it we expect it and subconsciously demand it.

  • So when things were predictable, they embody the expected qualities of the essential.

  • We don't want any surprises.

  • With the plane's landing gears become in for a landing, that is not excitement I can get behind.

  • This is an example of a critical fixture and some of what we preside over as developers are also critical fixtures of a sort.

  • Thes fixtures especially need to remain fastened accessible.

  • Part of getting there necessarily involves relying more on HTML CSS and platform AP eyes to reduce overhead.

  • And if your reaction to what I'm saying is to assert that this is boring work that will create boring websites that users will find boring.

  • Then I must viciously retort with the emergence of reader mode features that exist in several browsers.

  • At its core, reader mode is just a boring mode toggle that strips away scripts and styles to distill a page down to its core content.

  • People are so tired of grappling with stuttering, script laden pages that the will gladly strip away everything exciting to get to that crucial nugget of content more easily.

  • Still, reader mode won't work everywhere, and we shouldn't expect it to.

  • It's intended application for is for written content, like articles, not rich applications.

  • Solving human problems does require a human touch, after all, and so to that end, we're wired as human beings to want external consistency, which is when objects function and recognizable Appearance is reinforced by other similar implementations in the environs.

  • Imagine a house with zero external consistency.

  • We're turning.

  • Turning the knob on the stove changes the television channel or flipping the lights, which flushes the toilet and has aired, Bailey notes in an article on a list apart.

  • And I highly recommend you read this and follow him.

  • He is an excellent person in the accessibility field.

  • Browsers themselves are flush with examples of external consistency, and we would do well to ensure that we don't break those externally consistent behaviors.

  • Now I am fully aware of the danger of saying this on stage any job, a script conference.

  • So hold your tomatoes for a second.

  • But one of the most common some versions of external consistency and browsers is the single page application or S P.

  • A.

  • My personal inclination is to avoid building sites, is S.

  • P.

  • S.

  • This isn't because I hate, um, all right, don't understand how they work.

  • Or I think they're filthy, filthy, dirty, awful things.

  • It's just that the behavior they replace is one that browsers already do very well.

  • When we decide to take on the task of implementing that ourselves, we are taking on a lot of unnecessary responsibility and risks.

  • In many cases, how browsers navigate from page to page is part of a specifications arrived to after a deliberative process of debate and consensus and continual improvement.

  • And in my opinion, it takes a whole lot of courage with just a dash of hubris to assume we can do this better than browsers have done in 25 or so years.

  • And when a client side router is used, accessibility can become a casualty in that effort.

  • There's a whole host of things.

  • We end up reinventing or miss altogether, or shift beneath us.

  • As things change.

  • History must be managed.

  • Tab, index and scrolling position must be accounted for.

  • Navigation canceling can fail, and so on.

  • Even if we get client side rounding, just perfect.

  • There's another problem we have to grapple with, which is when we neglect to send server generated markup in favor of rendering everything on the client on amps.

  • Contents air not only inaccessible if and when, when, by the way, JavaScript fails.

  • But loading performance suffers as well.

  • When we serve content from the server, sure, we lose that snapping this after the initial load.

  • I will concede that gladly, but we retain that external consistency that people respect or expect.

  • Sorry.

  • That's not to say that we can never use client side routers.

  • If you provide service side versions of all your client side routes, people will have a way to access your sight from literally any context, whether it's a link from the outside or an internal link.

  • And then, if components are attached to server side mark up through client side hydration, people are going to get a progressively enhanced experience that gives us freedom a lot of freedom to try different things.

  • Perhaps only the authenticated part of your app is an SPF or and I like this, and I've been experimenting with it a little.

  • Perhaps client side routing could be opted into as an upsetting ensuring it only happens if people want it to where we make no assumptions which brings me to my final point and the end of my talk.

  • No tool or any amount of automation will ever be a perfect substitute for a human's judgment, which is which is finally honed over years of experience.

  • Solving human problems and solving human problems necessarily requires that you accept that humans have limitations either inherent or imposed.

  • It also requires you to accept that the tools you use can fail you in some ways, and your judgment is necessary in those situations.

  • Let me tell you another story.

  • This is Stanislaw Petro.

  • He was a lieutenant colonel in the Soviet air forces during a dangerously tense period of the Cold War.

  • While he was on duty in 1983 a brand new Soviet missile detection system reported that five nuclear missiles were launched by the United States and on the way to Russia for a reason and no small amount of intuition, he was convinced that the system was wrong in the moment, he concluded that five missiles was illogical because a U.

  • S strike would have been all out.

  • So he did not inform his superiors and therefore a retaliatory strike was never authorized.

  • He turned out to be right.

  • The system was wrong, turned out to be sunlight reflecting on some clouds above North Dakota that triggered the false positive.

  • So why will never know all the factors that play of the various levels of command in this situation?

  • It is not unreasonable to speculate that his decision to disbelieve the tools at his disposal when the time came for it may have averted a global nuclear war.

  • Obviously, no JavaScript engine here in this room will ever be charged with such a perilous decision.

  • I hope not.

  • Let's hope that JavaScript isn't the mechanism on which that operates, but I think it is a great lesson about how the tools we depend on can still get things wrong.

  • If that was, if that wasn't the case, every get hub issues.

  • Page would be a ghost town.

  • Zero issues zero p.

  • R's a 1,000,000 stars for everyone.

  • Yeah, so it is on us to realize and own up to our responsibility to people, as well as how our preferences as developers and the needs of real people can intersect in a way that's mutually beneficial.

  • And knowing where that intersection lies involves realizing that while inaccessibility inspector can tell you what semantic elements you should use knowing why those elements are preferable to a dib soup is Justus vital?

  • It's also realizing that why you could install a layout framework.

  • Such problems are best solved by relatively new and widely supported CSS layout modes such as Flex Box Ingrid.

  • In fact, if you want to create layouts that catch the eye and push the boundaries beyond the ordinary, you need to rely on these new layout modes.

  • You can't keep kicking that bootstrap can down the road people, because not only is the overhead of bootstrap onerous, it's just not where the Web is destined to go.

  • Nor will it allow you access to the full power of these new layout modes.

  • There are people called you.

  • I engineers hire them.

  • For all of my win Jing, about the evils of JavaScript and all the simple excitement it and its framework brethren bring, I firmly believe it has its place.

  • This is not a diatribe against JavaScript.

  • I believe Java script is great.

  • It's given a lot of us a living, and I'm thankful for that.

  • But we do need to re balance or use it against other parts of the Web platform.

  • Job script is most resilient when we can use it with progressive enhancement in mind.

  • That's to say when we could build a baseline everyone benefits from and then add that candy coating to enhance usability further for those who can benefit from it, we're not just building better user experiences, but more inclusive ones.

  • And that, to me, is the really good work.

  • That's worth doing, because inclusivity is not something we should just make room for conferences.

  • It needs to be a part of our daily work.

  • If you care about the Web as I know you all do, because if you're here, you definitely care.

  • You'll come to find out that this approach to our work isn't boring at all, but really quite rewarding.

  • We have two objectives as developers.

  • One work to make things better this week than they were last week, and two continue our education to ensure the success of the first objective.

  • I genuinely, truly believe our work can never be boring, so long as it helps us deliver on these objectives in the spirit of making the Web faster, more accessible and therefore more usable for everyone.

I never heard so much enthusiasm for a top called Make It.

字幕と単語

ワンタップで英和辞典検索 単語をクリックすると、意味が表示されます

B1 中級

Make it Boring - Jeremy Wagner - JSConf US 2019 (Make it Boring - Jeremy Wagner - JSConf US 2019)

  • 1 0
    林宜悉 に公開 2021 年 01 月 14 日
動画の中の単語