![React Finland](/img/default-banner.jpg)
- 172
- 171 732
React Finland
Finland
Приєднався 19 лют 2018
React Finland (24-26.4.2018, Helsinki) conference videos.
React Finland meets Aalto University - Panel about web development
In this panel, m4dz, Jen Luker, Ryan Carniato, and Juho Vepsäläinen (the host) discuss questions provided by Aalto University students.
00:00:00 Introduction
00:02:32 What web development framework do you really like and why?
00:05:30 If you don't have a developer background, what's a good amount to learn about development?
00:14:18 What skills should every web developer have?
00:20:07 How to choose between web development frameworks?
00:27:13 When most of you recommended React, do you have of conflict of interest there?
00:33:08 How do I land my first internship in an interesting company?
00:43:33 What was your background and skill level before landing the first position?
00:57:20 What are the skills of a senior programmer?
01:03:02 Can you have a successful career without dedicating free time to programming?
01:09:20 What have you learned from business people?
01:17:09 How to transform business requirements into a design or code?
01:20:06 Should I use TypeScript or something else?
01:26:14 Who is the best programmer you have ever met or worked with and what made them the best?
00:00:00 Introduction
00:02:32 What web development framework do you really like and why?
00:05:30 If you don't have a developer background, what's a good amount to learn about development?
00:14:18 What skills should every web developer have?
00:20:07 How to choose between web development frameworks?
00:27:13 When most of you recommended React, do you have of conflict of interest there?
00:33:08 How do I land my first internship in an interesting company?
00:43:33 What was your background and skill level before landing the first position?
00:57:20 What are the skills of a senior programmer?
01:03:02 Can you have a successful career without dedicating free time to programming?
01:09:20 What have you learned from business people?
01:17:09 How to transform business requirements into a design or code?
01:20:06 Should I use TypeScript or something else?
01:26:14 Who is the best programmer you have ever met or worked with and what made them the best?
Переглядів: 182
Відео
Closing Remarks & Thank You
Переглядів 35Рік тому
React Finland 2022 took place 12-16.09 at Paasitorni, Helsinki. We had 400 participants and lots of fun. Gold Sponsors: Relex Silver Sponsors: Elisa, Nitor, Gofore, Supermetrics Bronze Sponsors: Moon Highway, Solita, Huuva, Knowit, Utopia Music, Alma Media
Roosa Kallionpää - Accessible navigation in single-page applications
Переглядів 287Рік тому
Single Page Applications (SPAs) are lacking in accessibility by default. While a sighted user is able to tell the difference between different types of page updates, screen reader users might not separate the ones that resemble page loads from those that affect a single component. In my speech, I’ll introduce some techniques to tackle this problem. Drawing: api.react-finland.fi/media/drawings/2...
Eeva Jonna 'Eevis' Panula - Let’s Keep Our Promises - ARIA, Styles and Keyboard Navigation
Переглядів 131Рік тому
Many websites and applications give false promises to users. For example, they promise interaction when there is none. In this talk, I will discuss some of those promises and how to create websites and applications that fulfill the promises given to users. After listening to this talk, you'll walk away knowing more about ARIA and keyboard navigation. You'll also learn how to create more inclusi...
Marianna Österlund - Better accessibility with a user-centric view
Переглядів 141Рік тому
Web accessibility is much more than regulations and restrictions. It is based on real people with real problems and needs. By understanding all the users everything makes a lot more sense. In her talk Marianna addresses the ‘why’ of accessibility - and a little bit of the ‘how’, too. Drawing: api.react-finland.fi/media/drawings/2022/marianna.png Slides: drive.google.com/file/d/1B7j4Vz01edApcbyi...
Varya Stepanova - The complete design system: what and how we could learn from the others
Переглядів 238Рік тому
Benchmarking is one of the recommended practices when you are looking for what could be the next steps for your design system. But there are so many design systems, and they are very much different - it is confusing what should be the standard to benchmark with. Varya has studied dozens of design systems and committed reversive analysis on their features and attributes. This talk sheds light on...
Rami Ertimo - Breaking changes in Design system
Переглядів 235Рік тому
Breaking changes are usually inevitable in any library or system that lives long enough. So what are breaking changes in design system? What is the impact of them in different areas of the system? Is there a way to cheat the system and limit or even prevent this kind of change from happening? But when the inevitable happens, and you need to create a breaking change, what are the things you need...
Norbert de Langen - Testing design systems using storybook + Storybook 7.0 sneak peeks
Переглядів 517Рік тому
Design systems are code, and code should be tested. How do you leverage Storybook stories for tests. I'll also show you some of the new features coming to Storybook 7.0! Drawing: api.react-finland.fi/media/drawings/2022/norbert.png Slides: drive.google.com/file/d/1Ry5NYtWn3-MgKvsK0IQ70aOVkr2AhqAI/view?usp=sharing React Finland 2022 took place 12-16.09 at Paasitorni, Helsinki. We had 400 partici...
Web Components Q&A
Переглядів 54Рік тому
React Finland 2022 took place 12-16.09 at Paasitorni, Helsinki. We had 400 participants and lots of fun. Gold Sponsors: Relex Silver Sponsors: Elisa, Nitor, Gofore, Supermetrics Bronze Sponsors: Moon Highway, Solita, Huuva, Knowit, Utopia Music, Alma Media
Thomas Allmer - Faster content websites via SSR and progressive hydration of Web Components
Переглядів 946Рік тому
One of the best performance tips is "do less" - transmit less data and do less processing. There are a million details but we will focus on transmitting less JavaScript. We are going to tackle it by doing more work at build time which means we start with almost zero JavaScript and only load more as the users interacts with the page. Drawing: api.react-finland.fi/media/drawings/2022/thomas.png S...
m4dz - SDKs vs Web Components: Place Your Bets
Переглядів 107Рік тому
You're offering a fantastic brand new service, and it'll revolutionize your customers' world! Because it's smart, it delivers an API-first solution wrapped in an edge architecture. And because you're smart, you're offering to your end-users several SDKs to let them use those APIs at their full potential: PHP, Java, Ruby, Go, Python, JavaScript… Wait, JavaScript? When entering the world of front...
Matias Huhta - Avoiding vendor lock-in through Web Components
Переглядів 355Рік тому
In this talk we'll discuss the current status of Web Component support in browsers and how developers can avoid locking themselves into certain key technologies by utilizing the Web platform itself. We'll go through what the web can actually accomplish on it's own at the moment, and some useful tools to assist in developing more vendorless, portable experiences. Drawing: api.react-finland.fi/me...
Working in Finland Q&A
Переглядів 46Рік тому
React Finland 2022 took place 12-16.09 at Paasitorni, Helsinki. We had 400 participants and lots of fun. Gold Sponsors: Relex Silver Sponsors: Elisa, Nitor, Gofore, Supermetrics Bronze Sponsors: Moon Highway, Solita, Huuva, Knowit, Utopia Music, Alma Media
Tanja Malo - The most common headaches in relocations
Переглядів 28Рік тому
* Available services, free and commercial * Newcomer sessions to Finland for families * Find out about living in Helsinki region * How to cope with relocation in the first two weeks? Drawing: api.react-finland.fi/media/drawings/2022/tanja.png Slides: drive.google.com/file/d/1NiDu8YYXFxt2YBiw9TLLDDIRMXm4Lytw/view?usp=sharing React Finland 2022 took place 12-16.09 at Paasitorni, Helsinki. We had ...
Vismit Chawla - What do companies look for in a developer - the recruiter point of view
Переглядів 139Рік тому
* Differences in CVs and interviews in different countries * How the skills and competences are assessed in interviews Drawing: api.react-finland.fi/media/drawings/2022/vismit.png Slides: drive.google.com/file/d/1cfBHesZ22dpXjuJY5DQTkX32Dxk3zs6W/view?usp=sharing React Finland 2022 took place 12-16.09 at Paasitorni, Helsinki. We had 400 participants and lots of fun. Gold Sponsors: Relex Silver S...
Saku Tihveräinen - The (sometimes harsh) reality of landing a relevant role in Finland
Переглядів 55Рік тому
Saku Tihveräinen - The (sometimes harsh) reality of landing a relevant role in Finland
Farzad Yousefzadeh - State machines meet component libraries
Переглядів 218Рік тому
Farzad Yousefzadeh - State machines meet component libraries
David Khourshid - The two types of state management
Переглядів 3,3 тис.Рік тому
David Khourshid - The two types of state management
Nik Graf - The weird things about React
Переглядів 272Рік тому
Nik Graf - The weird things about React
Kenneth Sutherland - Notes to my younger self
Переглядів 36Рік тому
Kenneth Sutherland - Notes to my younger self
Esa-Matti Suuronen - Zorm - Type-safe forms for React using Zod
Переглядів 326Рік тому
Esa-Matti Suuronen - Zorm - Type-safe forms for React using Zod
Ryan Carniato - The World Beyond Components
Переглядів 14 тис.Рік тому
Ryan Carniato - The World Beyond Components
Nicola Corti - Bringing the New React Native Architecture to the OSS community
Переглядів 362Рік тому
Nicola Corti - Bringing the New React Native Architecture to the OSS community
Jen Luker - What do engineers, kintsugi and stained glass, and lotuses and clocks have in common?
Переглядів 133Рік тому
Jen Luker - What do engineers, kintsugi and stained glass, and lotuses and clocks have in common?
RF21 - Saku Tihveräinen - The future of software development in Finland
Переглядів 4242 роки тому
RF21 - Saku Tihveräinen - The future of software development in Finland
he/him is crazy
Прекрасно, Варя!
Great intro to statecharts
Solid js is the first real framework I've used since jQuery and it's great. Seems like the obvious choice.
This is the best JS presentation I've seen for a long time. SoldJs is definitly the best thing JS world has seen for a long long time.
9:20 Please, the first line of every explanation on Reactivity should be how it differs from the Observer Pattern.
I think Facebook had an extremely unique set of problems that most people don’t have. You can’t be so simple minded to think that one framework can rule it all.
Timestamps - 12:39 Slide with `createSignal` and `createEffect` implementations. An opportunity to understand how reactivity on SolidJS works. - 16:19 Reactivity with vanilla javascript show up. - 16:33 Apply JSX syntax - If there is a function in JSX component, then SolidJS compiler wraps that component into `createEffect` - 18:02 Make it a component: Counter. - 20:22 Ryan shows that Counter function called only once! And update happens due to effect that updates only `h1` tag text. Counter is not actually a component, it is actually a function. - 20:54 Another evidence of Count is just a function and called just once: using `setInterval` inside and call `setCounter` in timer. - 21:49 Two Counters on same page. - 22:21 What about global state? You can do it, it is just your functions and closures, you can architect as you want. - 22:53 Props drilling example. - 23:45 There is a little bit more than you showed me before. If compiler see function call or an expression - it wraps it into effect. Laziness. - 24:30 Map to DOM nodes. Controlling the flow. - 27:13 - components run once - no hook rules - no stale closures - templates compiles into real DOM nodes - most importantly state is independent from components - 28:56 Component need their Javascript even after server rendering. This is known as Hydration. If we can get rid of runtime components, we can also eliminate hydration.
Setting the record straight - single page apps built on reusable components was a flash novelty, not a react novelty. Flash did this in the late 90's / early 00's expertly.
React started out as a great idea, but with hooks and functional components it just seems that every project I join (or write) ends up an incoherent soup. I never know when components update without reading and understanding every hook. My components are littered with memo, useCallbacks and refs. I'm mainly a React Native dev so it's important to not leak event handlers or have native code run callbacks that don't exist anymore.
Damn man 💯
Ryan throwing shade at React in React event :) . love this.
I love these control flow components! This is one of the things which I like more in angular than react ( even though these here in solid are much more powerful!). Now that this is fixed, and with all these other benefits (I have tried for years to make my angular apps fully reactive!), I can gladly retire Angular. RIP 😄
I think that one really important aspect of it is how this can be ported back to react and preact, as signals did. Preact's approach is the bets of both worlds where it keeps the vdom but encourages using signals instead of hooks, so that the vdom render typically only happens once, but it also avoids needing the <for/> component since that part can still be handled by a real VDOM (if you are memoizing DOM nodes, you have a VDOM regardless of whether or not you admit it).
👍
Facebook programmers made vdom a thing and then tried to make things work around it and big companies adopted it and we're asked to know how it works to use it correctly, what a hell of a world 😆 good job Ryan.
The first half of the video could be named: Why you should consider solidjs :)
Amazing .., talk!!
"Direct" and "indirect" is also called "imperative" and "reactive". Also MVC and unidirectional.
As a person developing in react for the last 5+ years, I have to say it seems solidjs does have superior features/capabilities to react from this demonstration
Dude, @ryancarniato love the talk, and LOVE the Sliders reference
Wow, I didn't expect it to be this good😍 Having the opportunity to work with Ryan on solidjs would be great
I have a library that does this without a compiler :) and can be built by pure esbuild (no plugins, just pure esbuild compile speed). I named my loop component Loop and not For :D. Instead signals uses proxy to watch state changes.
Solid presentation Ryan. And very humble of you not to give the performance numbers of SolidJs vs React. You said that performance can always be optimised but I think that React dug itself into a hole and that only a breaking change can take it out of. Looking forward to see you explore the design space of resumability! In my opinion JavaScript has become too complicated, and we may benefit from a new high level language designed with DSLs in mind (a Lisp??) so that we do not need the huge compilation toolchains of today.
I absolutely love this ryan! What a great talk 😄!!!!
Unfortunetely, I feel like there are not many people who will understand how wonderful is this library. I remember the day when I first put my hands on React, after 10 years of experience in js I was writing a junk code that was in a recursive never ending loop and I couldn't understand why at that time. Then I realize that component functions in react always runs over and over again on props change....That never make any sense for me. Another weird thing on react is relying on props change. Javascript is a language that you can't rely on object comparison without compromising performance...In the world of javascript vanilla and browser everything works really well with events... If that event happens, then I know that I need to refresh or update something. To make any update looking for some change inside a object structure is just a bad idea. Maybe some day we're gonna wake up from this stupid fantasy... But it's alright for hybrid mobile app development... only because there's nothing better yet.
React's rule is that UI is a function over state (UI = F(S)) which is why it makes sense it would re-render when state (e.g. props) changes. This is how functions in JS works, too. Hooks may seem counter-intuitive until you releasize that they are effectively just event listeners that can be synchronized with state, only calling them when its state dependencies change. Solid's components are a bit harder to reason about, because it's not immediately clear that there are boundaries between initializing code and the reactive UI. For example, in the default SolidJS playground, adding a conditional render (e.g. if (count() > 5) ? <div></div> : <div>{count()}</div>) will not work as expected because the first condition is only called _once_. Looking at the compiled output, you can see why this is the case. This is because just calling the signal's getter is not enough to track its changes. This makes it hard to debug and unclear for the average JS developer that is not familiar with Solid's inner workings. Btw, this is not to dig on Solid. I love Solid, and I think it has really good concepts that React could learn from (especially the primitives it brings and its signals). I was just explaining why React is more true to JS than Solid.
@@dealloc Yeah, you're right in that case. Perhaps a way out of that is to return a function in the end of the component function, that takes props as arguments, so that part could rerender many times... idk. I do understand the UI = F(state) Idea, but I believe that makes sense only for UI. It's not so different than we used to do, using handlebars, mustache or template strings. React works different internally but the abstraction is the same for the end user. It's about sending a js object and getting an updated view. The issue I see in the React code design is that components does not have only UI as a concern, they are in the most part Controllers. They have to deal with event handlers, state managment, subcriptions, api calls etc. By making those parts rerender just like the view will get you in situations where you have to think to do something that should be obvious and straighfoward. I don't like Angular either, but I believe they have a better component design, you know that contructor will be called just once. Maybe it's hard to think in a better alternative because people can only see the React way of doing things... But look at this prototype for example: stackblitz.com/edit/async-in-jails?file=app.ts The only function that get called many times is the onclick handle function. So the rest is static, only runs when component mounts. So you can do the other things like ajax calls with async/await and everything without worry about other issues... useEffect is not needed in this world.
@@O_Eduardo Agreed that React components (well components-based architecture in general) does more than just UI nowadays, but that is inevitble-any rich web app will have to introduce side effects (events, async IO, etc.) One could argue that re-rendering the components when state changes is desirable to keep UI in sync with the state. The only rules in React you need to know is rendering happens on mount, setState and passing new props to a component. Of course there are cases where you only care about the UI changes that shouldn't be based on state, in which cases you can manipulate the DOM directly without triggering re-renders, but those are mostly for animations and highly interactive components (drag and drop, virtualized lists, etc.). It's a hard problem to solve, because side-effects are complicated in general and you have to deal with them in different ways based on context and requirements. useEffect is a low level primitive in React and ideally you should use use a library to handle async operations, caching and state. In the example you post it does more than just call "onclick"; it also mutates the entire DOM. According to the impl. it just replaces everything in the template when state updates. Not sure if this is an oversight but doesn't seem right.
@@dealloc Yeah makes sense your thoughts... From my point of view, is not like we are doing more then UI nowadays, in fact, for me front-end chalenge is about dom update and not the html rendering. But React mix the both concerns and its part of the things that stays in the way, it´s trade-off... ( You are kinda stuck on JS even on server side because that coupling ) You could render all your application with server side rendering or using static generation boilerplate with some node template system, and you´ll realize that some parts of the application is in fact dynamic...not all of it ( SPA´s is an exception ) The example I showed uses diff dom internally and gets html from the custom element and compiles it, so it´s not an innerHTML, it has diff dom in it context the other parts of the app will not be mutated or it will not have any diffing. It relies on Island architecture, because in practice your site is dinamic but you rarely need to update all components in the page at once, you just have to update some parts of your application.. So I use a state managment library to do those comunications and ui sync or sometimes I just use a pub/sub pattern which is simpler. Part of the bad design for me in react is that you have to think in performance all the time, by making several assumptions, like you did in the example, so you shouldn´t have to worry about, because the library and the way it work should address those issues. useMemo, useCallback, useRef, how to use context without updating several part of components tree.. etc... all these things just exists because you are stuck on React world. But There are no such thing as silver bullet and perfect world. React does a thing that would be impossible in the way I´m proposing, which is write the same code that can be rendered in server side and its the same code that will be executed in clientside... sometimes its very convinient.. but you pay a high cost for the other 99% of the scenarios which could be fine to separete that rendering html from js logic... You won´t be able to integrate with other template systems, server side frameworks in other languages, and have to wait for some React-like UI library because it doesn´t integrates well with vanilla UI solutions, so its about React community, not JS community... Idk... it´s been 5 years I´m working with complex apps using js without React now.. I feel like I prove empiracally for myself that those things has value, but... 99% of the times.. not necessary...and if it was, Angular, Ember, Vue, Lit, Svelte, all of them would need to use the same principles or you wouldn´t be able to build complex apps with those frameworks, which is not true.. But at this point we are in modern tech, is all about taste and marketing...Maybe Astro will lead us to a different way in the future, idk, but I like what they are doing in order to integrate the most adapted framework.. I like new things and different ideas, I feel like we are trapped in the react for a long time..
Great talk
4:15
I think David has been teasing us with xState v5 for like 2+ years
It's a hella overhaul, and they're shipping with great docs, so I'm eager regardless... but yeah, it's been a long time 😬
Since 2019 I think! Aaaand it's finally out 🎉
Great talk
Hi, how to display 3d .glb files from url in react native app
Damn! This looks cool ! Type safety and No run time overhead !
It was a great conference - full of amazing people!
Thank you for the lesson..
🌟 𝐩𝓻Ỗ𝓂Ø𝓈M
It was great time to be there and meet nice people 🙏🏼👌🏼 thanks
Great talk.
Okay fine... I'll try out Solid soon. The more code I get to throw out while still maintaining understandability is awesome and it looks like Solid is going to get that done for me :)
Good job, Keb!
first question: can you have an effect with 3 dependencies inside, but it's only triggered when two of that dependencies update? there are use-cases like this, and I don't see if we can handle it here second: if effect must trigger function from props, what's the implications of that? I mean, if we pass that function as a prop, how does Solid know, if function is the same?
Wow, this is awesome and I'm a big Tailwind guy. I'm switching over to vanilla-extract!
2022 :D, I've just started building a project and honestly this is a great overview of how to setup CI | CD
when can we use stylex? i can't wait 🥴
great job, thanks. u make me understand about ci/cd and also now i want to learn presentation like you
Please open source this!
Nice video!! you got a like!, one question, what vscode theme is that? i like it and i cant find it in google
is it possible to get a job as a junior react developer for an international student who studies at Tampere University in CSE? as an international student is it mandatory to learn finnish to get the job ?
That looked absolutely horrific. What sane person would even consider xstate after looking at that counter example? This is the perfect example of over engineering and making simple things complex. Total garbage. XState is a dead library.
Can you please make a video showing how to set up Linaria in a new react project? that would be extremely helpful