Community of developers coming together every month. Talks are not limited to React and may include related subjects like Elm, Redux, GraphQL, Reason etc.
Я сам русский, но боже... как же тупорыло звучит английский в наших устах! 😆 (я про лектора тоже) Такой ужасный, деревянный акцент, что мне тоже слушать неприятно. Берегите англичан, учитесь правильному акценту! 🤣
Фигня. Как правило, разрешение конфликтов (у программного кода) происходит не из-за редактирования ОДНОГО файла (наоборот, разные люди редактируют разные части проекта), а потому, что ОБЩИЙ продукт может даже не скомпиляться, если кто-то сделал изменения, а ты (сделав свои изменения) не забрал чужие изменения к себе и не проверил работу. Поэтому золотое правло работы: сделал изменения, отладил, ЗАБРАЛ ЧУЖИЕ, снова проверил работу, и только потом закоммитил/замержил.
The amount of cursing, yelling and joking it's really annoying and inappropriate. Kind of disappointing that one of the very few Preact-related talks is filled with this kind of garbage.
Hi Ali, great video! I just launched the book "Professional Front-end Architecture" which presents a new perspective on the topic. frontend-architecture.com/buy-book/
Thanks for recording - to follow along find the talk notes online @ github.com/geraldb/talks/blob/master/gatsby2.md Cheers. Prost. Greetings from Vienna.
don't tell me this is a bunch of JS programmers that have absolutely no idea about garbage collection. Isn't the prejudice against JS-Programmers that they have no idea how to program and don't care how anything works in the back? I guess after this video I understand why. I'm primarily a JVM dev and I can tell you that this is just the basics of JS Garbage Collection. I can also tell you that there are mistakes in your talk. 4:02 "a typical frame takes up about 60 seconds". A typical frameRATE is 60 frames per second, thus a typical frame takes 1/60th of a second so about 16.66.. ms. 11:45 "so V8 uses a generational garbage collector [...] different than java, ..." Java is using a generational Garbage collector as well, actually the V8 garbage collection is very close to the Java garbage collection (you can read about java here: www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html#t2) 12:20 "so then the older generations [...] those get left alone." Again no, the very old generation gets left alone. the old generation is cleared with standard mark, sweep, compact and this is the part of garbage collection that takes by far the longest. 12:55 "the interesting part about that is that the older object don't usually intermingle with the younger objects [...] they won't have a reference to the younger object" That is unless you give the old object a reference to a younger object what happens quite often in JS. quite often might mean only a few percent, but the point she didn't make is that the young generation is spammed with a lot of objects and most of those die very young. But the case of old object references young object is a very important topic or your garbage collection system would simply not work. She didn't talk about the garbage collection system which is Scavenge for the young generation and Mark-Sweep-Compact for the older generation. It is very similar to Java, but with some small differences. Also you keep talking about pointers. What you mean are references. Pointers are basically address values that you can manipulate, references directly reference the object.
This is exactly the right approach to scaling front-end teams. I would be very interested in seeing this at a large scale (like your Spotify example), the direction of having independent apps inside an app-shell but still enforcing types with Flow across the application should make for a very flexible, scalable, and robust front-end application. More importantly, it facilitates scaling on human level into teams that have the autonomy to choose the best tool for the job, as you pointed out. This is definitely the way forward. Thanks for this presentation!
Loved your talk.. Have seen the create-react-app but din notice it. It would be really handy in my future projects. Thanks once again for such an insight
1:34 I get it, its a lot of tools, but the overwhelming part to me is how fast things change. and the poor guys who create medium blog posts or guides, their work goes out of date fast.i think i spent a day or two setting up typescript and im still not done.
I'd be grateful for a bit of detail on ":tree" versus "::tree" in the recursive spec. It wasn't immediately clear to me why you have two different keywords, whether you must have two different keywords (to stop the recursion?), and how :tree is related to ::tree (one of the two is implicitly name-spaced iirc).
I think the first keyword has to do with the representation of the spec (e.g. when you call s/conform and get a map as a result), and the 2-colon keyword (namespaced) is the actual spec. So, instead of :tree you can write :foo and the spec still works, but there is a difference in the map output. (not completely sure, of course)
Elm (almost always) doesn't swallow errors, it actually requires you to handle them. You could just ignore them but you would have to do so knowingly. For instance, if you're getting the first element of the list it won't just give you the item or Null it will give you a `Maybe value` which requires you to write conditional logic around the "nothing there case" and the "something there" case to get the value out. Not doing so would not compile.
also when " (s/conform ::person {::first-name "David" ::last-name "Nolen" :age 37})" failed you should have immediately done "(s/explain ::person {::first-name "David" ::last-name "Nolen" :age 37})" to show the power of spec. Because if that had been a deeply nested structure that you couldn't just eye-ball and say "oh yea I forgot to use the namespace qualified version of the age keyword," explain would have shown you exactly where the issue was. When I reran that example at the repl it said "fails spec: vienna-js.core/person predicate: (contains? % :vienna-js.core/age)"
not sure how I feel about versioning a spec. if you have a spec that is called ::firstname that is a string and you want it to change it to instead be the hex value of the first name, would you make ::firstname-v2 or just call it ::hexed-firstname ? in both cases you're giving it a new name because spec doesn't allow versioning in the sense that you have the same name and then your build tool gives you the right version of the thing at compile time, but still, when David said "versioned specs" I shivered a little bit
Video describing your reactjs boilerplate would be awesome. I am having very hard to understand the routing and reducer relation in your awesome boilerplate.
All you need to be a "PWA" is a manifest.json and a service worker. There's not many differences from a plain website, you could easily do that with Elm. If you need some special features you can do with JS and ports.
