loading...
Cover image for Explain your front-end framework to a React developer

Explain your front-end framework to a React developer

stereobooster profile image stereobooster ・1 min read

Hi, I'm React developer. I'm not a React fanboy. I don't think we need to built-in React inside browsers. I don't think you need to use React for landing pages (with barely any interaction). First time I saw JSX I thought "oh no XML again". I work with React day to day (recently; before it was Ruby). I hope I'm more or less open-minded.

Given this, try to explain why would I want to try another frontend framework. What are the sweet spots? What do you enjoy about your framework?

PS. I have tried different frameworks like Angular and Ember a long time ago, so my understanding is most likely pretty outdated.

Photo by Kylie Haulk on Unsplash

Posted on by:

stereobooster profile

stereobooster

@stereobooster

Hello, I'm a full stack web developer. Follow me on Twitter!

Discussion

markdown guide
 

So first, my perspective. I still live with code that was written more than 10 years ago by me and others. Maintainability is something that is very important to me -- something I wish had been more important to us back then. But hey, we did the best we could with what we knew at the time.

Today, I try as hard as I can to avoid building my code on top of frameworks. Because in the end I've decided that all of them are leaky abstractions. Ultimately, I not only have to understand my code, but I also have to understand the intricate bowels of the framework to make it behave correctly. Sure it saves time in simple cases, but I always find what I thought was simple or common is not quite the same as what the framework devs thought.

So I use the MVU pattern. I've used it in Elm and F#. MVU isn't what I would call a framework, although it does come with some pre-packaged functionality (view rendering especially). But it's not quite what you think -- almost all the types and functions you create in MVU are to solve your problems, not to satisfy technical requirements of a framework. Less of the things you learn are non-transferable. And in fact I have learned a great deal from this pattern that I have also applied to the back-end.

The end result is something that is ridiculously maintainable. But there are downsides. The main one that comes to mind is upfront effort to learn. It's different. And since it is a fairly uncommon way of doing things, there is less information than you might like available. And sometimes what is there leads you down less optimal paths. But the great thing is that since it is so maintainable, you are not unduly penalized for those early mistakes. You can fix them -- with some effort, but without much risk. Some people complain that it has boilerplate. Maybe it does in some places or with some strategies. But when I consider the framework wiring boilerplate I don't have to write (or worse, the invisible magic wiring deity that I hope I don't make angry), I think it is roughly equivalent.

I've been meaning to write an article about it, but I've been heads down in a project and haven't had the extra bandwidth.

 

Most of the frontend frameworks/libraries out there today focus on the reactivity concept, which makes it easy to change any state so it's reflected everywhere on the app. I think this is great!

But it requires a lot of boilerplate code to get simple things done. I think the Svelte library is on to something because they focus on less boilerplate code/overhead to get stuff done.

You can read more about it here in their own words.

Thanks!

 

I also heard that the latest version of Svelte (3) is going great. It's all over the news nowadays.

 

Link doesn't work for me. UPD: I can use google cache or web archive, just saying that link doesn't work

 

@stereobooster , the link should work now...hopefully 🙂 .

 

I like stimulus js. It just attaches to the HTML you already have and gives little sprinkles of functionality. Great for not data heavy apps. But you want to have a little framework.