Here are my notes from ForwardJS:
My favorite talks were:
JavaScript: Mastering Chrome Developer Tools
The Web meets the Virtual and Holographic Worlds (below)
Fireside Chat: Serverless Application Architecture (below)
Keynote: On how your brain is conspiring against you making good software
Jenna Zeigen @zeigenvector.
jenna.is/at-forwardjs.pdf
I particularly enjoyed thinking about how this talk relates to politics ;)
She studied cognitive science. She wrote a thesis on puns.
"Humans are predictably irrational." -- Dan Ariely
"Severe and systematic errors."
Humans aren't great logical thinkers.
People will endorse a bad argument if it leads to something they believe to be true. This is known as the belief bias.
"Debugging is twice as hard as writing a program in the first place" -- Brian Kernighan
We tend to interpret and favor information in a way that confirms our pre-existing beliefs.
We even distrust evidence that goes against our prior beliefs. It's even harder for emotionally charged issues.
We have a tendency to be rigid in how we approach a problem.
We sometimes block problem solutions based on past experiences.
We often have no idea we're going to solve a problem, even thirty seconds before we crack it.
Breaks are more important than you think.
Creativity is just about having all the right ingredients.
Again, we tend to think about problems in fixed ways. That makes it harder to understand other people's code.
We prefer things that we have made or assembled ourselves.
We're bad at making predictions about how much time it will take us to do something.
We tend to be pessimistic when predicting how long it will take other people to do something, and optimistic when predicting how long it will take other people to do something.
We think that bad things are more likely to happen to other people than to us.
We're actually pretty good at filtering out unwanted stimuli, but we're not totally oblivious to it. Selective attention requires both ignoring and paying attention.
We're very limited in our mental processing. For instance, we can't do a good job writing code while doing a good job listening in on someone else's conversation.
We're sometimes helpless to the processing power of our brain.
Software is about people.
Relatively unskilled people think they are better at tasks than they actually are.
We tend to overestimate our own skills and abilities. 90% of people think they're above average at teaching.
Skilled people underestimate their abilities and think tasks that are easy for them are easy for others.
She mentioned Imposter Syndrome and said that the Wikipedia page was pretty good.
We favor members of our own in-group.
We prefer the status quo.
We weigh potential losses caused by switching options to be greater than the potential gains available if we do switch options.
We're liable to uphold the status quo, even when it hurts other people.
People have a tendency to attribute situations to other people's character rather than to external factors.
People have a tendency to believe that attributes of a group member apply to the group as a whole.
We rely on examples that come to mind when evaluating something.
We assume things in a group will resemble the prototype for that group, and vice versa.
In some cases, we ignore probabilities in favor of focusing on details.
Diversity is important for a team. The more diverse the team, the more diverse their background, the more creative they can be.
Real-time Application Panel
I didn't think this talk was very interesting.
There were 3 people on a panel: Guillermo Rauch (he wrote socket.io), Aysegul Yonet (she works at Autodesk), and Daniel Miller (a developer relations guy from RethinkDB).
The RethinkDB guy said that RethinkDB doesn't "have any limitations or make any compromises" which seems quite impossible. Certainly, it can't violate the CAP theorem ;)
From their perspective, Real-time is a lot about getting updates from your database (change feeds) as the changes comes in.
Some databases can give you a change feed.
The XHR object has an upload event so you can track uploads.
Real-time is about minimizing latency.
REST doesn't fit very well with push architectures / WebSockets.
Sometimes you need to be notified that a long running job has completed.
WebSocket tooling can be insufficient.
It's unclear what's going to happen with HTTP/2 vs. WebSockets.
The fact that HTTP/2 provides multiplexing is perhaps an advantage over WebSockets especially when you have wildly different parts of the client app talking to the server.
Server push is an exciting part of HTTP/2.
2 members of the panel were excited about observables and RxJS.
Fetch, the new way of making requests, doesn't have a way of aborting.
The RethinkDB guy gave a shoutout to MobX, but he didn't seem to know much about it.
(By the way, looking around, I see a sea of Macs. One guy said there were only 3 Windows machines in the workshop he was in.)
There was a little bit of talk about REST perhaps not being the best approach for a lot of situations.
Fireside Chat: Serverless Application Architecture
This was another panel, but I thought it was pretty good. Alex Salazar (from Stormpath) and Ben Sigelman (who wrote Dapper, the distributed tracing system, at Google) where the two people on the panel.
Stormpath has adopted this sort of architecture. The company itself provides authentication as a service.
"Serverless architecture" is a serious buzzward. It started 6 months ago. It's trending a lot right now.
Alex says it can refer to two different things:
Using services like Twilio, etc.: He says this is more "backend as a service".
Functions as a service: He says this is more accurate. He mentioned AWS Lambda. The idea is that you can write some business logic specific to you, and you don't have to manage anything that even looks remotely like a server.
When people say "servers", they're kind of referring to VMs. With serverless, you don't even need to think about VMs.
There's a lot of cross-over with microservices.
Although Heroku got pretty far, he says it's beyond and different than what Heroku provides.
Heroku automates server work (i.e. a worker). You're still writing a Python, JVM, or Node application.
Google App Engine, Heroku, etc. were all trying to be platforms as a service. It's still a backend, monolithic application on their architecture.
Serverless in the lambda model is not a server application. It's a set of finite functions that run in a stateless environment. He says it's a superior model depending on your use case.
Stormpath started with a Java monolith. They moved to asynchronous microservices. They spent a lot of time looking at AWS Lambda. They wanted to update and deploy modular pieces of code without versioning the whole system. For instance, they wanted to be able to update just one function.
Ben is terrified of CI (Continuous Integration) and CD (Continuous Delivery). Some PRs (pull requests) may not have considered all the weird interactions that actually happen. He thinks the pendulum might swing back the other way so that there's one deploy per day.
Monolithic apps can be easier since the different parts are all versioned together. It's scarier with microservices because there might be more version mismatches.
Stormpath tried to move to the Lambda model, and it didn't work. Latency is a real problem. Stateless pieces of code take a while to spin up and spin down. Functions that aren't used very often take a while to spin up--especially with the JVM. They went from serverless to even more servers. It resulted in more infrastructure, not less.
NoSQL databases are beneficial, but there's also too much hype. They kind of hid their drawbacks which was bad. Proof of point, see the guy from RethinkDB above :-P
Ben said that Lambda is the absolute extreme of where this movement will go. Consider GRPC, Finagle, Thrift; can we have hosted services for these things with a little caching?
Anytime you have latency issues, you apply caching.
The difference between memcached vs. in-memory caching (i.e. in the current process) is huge. So stateless has a huge drawback since you can't do in-memory caching. If you have to cache anything between requests to minimize latency, Lambda isn't the right thing.
If performance is important for you, Lambda (serverless) isn't ready yet. That's not true of microservices, though.
If you need to create a chain of these functions as a service, then maybe you shouldn't be using serverless. The latency compounds. One time, he was doing 4 chains, and he was seeing multi-second latency.
Serverless is really good for certain applications.
The history of computing is all about more and more abstraction.
From microservices to serverless is a natural transition.
What will the learning curve be like for learning how to use this model?
Stormpath had to invent a lot of stuff to adopt the model because a lot didn't exist. This included testing, messaging, authentication, etc.
However, he likes async, promises, etc. Scala and Node both have this right. However, Ben thinks Scala is "ridiculous". If you're all asynchronous anyway, it's easier to move functions off the server into a separate service.
Promises need to have more things like deadlines, etc. He thinks promises are a good fit.
It's an anti-pattern to wait on anything that's not in process.
A lot of stuff from Scala (async, reactive, etc.) is making its way back into Java.
JavaScript developers are already in the async paradigm, which is why they adapt to this stuff more easily.
The average Java developer hasn't wrapped his head around async yet.
Stormpath is hoping to provide authentication as a service for services, not just authentication for users.
Ben thinks security needs to be applied more at the app layer. Auth, security, provisioning, monitoring, etc. should all start happening at the app layer.
There is indeed business risk depending on a bunch of external services like Lambda, Stormpath, etc. There's no silver bullet. Can you trust the vendor? What's the uptime and SLA? Now, with SAAS, you're not just depending on them for code, but also for ops.
Having an SLA for high percentile latency (99%) is important. Uptime doesn't mean anything. However, historical uptime is still important.
Ben says that the main advantage of the monolithic model is that all deps get pushed out every week along with any updates to the code.
Your team needs processes and automation. Test before things go out. Integration testing is how you keep things from blowing up.
The Web meets the Virtual and Holographic Worlds
This was a very fun talk by Maximiliano Firtman, @firt, author of High Performance Mobile Web! I can't find the video, but if you can find it, it's worth watching. He's written and translated a bunch of books. He's very engaging.
He started by remembering the web from 22 years ago.
He says that the web has been trapped in a 2D rectangle.
New worlds:
Physical world
Virtual reality
Mixed reality (holographic world)
Immersion modes:
Seated mode
Room space mode
You can be a part of all of this, even as a web deveoper!
We're at a point now like where mobile web was 10 years ago.
VRML is from 20 years ago! We're not talking about it anymore. Technology has changed.
Experiences:
Flat web content (this stuff still works on these devices)
3D world (stereo)
360 still or animated content
Distribution:
Apps
Websites
PWAs (pervasive web apps)
Human interfaces:
Gaze (move your head to select things)
Voice
Touch controls
Clickers (remote controls)
Controllers
Your body (mostly hand gestures)
Mouse and keyboard (good for mixed reality)
Hardware:
Oculus Rift (Windows)
HTC Vive
Cardboard (Android, iOS)
Oculus Gear VR (by Samsung; has 1 million users)
LG 360 VR (LG G5)
Hololens (this is the most different; uses Windows 10; not connected to a computer; mixed reality)
New worlds:
Virtual / mixed reality
Physical world
Immersion modes
Human interface
Hardware
User experience:
Safari or Chrome (iOS or Android) with Cardboard:
Use a gyroscope to recognize your position.
Samsung Internet (browser) on Gear VR:
It's a 3D environment, but the web is still a box in that environment. It has different modes for watching videos.
Microsoft Edge on Hololens:
This was a really neat demo! You can use hand gestures. He showed a hologram floating in your room that you can see using the headset. You can walk into the "window". It's like it's floating in space. It recognizes the room around you. You can put a hologram in a certain place. For instance, you can have a window running Netflix that lives in your bathroom.
APIs and specs:
Web VR:
You can get data about the device's current capabilities.
You can poll HMD pose.
you can get room scale data (data about the size of the room).
You can request a VR mode which is like the fullscreen API.
There are two different versions of the API. He recommended version API 1.0 with the changes they've made to it. It's optimized for WebGL content.
You can use this API to get data from the devices. This API is not for drawing to the screen.
It's supported by Chrome, Firefox, and Samsung Internet browser.
There's a polyfill to work on other browsers.
Web Bluetooth:
This allows you to talk to any type of Bluetooth device.
You can scan for BLE devices.
You can scan for services available.
You can connect to the services.
Note, Bluetooth is complex.
This is only in Chrome, and it's hidden under a flag.
Other APIs
The ambient light API lets you get info about the current lighting conditions.
There's a gamepad API. Chrome is the furthest ahead on this API.
There's speech synthesis and recognition. This allows you to interact with the user by voice. Note that synthesis is more broadly supported than recognition.
Web audio lets you generate dynamic audio, including 3D audio. You can do ultrasound communication with devices. He recommends a library called Omnitone for doing spatio audio on the web. This API is available all over the place.
What we can do today:
You can show flat content in these environments:
I.e., you can show the kind of content we already have in these environments.
It's like a 2D box in a 3D environment.
You can show 360 content:
You can get the device's orientation.
You can touch some of these devices, or move around.
There's something called VRView from Google.
The Vizor Editor is pretty useful. You can use it to create a 360 degree environment.
You can capture 3D content using cameras. However, most browsers don't support live streaming 360 content today. You have to use YouTube if you want that.
You can use the Cardboard Camera app from Google. Then use the cardboard-camera-converter.
VR 3D:
This is mostly based on WebGL.
You can use ThreeJS with VR support.
Holographic experiences:
This is only native at this point. You can't do it from the Web yet.
AltSpace VR is like a social network using VR. It's a native app. It has an SDK. You can use ThreeJS.
More will come in the future...
These are things he expects we'll see in the future:
New Devices:
Daydream from Google looks pretty cool.
Think about pixels:
What do they mean now in a VR environment?
How do we think about bitmaps? Can we use responsive images based on distance? See MIP Maps.
There's a new format called FLIF. It has multiple resolutions in the same file.
Future CSS:
We might see media queries based on how close the user is.
New challenges:
Consider infinite viewports.
If I increase the size of a virtual window, what should happen? Should it show more content, or should it show the content larger?
Augmented reality physical web:
Laforge:
Like Google Glass but not from Google.
We need more from Edge and Windows:
Holographic
New challenges:
Responsive VR.
React Native: Learn from my mistakes
This was a talk from Joe Fender. He's from a company named Lullabot. He lives in London. Here are the slides.
"We create digital experiences for the world's best brands."
(React is very popular at the conference.)
(There are a lot of women at the conference. It's not all men.)
Not as many people use React Native.
Being a web person is enough to build mobile apps.
What's the fuss? Developing native mobile apps is a pain. It's difficult to code the same thing twice (Java and Swift), especially if you're not very familiar with those languages.
PhoneGap/Titanium just didn't feel right. Furthermore, there are some memory and performance limitations. You're stuck with a non-native UI. It's a WebView embeded in a mobile app. Furthermore, it's a bit weak on community support.
React Native is really simple. It allows you to make truly native apps. React itself is nice. He thought coding in JavaScript was nice. His team was more successful than when they were trying to write the app in Java and Swift.
10 things he wish he knew. These things weren't obvious to him when he started:
You need to know some things ahead of time such as JS, ES6, React (including the component lifecycle), and the differences between various devices (i.e. their differing UIs and features).
You need to learn about the various React Native components. React Native has a whole bunch of components--about 40. You can get a lot done with just the core components. However, there are also contributed packages--about 200 of them. Sometimes you'll need to write your own components.
You need to think a lot about navigation. It's a really important part of the app. How will users get between screens? How will they get back? How will the transitions look? NavigatorIOS is good, but it's only for iOS. Navigator is cross-platform. NavigatorExperimental is very bleeding edge.
You need to think about how data flows through your app. Consider how your app will scale. Consider using Flux or something similar. He used Redux and liked it.
Think about how you will structure your code if you need to support both iOS and Android. Will you use a single code base? Will there be platform specific code? Will you write expressions like { iOS ? 'nice : 'ok' } to match the different platform conventions? Some people have very high expectations and expect your app to look very native. You can get started with npm install -g react-native-cli react-native init MyApp. You can have index.android.js and index.ios.js just require index.js. Note, many components work on both platforms, and usually the component will take care of platform-specific things.
Flexbox is a really great way to lay out components on the screen. It's responsive. That's really important in mobile. It's pretty much the way to go with React Native. There's a bit of a learning curve, though. It's just a different way of thinking about things.
You still need to test on real devices. Simulators are insufficient. It took them a while to realize this:
The performance is very different. Consider animations and load times. Your laptop is too fast.
The networking is very different. With a mobile device, you're not always on a nice WiFi connection. What about if you're disconnected or have a 3G connection. WebSockets behave differently when you have a spotty network.
Push notifications are a pain. You can't test this on the iOS simulator. For Android you can.
Real devices don't have separate keyboards. This caused a big problem for them. Using an on screen keyboard takes up half the screen, and some of their layouts were incompatible with that.
Think about landscape mode. Think about different layouts.
Debugging is important. The developer menu in React Native is very helpful. In general, React Native has a really nice developer experience. On iOS, shake the device. There's a Debug JS Remotely feature so that you can debug via Chrome's DevTools. This supports live reload, and it only takes 100ms to reload new code. console.log() works too. You can pause on caught exceptions and add debugger; to your code like normal. Unfortunately, the React Dev Tools Chrome extension doesn't work with React Native.
Be aware of the React Native release cycle. It's every 2 weeks. Sometimes, it's weekly. It's very fast, and very bleeding edge. His company is 10 versions behind. In general, the release notes are quite good. He recommends that you don't try too hard to stay on the most recent version.
Remember that you'll need to release your app since it's a mobile app. Submitting your app to the app store is not easy. You need certificates, icon sets, a privacy policy, a support page, etc. It took them 2 weeks. Furthermore, it takes Apple a while to approve it. You also need to think about things like automated testing. React Native has a bunch of useful stuff to help. You can also use ESLint, which is nice.
React Native has Android, but it came a bit late.
His company didn't have any problems with missing APIs.
They used Parse which is an external DB as a service. Unfortunately, Parse is going away.
He thinks Firebase has good React Native support.
If you want to have really native-looking components, it's going to be hard to just use one codebase with flexbox.
Dealing with WebSockets was a pain.
Push notifications are pretty different between platforms.
Building Widget Platform with Isomorphic React and Webpack
Unfortunately, I didn't think this talk was very good or very useful for most people.
It was given by a guy named Roy Yu.
He was considering SEO value and discussing his architectural decisions.
He was creating isomorphic widgets that were shared by PHP, Java, and Python.
React isn't so simple once you hit the advanced stuff (e.g. high order components vs. dumb components).
I knew the keywords he was using, but I didn't understand what he was trying to convey to me.
He says that Webpack is more powerful than Grunt and Gulp.
He introduced React and Webpack a little.
You can package and deliver widgets to third parties using a range of mechanisms:
S3, CDN
Web component / open component
Public / private registry
Docker container as a resource / API proxy
You can have an API that other servers hit to fetch HTML.
I left early.
Generating GIF Art with JavaScript
This was a fun talk by Jordan Gray, @staRpauSe.
Here are the slides. They contain lots of fun GIF art.
He pronounced GIF with a hard g.
He works at Organic and Codame (in his spare time). Codame unites art and tech.
"Creativity is the basis for life."
He releases everything he does under Creative Commons. He likes the remix culture.
His stuff has showed up in major magazines, films, etc.
GIFs have stood the test of time. The format is 30 years old. It's completely free of patents.
They're inherently social.
Creativity loves constraints, and GIFs have interesting constraints. They only permit so many colors, frames, and dimensions.
Constraint considerations:
Tumblr is the holy grail to target. There's no censorship.
2 MB 540px wide (or less) is a good target.
He talked about VJing (like DJing, but with artwork). He talked about GIF Slap. You must target 5 MB or less.
He talked about PixiVisor. It supports any height as long as it's 0.5625 times the width (i.e. 64x36). You can embed the GIF in audio.
You can target CAT Clutch which is for LED displays. They are 32x16 pixels in size.
You can use GIFPop Prints to print the GIF on a "lenticular" piece of paper. This is really neat. You're limited to 10 frames but you can have up to 1500px. This was really neat.
How to make GIFs:
Use gif.js.
In general, it's really easy.
Define a GIF. Add frames. Render it.
You can use three.js to do 3D manipulation, etc.
The best resource he offered is bit.ly/eric3demos.
He also talked about processingjs.org.
Anything else that renders to canvas is usable as well. See javascripting.com/animation.
github.com/dataarts/dat.gui is incredibly helpful. It's "A lightweight graphical user interface for changing variables in JavaScript."
He mentioned jzz.js. It's an Asynchronous MIDI library. It lets you control a web page with an actual MIDI device.
github.com/CODAME/modbod3d-gifgen is a good example. They used a Kinect and a body-sized turntable to help create the GIFs.
gif.js generates the gif, and then you can download it from the web page.
(He's using Sublime Text.)
His next demo was or involved Technopticon.
Next, he talked about the theory of animation. "The Illusion of Life" is really good. Some Disney animators wrote a book about this stuff. There are some YouTube videos about it which looked really good. he talked about "the12principles".
He talked about keyframes vs. straight ahead. It's mostly about straight ahead when generating gifs.
he talked about greensock.
See: vimeo.com/80018593.
He mentioned Movecraft.
React Application Panel
There were 5 people on the panel.
There are some people at Twitter using React.
The main reason people are initially turned off by React is JSX. However, at Facebook, they were using something like JSX for PHP, so it was a natural fit for them.
Reddit started using React.
Here's how one team split up their code:
Dumb components
Containers
Modules
Screens (route handlers with React Router)
An API layer
Try to reuse data layers and view layers.
Lots and lots of people use Redux.
"It's the web. We'll probably rewrite it in 3 weeks...in Angular 3."
The Twitter guy does some work to try to keep the connection between React and Redux as thin (small) as possible. He doesn't want them overly coupled.
One person was from Adroll.
One person was from Reddit.
Lots of people started adding React to their existing Backbone apps.
One person said try to use stateless components when possible. Push state as high up the hierarchy as possible.
The Facebook guy didn't like the class syntax. The function syntax makes it clearer that you're just mapping props to render output.
The Facebook guy says that people are a little too scared to use component state, but it's there for a reason.
Time traveling debugging is "sick AF (as f*ck)".
One guy mentioned MobX, but I didn't hear many people mention it at the conference.
One person said to introduce Redux only when it's time to add complex state management. One person said you're going to need it at some point, so you might as well add it to begin with.
The Facebook guy said to start with the simplest thing (component state), and then when you're familiar with the pain points that Redux addresses, you can start using Redux. You probably don't need Redux on day one.
The Reddit guy said he would add Redux later. Introduce data stores once it becomes a necessity, such as when multiple apps need to access the same data.
The Twitter guy said that it's helpful to keep things separate to make them more testable and adaptable to change.
A lot of people had different ideas of how to do HTTP async with React.
2 people really liked Axios.
Promises are great, but they can't be cancelled, for instance if you move to a different page. They might add that. It's a significant weakness.
The Facebook guy said they use promises on the outside, but something more complicated inside. He gave a plug for await. It has reached stage 4, which means it'll make it to all browsers soon.
One guy plugged RxJS. You can unsubscribe from an observable. Observables are more advanced than promises, and they provide more granular control.
Some one asked what people's favorite side effect library was for Redux. Most people didn't have an opinion. The Twitter guy uses Redux Thunk.
They've been rewriting Twitter from scratch in the last year. A lot of abstractions that were there got in the way. Too many layers of abstraction sucks.
Something like Saga (?) is overkill.
Make the code more approachable.
No abstraction is better than the wrong abstraction. It's ok to duplicate a little code if you don't know the right way to abstract the code to make it DRY. It sucks to have some abstraction that handles 3 use cases, but not the 4th. Too DRY sometimes makes things horrible. Sometimes you need more flexibility. One guy used the acronym WET (write everything twice) and suggested that it was a good approach to avoiding bad abstractions.
Create React App is nice. It helps people get started quicker. One person said that it's awesome.
React is not very prescriptive about which build system or packager you use, although, those things are useful. Most people should be using Webpack or something like that.
One person is using CSS modules. She said "it's fine," but admitted that she hates it.
There are so many ways to attack the CSS problem.
The Twitter guys are using Webpack.
React is quite a hackable platform. That's really useful. The Twitter guy uses CSS modules. "It's been ok." Some things are really not fun to debug. It's a black box. CSS really limits your ability to share components across projects in open source because different people use different CSS libraries.
"CSS is like riding a bike...but the bike is on fire...and you're in hell."
It's hard to know what CSS is being applied. If you're looking at CSS, it's hard to know if the CSS is even being used. If you apply CSS in the wrong order, it changes what things look like.
Some people think that styles in JavaScript seems interesting.
The CSS thing isn't really solved.
The Netflix guy says, "Write CSS that can be thrown away." They use LESS. They do some static analysis.
Aphrodite is a CSS library.
The Twitter guy is more excited by the idea of moving CSS into JavaScript since it enables a bunch of new things. Move away from strings to something introspectable. It'll be more powerful and predictable, but it may have performance issues.
One person has a team with a woman who does amazing UX design and amazing CSS.
One woman at Netflix said that they have one CSS file per component. Just separating files is not enough. Putting CSS into the code modules is an interesting movement. The React guy is afraid of it causing performance regressions.
Just like we've moved onclick handlers back into React, we'll probably move the styles back into the DOM code.
Code Trade-offs: Benefits and Drawbacks of Each Decision
This was another 5 person panel. It was ok, but not great. I didn't get all the names, but here are the ones I remember:
Ben Lesh from Netflix. I think he wrote RxJS 5.
Richard Feldman who wrote Seemless Immutable. He's an Elm guy.
Amy Lee from Salesforce.
Rachel Myers from Obsolutely, GitHub, etc.
Brian Lonsdorf
Abstractions come at the cost of performance.
RxJS is really an abstraction for async. But, he says, start off with just a callback. Maybe move to a promise. Move to Rx when things get more complex.
John Carmack had some nice comments on when to inline vs. abstract. Performance is a consideration. Readability is a consideration. One guy said inline by default, but then pull it out when it makes sense.
One React user said YAGNI (you ain't gonna need it).
You can add the greatest abstraction ever, but if it's not readable, understandable, and greppable, it's not going to help. Abstractions can get out of control pretty quickly.
The Ruby world has no constraints. They look at constraints as if they're a horrible thing. There are 8 ways to add things to an array. In Python, there's one way. The speaker said that that's much nicer.
In Elm everything is immutable, and everything's constants. NoRedInc uses Elm. They have 35k lines of code. They don't ever get runtime exceptions. Elm makes refactoring very easy. Elm is one of the panelist's favorite programming languages.
RxJS started using TypeScript. Dealing with users using it from JavaScript is kind of painful.
With MVC, you think you can replace each of the pieces separately, but in practice, this doesn't really happen. All three pieces are very wed to each other. It's the "myth of modularity."
Simple Made Easy is a great talk.
Drawing the lines of modularity in the wrong places causes a lot of pain. Doing modularity just right is really hard.
Concise naming patterns are really important when you're doing modularity.
Generic code and interfaces are "dangerous". "No abstraction is better than the wrong abstraction."
Imagine you have 3 things, and you notice a common interface among them. Now suppose you create an interface, but then you suddenly get a 4th thing that doesn't match the interface. Now, you're in bad shape.
When you create a public API, you have to have an interface, but creating an interface for your own code when you don't necessarily need one might cause more problems later.
When speaking of adaptation in JavaScript, someone said "It's not a duck, so you punch it until it's a duck."
If you can come up with a good interface that can fit a lot of things, like Observable, it's really useful. It gives wildly different things some sameness.
Then, you can write code that people can understand.
Lisp has a very pleasant interface: a paren, a command, some stuff, a paren.
Rx is arguably a DSL.
The key is finding an interface that's really simple that can solve a wide variety of needs. It's tough. You sacrifice some specificity.
On the subject of principles:
Someone said, "I used to have principles. I no longer do." For instance, I used to always have unit tests. Then, she started a company, and figured integration tests were good enough.
One guy wrote a lib with a little DI. He achieved 100% code coverage. Then, he ended up breaking it anyway. Unit tests are not enough. He is a little integration test heavy. Integration test first, unit test second. He was told the opposite, but changed his mind.
Another person said: unit tests have a lot of value, but you also need integration tests. You also need to test with real users.
One guy's principle was: put UX first. The end user is more important than clean code.
Principle: If I feel 100% sure I'm right, that worries me. Question your own decisions.
Principle: never write the same thing twice unless there's some really good reason. (Presumably, they've written "if" more than once :-P)