21–30 of 49 posts
Half the time is spent on novel new ways of adding in a loading spinner. Perhaps it's just his demo, but I can sense Roy Fielding shedding a tear.
In the future, JS libs will be popular for 15 minutes.
I think it'll also be interesting to see how Apollo continues to evolve in this space as more people adopt GraphQL in their React apps. Apollo is getting more and more state management features that can handle lots of what Redux is doing: https://dev-blog.apollodata.com/the-future-of-state-manageme...
Apollo uses Redux under the hood.
However - after having plugged in a lot of reducers - the boilerplate code required to do simple stuff becomes a real bore. I've since compromised by using a simple `key-value store` reducer that I can write new values to without needing a new reducer with accompanying actions.
I'm sure this is not how it's supposed to be used but nobody ain't got no time for making all that boilerplate just for a button :-)
Like I say - it's worth it though - it's amazing how large frontend apps "just work" once you have the state in a single place and the UI rendering from it and it alone.
The async rendering rendering stuff Dan is showing in his talk ( https://www.youtube.com/watch?v=_c7ajDXb4qw ) looks great, but I disagree that this is a redux killer. redux is useful for a lot more than just async fetching & loading. I think these new features will just reduce the scope of what redux is used heavily for.
Redux deliberately doesn't deal with async processes, that's left up to the user.
Earlier quoted context omitted.
I will keep using VanilaJS, nothing else is worthwhile unless to pump up CVs.
So for every project you implement solutions to common problems differently?
ASP.NET, Spring and JEE work just fine.
Earlier quoted context omitted.
So for every project you implement solutions to common problems differently?
We use server side rendering with minimal JavaScript for dynamic behaviors. ASP.NET, Spring and JEE work just fine.
Don't get me wrong, I agree server side rendering is a lot simpler and solves many problems, but there are plenty of reasons to go with a full client-side app and in those cases libraries and frameworks, while not essential, are logical and sensible conclusions.