-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathtalk01-responsive-adaptive-responsible.txt
201 lines (161 loc) · 6.48 KB
/
talk01-responsive-adaptive-responsible.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
Responsive Adaptive / Responsible
the web as a platform we dreamed up is based on a few
beautifully simple principles
maintainability
accessibility
predictability
flexibility
extensibility - whatever you build should be easy to extend
these principles have always been challenged
products don't start as services ideas or content, but as
visuals
a false belief in "this should look the same everywhere"
a flawed comparision with more defined, specialised
environments
"we don't have time for you to craft - just release this
thing and we'll fix it later"
the bigger problem is that we have internalised these challenges
do we need to release more and faster all the time?
are we ok with building and discarding everything we do over
and over again?
are we just plumbers of the web, or is it time to call the
shots?
as developers of the web, we live in a world of promises...
every week or so there we have some new, incredible tech to play
with...
web componetns
service workers
emscript
incredible - adjective 1. impossible to believe
incredible = lacking responsibility
everything these days is experimental
many things need non-standard code or flags to be turned on
**** missed a line***
impatience and abstraction
to make things work, we write abstraction libraries
to make these mmore reusable, we base them on other libraries packages and frameworks
almost every single one of these ********* (was drinking
more coffee and missed it again)*****
so who do we innovate for if we can't use it in production?
ourselves
we have great jobs, we shouldnt feel unhappy or stressed
things do not burn when we make mistakes
the environment we work in flows like water, there is a
constant need for new ideas
we need to be the masters of uncertainity
we work in a publication medium, not a software platform
it is time to be more resposible for our work
always question authority
browser innovation
standards not implemented in browsers
magical abstractions
impressive looking tool chains and development packages
blind faith in abstractions and browser innovation lead to a
terrible state of the web
don't allow scapegoats to get in our way...
i joined microsoft to help with one very important fix the web
very much needed
microsoft edge
the plan was simple:
burn ie and let a new browser emerge in the ashes (ie
firefox)
the idea was to get rid of all the bad ideas of the past
list of bad IE stuff
we were too late...
replacing old with agreed upon new stuff
never trust a user agent
experimental? probably safe to use..
webkit-appearance: none
webkit-gradient
thigns you learn when you write a new js engine
chakra the javascript engine that powers microsoft edge (a
link, google it)
only a 1/3 of the top 3000 sites can benefit from JS
inlining. reason is lots of scripts instead of
concatentation.
you need to optimise a lot of JS in the engine (length
reading on every iteration of for loops!)
outdated libraries are still very much in use and clash with
new JS features (mootools breaking with array.contains(),
zepto disliking array constructors)
minifcation used a lot on the web and uglifcation ** MISsed
some stuff**
things i learned working for browser makers
it is a constant race not to break the web - every mistake
web developers make needs to get catered for.
the pressure is immense. instead of pushing for an
interoperable web, browsers are constantly compared and
expected to be different.
when implementing standards, we find a lot of problems and
feed them back. that's why a score of 100% in feature tests
make no sense.
most speed increases are based on analysing and fixing
developer issues ** missed some stuff**
we're stuck in a loop of demand and flawed supply..
and now we need to concentrate on getting one thing right...
ES6 comes with so much goodness, technically it must be fatting
all of these parts have different audiences
syntactic sugar
scalable apps
library builders
support is encouraging, but also patchy
http://kangax*******
the problem: for non-supporting browsers, ES6 are syntax errors
turns out, you can feature test ES6
http://featuretests.io
if you want to use it all: transpiling into ES5
babel
the problems with transpiling:
it adds an extra step in between writing code and running it
in the browser - probably the thing that made the web grow
as fast as it did
you don't run or debug the code you write
you're at the mercy of the transpiler to create effiient
code
you create probably much more code than you need
browsers that supprot ES6 will never get any.
how does it perform compared to ES5
some link i didn't get...in general its slower except for
the new features
the ES6 conundrum
we cant use it safely in the wild
we can use typescript or transpile it
we can feature test for it, but that can get complex quickly
browsers that support it, will not get any ES6 that way (but
can use it internally)
the performance is bad right now (which is normal.) to
improve this, we need ES6 to be use din thew ild
help ES6 by looking at its unit tests
http://github.com/tc39/test262
http://es6katas.org
lets go back to a good principle of html5 design
"in case of conflict, consider users over authors over
implmentors over specifiers over theoretical purity."
we live on too many empty promises
tooling will save us in lots of cases, but we shouldn't have
to counter bad decisions of the past with more code
it is great and necessary that borwsers innovate at
different speeds, but unless that innovation lands in all of
them, it is dangerous to use.
not everything that solves a problem has to become a generic
solution. going generic always come with bloat.
we won't achieve much punishment
our end users should never have to change enironment because
of our code (other reasons, of course, apply)
blaming the tool is a sign of bad craftsman, good craftsmen
improve the tools by feeding back to the tool maker
it is not your fault you're not too stupid, we just liek to
show off too much.
love and passion trumphs everything
love responsibily <3
everything you do is for your end users - great UX is
invisible, so should our code issues
what you use and makes you happy is not what others have -
consider yourself lucky, not better
if you love the web, keep it clean - remove outdated code,
keep helper tools up-to-date
it is people like you who created the things that annoy you
- explain your issue, ask for reason's and you'll see fixes
good things take time - let's slow down our pace and build
better, not faster.
@codepo8