That feeling when the video is zoomed in on the speaker and multiple slides go by that you CANT SEE.... arghhhh!!! Why oh why don't the people that film these talks learn not to do that?!?!?
Tips in talk : * Organize bigger functions into smaller functions. * Helper functions. * Narrow your types in functions. Scaling Model: * Write functions taking extensible records. Views: * Have reusable components : Html.map and Cmd.map * Use simplest api possible.
Great talk! side note: please just leave the view where I can see the slides. You can change which camera angle is present on the side, but missing information in the slides when he is referencing it is really frustrating.
Great talk. It's definitely helpful if you want to force your elm app to scale ;-) 53:50 That's not right. You can end up with the same kind of bugs in Elm if your model had "dropdownOpen" as a flag for each component. And on the other side, it would be theoretically impossible to get the error in React/Redux as well if you also had one single flag in the model instead of having it in the local-state. So it's actually the same. Feel free to correct me in case I got it wrong.
I've been trying to tidy up an existing, large Vue codebase by adding Typescript, ESLint rules, prettier, and written programming guidelines; yet no matter how many rules I add, our programmers are to come up with the most insane patterns that makes the app hopelessly difficult to maintain. I am curious if an Elm app would scale better with a large team.
I thought the "fractal" architecture was the way to go for scaling Elm apps. This is the first time I see it described as OOP-inspired. Will have to ruminate on that...
It looks great. But I didn't got how can you write type signature for clearUser user = clearContact user >> clearAddress user ? In Haskell rio style there is a way to intersect type-classes. But how do you intersect extensible records in Elm?
Disclaimer: I do not use Elm, so there might be some technical details that I overlook. When every "component" in a large application would have different API - it would actually make thing more complex, it seems. If every component would have a model, and an updated, and a view - it makes things simpler. Not necessarily the by reducing the number of lines of code, but in terms of overall complexity. Exactly like it is described in the beginning of the talk, when it goes about how we should split complex model, by adding lines of code, but making things easier to understand. And the problem with narrower types seems to be solvable, by using model and msg types special to the component. Another thing that I noticed is that with extensible records - that is duck typing. With increasing scale it would make name collisions more and more likely. Especially, if we are talking about reusable components. So, it looks like a bad design decision.
As someone who uses Elm a lot (work and fun) his talk is spot on and often the approach to designing an app in Elm is very different then designing an app in another language/framework. Its hard to describe it really. I've done the everything has a Model, View, and Update and it just became a big PITA.
@@jgt_ I assume you disagree with something I wrote? If you could point it out we might have a conversation. I assume our experiences are distinct, if you assume I have none. Though, if you think that everything I said is just stupid, then a constructive conversation is unlikely.
Its a toy language that leads to better code quality with little thought (especially when working in teams). Still a toy language (for now) - but it has its perks.
How else are you going to convince javascript developers who are happy with writing bad code to change their processes? Evan has studied the niche that Elm aims to fit in very well - and dumbing down documentation into easier to swallow parts for the sake of wider adoption is the best way to change how people develop for the web overall.
