Developer, Architect and Independent Consultant at Ducin IT Consulting. Co-Founder of architekturanafroncie.pl Helping dev teams in improving overall quality and architecture of their systems. Creator of architekturanafroncie.pl. Advocate of sane and long-term solutions for JS ecosystem. Critic of abusing buzzwords. Experienced in both frontend and backend. Trainer with a passion to explain how things work and focusing on _whether_ they’re needed - or not. Ex-theatre-actor. Probably addicted to coffee, definitely addicted to music.
If you ask any frontend developer: "is your codebase modular?" I bet they'd say "of course!" The truth is, so many frontend codebases start to look like spaghetti and unnecessary complex all too soon. The issue is caused by lack of general knowledge of architecture fundamentals, which frontend folks don't seem to be interested in, in the first place. Let's talk how we can challenge the rest you think about modularity in your codebases.
Angular has been perceived as a rather complex framework by some, yet it's used massively by enterprise-scale systems. Whether we agree with the criticism or not, the framework is undergoing a monumental transformation. In recent months, Angular is experiencing a period of frequent and significant updates and - at least considering previous years of stagnation - groundbreaking changes. These include not only the features, public API and architecture, but also to the mental models that developers come up with.
We're witnessing the next step of the Web Architecture evolution: after MPAs, SPAs, SSR, SSG/ISG, it's time for Server Components. Many questions arise, such as: * does this architecture suit the needs of my business and my application? * what are the benefits to expect? * what are the downsides and do the benefits overweight them? * and... aren't we actually taking a step back (!), since we're moving more operations back to the server? Let's deconstruct the hype around Server Components, with a tiny bit of technical details behind React Server Components. Let's discover how the fusion of client-side interactivity and server-side efficiency optimizes web vitals and (r)evolutionizes web development.
This is the first out of two presentations that will discuss various ways to craft asynchronous JavaScript (part two in December '17). We'll start with fundamentals of asynchronicity model in JS, go through callbacks, promises, coroutines and finish with async await. There'll be many questions and/or discussions with the audience, so forget live streaming and join us in person :)
JavaScript is the most accessible platform of our times. Yet, it has many downsides, especially when it comes to big scale applications, being developed by multiple developers. TypeScript is a solution to that problem. Being the new guy, it has already found its place in the JS kingdom, among rivals such as CoffeeScript and ES6. Angular2 chose TypeScript as its language. It has bindings for most existing libraries already. Some people, including me, state they'd choose TypeScript for development of any new project. So why is that? In this talk I'll highlight the native-JS problems that TS solves and compare it to its rivals, CoffeeScript and ES6. Moreover, we'll see how do non-Frontenders see TypeScript. I'll share my experience of banking software development.
Lekki temat-dyskusja poświęcony temu, że w ostatnim roku-dwóch devów JS zalewa morze nowych bibliotek i ciężko się w tym ogarnąć. Pierdyliard różnych bibliotek robiących to samo, developerzy nie mają możliwości ich porównać, zrobić dokładnego researchu co z czym bangla itp. Nie ma ultimate stack of tools (jak w Javie). Talk mniej techniczny.
Single-Page App architecture is still being adapted into huge enterprise systems. Each design mistake costs a lot and is very difficult to refactor, if possible at all. The good and bad parts of growing JavaScript code.
JSON is the most widely used data exchange/definition language in the web. It's as flexible as XML and as concise as possible. However, the structure flexibility of JSONs comes with a price of losing control of what data is being stored. If you want to have your JSON under control, let's dive into JSON Schema. It made my work easier, hope it makes yours too!
