Forem: Or Yoffe

You don't need a frontend framework

Or Yoffe — Sat, 20 Jul 2024 09:59:21 +0000

You can and should build one yourself, but you would benefit from using a framework in production.

Modern JavaScript and Browser APIs

Today you can achieve most of the features with "simple" JavaScript (TS) to update your state, have routing, a bundler with code splitting, maybe JSX, templating and even getting different components like a calendar or emoji picker you can do in many ways like copy an example from the web and make it your own or use an OSS web component.

Browsers and the JavaScript community have came pretty far from the old days of IE6. You have many ways to implement UIs and a ton of libs to do the small thing you want. jQuery and other major APIs were added to the library and our bundlers are plentiful with many features out of the box for all your CSS, HTML and JS needs.

Issues

Developers complain about speed, JS bundle size, react-dom weighs too much. Well if you think of these frameworks and their components as abstractions, you should try to understand the payoff. These known frameworks have been tested on many edge cases your own code wasn't even ran that many times. So many bugs were fixed and though you might not have the edge cases their fixes are in your framework. Is this a good thing? depends on your opinion, like best practices, would you want them implemented from the start for the chance you'll need them and enable extending your apps or prefer to keep it small and to the point.

A good reminder from OSS and from work is that everything you write will one day be legacy and will be passed to someone else to maintain potentially and in the worse case it will be you. IDK about you but I don't remember every line I wrote 5 years ago, who am I kidding, 3 months ago 😅. My point is that someone will have to deal with what you write and they will need docs and examples like StackOverflow or ChatGPT to maintain that shit you called the best thing ever. For me TypeScript helps with keeping things maintainable when paired with tests to ensure I don't break everything.

I recently updated my library Jstates and had to refactor the majority of the code after 2 years of not touching it, and it's a super simple library with 1 function. Having tests and types are a huge benefit, and I did go to many documentations for rollup, vite, vitest and other tools I used to update my code base.

Build your own Vanillajs framework

I like to breakdown tools to understand how they work to see how I could build the same and then understand the choices the author made and how things work underneath. I always try to create examples and enjoy the challenge (when it works). For the example, I worked on creating a frontend app without any framework, I used my Jstates library to have updating values and a lib for JSX and vite for bundling and the rest was pretty ok without a framework but with all the base features I need from any framework.
The repo
Including TypeScript, JSX, State updates, Templating, Routing, code splitting.. What else do you need?
Ok.. go ahead and add tailwind or another CSS lib, but IMO modern CSS is enough 🤷

I would recommend trying to build one yourself for learning, and maybe you'll find a use case to actually use it. For example, if you're unfamiliar with SPA routing, doing something like this could give you insights into what you need to do to trick the browser to do what you want and not redirect and refresh your frontend app on every click. There are also vanillajs libs for this just like anything else, the point it you can try and make things different and make your own.

I know there are many frameworks, some say too many, but I think it's a good thing. There are many use cases out there and it's great to find a battle tested, production ready framework that fits your needs that someone else is maintaining for free. The more we share our tooling the better they usually are by having more people contributing to the ecosystem with plugins, complimentary tooling, design libraries on top, creative ideas, articles and "How to" guides and more..

Frameworks are helpful to abstract away a lot and get something production tested very quickly off the ground if you know them already. Animations, pre built components and more and more features and capabilities.

More issues

Lots of people say they don't need all the new features in react because they don't have the needs of fb, well they might need all the goodies from the react community or they might need a new developer to get up and running fast in the new job, and they know react because it's the hottest thing right now. That's how the abstractions helps. Also in the job market, it's hard to find positions that don't require you to know one of the frontend frameworks for a frontend role.

This standardization, also around the frameworks features are there to help us abstract noise away and make us more productive. Many junior developers that I worked with had an easier time starting with a framework than Vanillajs, I started with jQuery. The issue for many is added features on top which they feel they don't need, and they might be right, even though you often don't have to use them in order to use the framework. Back in the early days of react, I met teams which used react for rendering and and older framework for their state management, this was before redux even and I think it was Backbone or something, anyway..

The real issue for many developers are the other developers on their team that would want to use these new features and abstract the code even more. I believe this is actually good as it would bring up the discussion of the benefit of the features and weighing their benefits. I was in some teams that were not using library features because of a bug or because the team decided not to. Only issue there is you go away from the main usage of the library, which might be harder in the future.

Final works (before everyone attacks 🫣)

Go build your own Vanillajs framework, learn from it, understand the frameworks you use better as a result and share the knowledge. And remember, if you think of open sourcing your framework or library, don't expect people to use it, and if they do, now you'll have to maintain it and hear their complaints like the lovely framework maintainers 🙇🙏
Some great examples are Solidjs and preact

My way into open source 👻🎸

Or Yoffe — Thu, 13 Aug 2020 11:23:37 +0000

My way into open source 👻🎸

I want to share with you my journey to open source in the JavaScript programming community.
The beginning 🕑

Since I started writing code 🚶 I learned open source tools that made my life easier so that I didn’t need to learn every specific implementation technique 📚 for every special feature I wanted to create 🙇.

After a while, I realised the open source projects live in Github ❤️ and are relatively open for the users to understand how they work and also to user input and contributions from code to documentation assistance.
It seemed too intimidating to contribute directly 🙉 and took some learning and lots of context in order to contribute to them 🙈, but back then I didn’t even think I was good enough to add my shitty code to the Olympus mountain ⛰of these great projects 💪.
Since I started learning new different tools 🤓 like React.js, express and socket.io, I made some boilerplates and put them on Github so that they would be public and I could use them in the future too.. I didn’t know this would be the start of my contribution to open source.

After I got some experience 🏋

After a few years of working as a Front-End developer, I joined a company that asked me to build a react app for Web, IOS and Android. After a bit of research 🔍, I found that a library called react-native-web was the best choice.
While searching, I found a few boilerplate projects that I could learn from, since the library itself didn’t have such advanced documentation or examples of how to integrate certain things. Even more, I barely found Stack Overflow answers or questions around the topic 😮. I was surprised that most of the good knowledge I found, for edge cases issues, I found from Github issues on the project repository 🎁.

I got the feeling that there were many areas to contribute 😻 and I even tried to figure out 🤔 a way to contribute directly to the project but didn’t have much success in solving a few bugs that were issues in the project’s repo 😣.
I wasn’t sure how I could contribute to this library (which felt more like a movement to me 😇 🏩 with a common goal), until I read Ken Wheeler’s “guide to Open source” ❤️ https://medium.com/codezillas/a-bitter-guide-to-open-source-a8e3b6a3c1c4
It is a good read with good tips ✅ about how to create your own project and contribute to the community 👪 from a well experienced member of the open source community.

My own project 👶

After I had my first boilerplate with the react-native-web, I went to my boss (Richard Abendroth) and asked to open source it (meaning to make the repo public).
He loved the idea and pushed me to pursue it ❤️. After a few weeks I published it and a few months later I wrote my first Medium article about it and my journey of discovery in this new area.
I shared the article on LinkedIn, Twitter and many Facebook groups 👍 in order to get some feedback. I was shocked to see how many people were reading and how many people visited and liked ⭐️ my project. I would show my friends and colleagues the numbers every few weeks 🤳.

I started working on a talk for a local meetup about my experience and basically about the article topic. I took the article I wrote, removed the parts I didn’t want to repeat and added some verbal topics that would be better and started putting Gifs and slides of code for my talk 📽.
After I had the slides and the talk down, I decided I’m ready and submitted a request for a local reactjs (related to the topic) meetup. After a week they replied and I had the spot! 🙊 The talk went great and I really enjoyed the experience and I wanted to do more for the community and contribute more after I got such positive feedback all around 😊.

After a while I even got some issues opened up on my project from people all around the world 🌐 that were using my project. I felt honoured that other developers were using my code to work and to do their own projects. This gave me even more ambition to do more and find a better solutions for the community.

Aha moments 💡

As a Front-End developer, I was used to have cool CLI tools 😎 that would start my projects up, as the trend goes in recent years. I felt this was missing in the react-native-web community and decided to build one❗️
I went over a few great CLI tools that were already well established and that I used in the past. I learned from them and created my own project for the CLI tool 👶.
I published it to npm and in the social networks 👍 again and the feedback was even better 🌟. I was thrilled and felt a need to reply to every issue right away, as I felt honoured that people were using my code and that I should answer and help people with the problems they encountered. Even though most times it would be with other libraries and not my own code 😅.

After your idea becomes reality 😱

As the time went by, more and more Github issues were opened and even one Pull request 😍 to add some documentation. More feature requests, and also a bit more pressure to get things done quicker 😓. But I felt it was a success 😁 and I finally did something good that people liked to use. Now just maintaining it, was left to be done.

Maintaining sounds bad 😰, but this meant for me to find out about other people from the community that requested features I didn’t even think about. To discuss the benefits of each suggestion and realise what would bring more value to the project. 🤔
After my second big release of the project, I received such compliments 👌 and even more downloads 📈 that I felt I should share my experience of doing this project and to push more people to contribute and go on this journey since open source helps us all the time.

Hope this gave you something, as my journey gave me a lot personally 🤗

Learning (software)

Or Yoffe — Thu, 13 Aug 2020 11:12:40 +0000

Learning (Software)

Many people ask a lot about how to learn X (language/framework/library). Many people also answer the same answer again and again: make a project.

I want to elaborate in this article about what that answer means, how to learn and why this is the right answer.

Why learn something new?

Initially you have a reason that you want to learn X. Whether it is to put on your CV or to know more about it or to use it or any other reason you might have.
First you should make a plan to fullfil that need: new framework => to get a new job.

In the scenario of trying to get a new job with a new tool, you can see what is the common use case of that tool for example. Plan a project to show off and to learn from. Work on it in small steps to tackle problems and learn from each part. This way you won’t give up and you could see small improvements in your learning process and also you can decide in the middle that you learned enough and change the plan at any point.

Basics are the reason you want to learn

Obviously you would go after the basics of X first. The issue here is knowing what they are. But you can answer this yourself by asking what you need it for. Using a frontend framework? Google what is it good for. Same with libraries, what to learn d3, you will find it’s mostly used for charts. You can then later choose a few charts you want to implement and start from the easy parts.

Real world example

A good current example is reactjs, a UI library/framework. For me it’s good in rendering your UI based on the state of your application in contrast with jQuery which you would manually go and change stuff based on events. Reactjs is mainly about the component usage with internal state and lifecycle methods.

A small app that uses these when needed:

componentDidMount for api calls and dom event listeners
componentWillUnmount for removing dom listeners
component internal state for data and user interactions that changes the view
Passing properties between components

From there you can tackle the usual different cases of real world applications like forms, menus, SEO, app state, localization and many others. Most developers don’t tackle all of these in their career! We are driven by needs that create problems to solve and we learn from them.

So like on the job when you have problems to solve, all you need is to create a need from the reason you want to learn, then you would have many problems to split, solve and learn from.

From small libraries with one use case to a complex framework with a new way of thinking

I find it useful to find code online, copy and try it in an existing project. This method is very useful with small libraries to get a real feel from.
The bigger X is, the bigger the journey and the effort/planning would benefit the learning process.

Summary

To learn something, we need to use it. To be motivated to use it and not get lost, we need a good reason. Anything we want to learn has a need to fullfil, a target we should focus on to get to our goal. This is also true outside of the software world.

Please let me know if this helped you or if you have a suggestion or some other way you learn and is proven to be useful for you.

why does react context need the provider?

Or Yoffe — Sat, 09 May 2020 08:40:52 +0000

Hi everyone, i wondered why using context provider is necessary and couldn't find the answer (besides that it's the react api) and therefore posted a stack overflow question with more details. I would love your opinion

https://stackoverflow.com/questions/61693937/why-does-react-context-needs-a-provider

A simple, small JavaScript state library called jstates 📡🛰️

Or Yoffe — Thu, 26 Dec 2019 00:36:45 +0000

TL;DR
jstates: the core state library https://www.npmjs.com/package/jstates jstates-react: A Reactjs subscribe function for jstates https://www.npmjs.com/package/jstates-react

A simple (one file ☝️), small (less than 800B 🙉), extendable ♻️, and most of all 👀 understandable, JavaScript state library and in addition a Reactjs❤️ subscribe function to use as a HOC (Higher Order Component) without context complications.

Why another state library? 😒
There are many great state libraries for react and JavaScript in general (for example: redux, mobx, unstated and more…). So why create another one? 😏

I wanted to have the simplest, most clear and usable solution I could think of. I wanted to have a few features in a state library that I didn’t find together in one library:

Tiny bundle size (so I don’t have to think twice before installing)
Small code base (one file: index.js)
Simple and understandable (so other developers could start with it quickly and even improve it)
Extendable (so I can add the functionality I need and others could too) Can have multiple separated states
The best api parts of the state libraries I used (IMO, feel free to copy and create your own or maybe create a Pull request 😉)
Whatever else others want and need that they can’t find out there…

State can be simple and there is no reason why there shouldn’t be many of them out there for many use cases and for the developers around us with different (some might say “strange” 😝) flavors.

When I started with Reactjs 😍, before even playing for a while with react, I was told to use redux and to learn it straight away 😓.
Redux (“The King” 👑 as some might call it) is a great library 👍, but I had a hard time with it and a harder time throughout my career explaining it to people 😣.
In addition, explaining the state issue and the components communication in Reactjs and why we need an additional state instead of global objects is complicated enough 😕. I don’t think we need another additional concept to learn on the way (again, IMO 😅).

So without further delay 📣, I would like to present to you…

Jstates, a simple and easy to use state library that would work with any js library or framework 🎉

And if you want to use it with Reactjs, it fits without any in the root of your app since it’s separated from the components context 😃

Happy hacking 👷 and thank open source people for giving their time to create the great tools I learned from 🙏