recentpopularlog in

dirtystylus : javascript   469

« earlier  
Disenchantment - Tim Novis
After years of working in SPA-land, rarely touching a server-rendered website, I was amazed at how quick it was to get up and running and start feeling productive right away. Developers are quick to extoll the virtues of tools like Create React App, and whilst I agree - they’re great! It really takes a while to start feeling productive when setting up a new SPA from the ground up. So much non-work has to be done before the real work, what you’re likely being paid to do, can begin.

I had an admin panel with authentication, pages, routes, templates and CSS, flash messaging, The Works™️ set up in an afternoon. I hadn’t felt this productive in years. But best of all, it was fun. Of course I still enjoy working with our modern, flashy tech stack - but this felt so different. No waiting for recompilation. No React devtools. No props and state flying around. No convoluted centralised state management. No worrying about loading states. Complete bliss. It was functional, it was fast, and it felt solid. The only thing I legitimately missed from a “developer experience” perspective was TypeScript. TypeScript is great, and gives me much more confidence when shipping code.

I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.
programming  javascript  webdev  tools  nodejs  reactjs  backend 
12 weeks ago by dirtystylus
The nostalgia! While cleaning up my drive, I came across the slide deck from the presentation that showed me that…
by:nadiehbremer  d3js  dataviz  javascript 
january 2019 by dirtystylus
Andrew Clark on Twitter: "So many update performance problems in React go away when you use local state. If you have some state that updates frequently and needs to be fast (ahem, forms), probably shouldn't be putting that in a global store that the whole
So many update performance problems in React go away when you use local state.

If you have some state that updates frequently and needs to be fast (ahem, forms), probably shouldn't be putting that in a global store that the whole app subscribes to!
codearchitecture  reactjs  javascript  statemanagement 
september 2018 by dirtystylus
The "Developer Experience" Bait-and-Switch | Infrequently Noted
JavaScript is the web’s CO2. We need some of it, but too much puts the entire ecosystem at risk. Those who emit the most are furthest from suffering the consequences — until the ecosystem collapses. The web will not succeed in the markets and form-factors where computing is headed unless we get JS emissions under control.
javascript  webperf  performance  by:alexrussell  frontend  progressiveenhancement 
september 2018 by dirtystylus
How is JavaScript used within the Spotify desktop application? Is it packaged up and run locally only retrieving the assets as and when needed? What JavaScript VM is used? - Quora
This organization structure, combined with the global-ish nature of JavaScript in the browser, has made us build the desktop client UI out of many small, self-contained web apps called Spotlets. They all run inside Chromium Embedded Framework, each app living within their own little iframe, which gives squads the ability to work with whatever frameworks they need, without the need to coordinate tooling and dependencies with other squads. While this approach has the disadvantage that we have many duplicate instances of different versions of libraries, increasing the size of the app, but it offers the massive advantage that introducing a library is a discussion between a few people instead of decision that involves ~100 people and their various needs. Not only would such a big discussion extremely time-consuming and hard, it would also force us to use a least-common-denominator approach to picking libraries, instead of picking the ones specifically tailored to the problem domain of each squad. Considering the size of a single song compared to the size of a JavaScript library, this trade-off is a no-brainer for us.
programming  javascript  music  spotify  codearchitecture  npm  via:peter_chappy 
july 2018 by dirtystylus
« earlier      
per page:    204080120160

Copy this bookmark:

to read