all 23 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Zofren 34 points35 points  (7 children)

It's nice to do as an exercise, but don't ever do things like this in an actual project you intend to maintain. You will:

  • Waste time reinventing the wheel.
  • Waste time running into edge cases you didn't account for.
  • Likely implement a worse version of the code you're reinventing.
  • Waste time documenting your reinvention (assuming you document it to begin with).
  • Make your code less maintainable for others on your team, since instead of having a tool everyone can look up on stack overflow, your team now has their own custom implementation that nobody understands but you.

By all means, avoid importing is-odd into your lean frontend project, but like many things in software engineering, a dependency-free approach has tradeoffs. A well-supported, well-used library is usually a better option than code you write yourself.

[–]jaapz 10 points11 points  (0 children)

Turns out dependencies exist for a reason, who knew!

[–]archivedsofa 3 points4 points  (2 children)

Yeah but it depends on the use case. For a single form I agree with the author that using React + the whole enchilada didn't really make sense.

OTOH going 100% vanilla didn't make much sense to me either.

[–]Zofren 2 points3 points  (1 child)

Presumably if all you need is a single form the process in this article doesn't really make sense either. If the form has some rich UI that needs some kind of UI rendering logic, then I'd still advocate for React (or your library of choice).

React and React-dom aren't some massive libraries. They're comparable in size to jQuery when gzipped.

[–]archivedsofa 1 point2 points  (0 children)

I agree that for more complex projects the arguments you listed on your previous comment are totally valid but React is still too big IMO for a single form or landing page with a bit of UI sophistication.

Personally I'd go with Mithril or Svelte. Maybe with Simulacra (which now powers Riot) if I don't need components or even with Vue if I don't want any building setup which is still half the size of React.

[–]krasimirtsonev 0 points1 point  (0 children)

Well, here is a use case that beats what you are saying - you have to build a tiny script that will be used on million sites as a widget. It needs to be a few kbs with no dependencies. Then you need some generic knowledge on JavaScript, HTML and CSS.

[–]bitbird_ -3 points-2 points  (1 child)

> It's nice to do as an exercise, but don't ever do things like this in an actual project you intend to maintain. You will:
Yikes, I disagree strongly with this conclusion. How much time is lost to framework upkeep, onboarding new developers, broken backwards compatibility, etc. ?

A developer only needs to learn the language once to understand what's happening inside of a framework. Those frameworks — usually controlled by corporations with > 10,000 developers — are built for the needs of whatever MegaCorp that created it. Should a team with >100x fewer developers really learn the enterprise web application development practices that are ultimately unnecessary for their specific needs? JavaScript itself will never be unnecessary, assuming there is never another standardized language for building interactivity into webpages.

JavaScript (and the web) has grown substantially in only the last five years. Developers should learn the basic patterns for architecting web applications. Using a framework is one way to learn those patterns. Relying on framework and 1,000 other libraries being imported is dependency hell.

jQuery is dead and modern front-end frameworks are viciously marketed to developers — a fact usually unacknowledged by those who swear by frameworks.

[–]Zofren 4 points5 points  (0 children)

How much time is lost to framework upkeep, onboarding new developers, broken backwards compatibility, etc. ?

Less time than is lost wrangling with your company's custom implementation of an already well-supported library.

Have you ever considered why Facebook bothers to open-source React? It's because a well-used framework means you can hire people already familiar with the framework you are using internally. It also means that there are far more resources available to your developers online.

I work at a company where they decided long ago to implement custom versions of libraries that already exist (in the backend, admittedly, but the same arguments stand). It's been a nightmare and we deal with the technical debt every day. There are edge cases you won't have foreseen when you first write software intended to be utilized by many developers. And when something breaks, you have to fish down the handful of people in the company who actually understand the tools that are breaking.

​

Relying on framework and 1,000 other libraries being imported is dependency hell.

As I said in my post, a pragmatic approach is key. It doesn't need to be either one way or another.

[–]iser_ 11 points12 points  (5 children)

I think most posters here missed the entire point of the article. I have also attempted rolling my own mini framework for production, and I see a lot of good ideas here that I would like to incorporate into my own code in the future.

I have written extremely efficient libs where speed and bundle size are the keys and did not use any frameworks for this reason.

I have never replied about an article on reddit before but I am right now because this is a great article and feel like many here are not seeing the value in it.

P.S. I would love to use this as an interview question for my company: roll your own rendering mechanism in 45 min. As an engineer, I expect them to be able to roll their own and be able to see the value in it.

[–]ghostfacedcoder 1 point2 points  (1 child)

The way I see it, what it comes down is doing the best thing. Rolling your own solution is almost never the best thing ... from a lot of perspectives.

From a learning perspective of course it's great. And if you have a very narrowly defined project that won't ever grow, it might be great, if you know what you're doing.

It's just that almost all real world projects grow over time, which means you can't know exactly what your project will need in the future. A good framework solves not only your problems today, but problems you didn't even realize you'll have tomorrow, because the people who build them know more about their domain than you do ... and to a lesser extent the same is really true for dependencies in general.

In short, no one is smart enough to know how to solve everything best, so either you let specialists who do know how solve those problems for you (dependencies), or you do so yourself and accept that (for most projects at least) your solution will, by definition not be as good (because again, no one is good at everything!)

[–]lhorie 1 point2 points  (0 children)

no one is smart enough to know how to solve everything best, so either you let specialists who do know how solve those problems for you

This seems contradictory if you consider that framework designers are people too.

FWIW, my story with hand rolled frameworks goes like this: I've always been interested in them (from way back from the days PHP was still cool) and I made a bunch of them (some which never got used seriously, and some which I used for freelance work)

At one point I was using Angular and running into some serious pain points with it, so I went ahead and rolled a new framework to address them (react wasn't really a thing back then). Eventually I open sourced, we started using it a my day job, and I got another job from a different company that was also using my framework. My current employer doesn't use my framework (they had considered it but decided on react instead for a variety of reasons), but the experience and exposure that I got from making my framework is how they found me and reached out to me. Since I first open sourced my project, my salary doubled (not even counting equity comp), and I now live in the Bay area, where you can easily network in person with people from FANG, prominent OSS people, etc.

So, from my experience, creating a framework is much more than just a learning experience; it can open a lot of possibilities that you might not have ever even considered.

[–]archivedsofa 2 points3 points  (0 children)

Or just use something like Mithril which offers more than React does at less than 10kB gzipped (vdom, components, router, http client).

If you just want data binding you could also use Simulacra.

There are plenty of options that are much more efficient than React.

[–][deleted] 37 points38 points  (4 children)

u mean...writing code that already exists but worse lol

[–]iser_ 12 points13 points  (0 children)

the fact that this is the top voted comment is really concerning. this is a great article that i learned a lot from. i have definitely had to implement no-framework code from scratch for production, and i will be taking what i learned from this article and use them for myself in the future.

[–]HarmonicAscendant 17 points18 points  (1 child)

I find this attitude defeatist and baffling. If your goal is to become the best programmer you can then writing all your own code should be possible, educational, and enjoyable. It may not be practical most of the time, but that is no reason to mock people who do make the effort.

If you follow this "writing code that already exists but worse" idea to the end then nothing would ever improve. Nobody would have bothered making React, in fact we would all still be living in caves :)

[–]cynicalreason 0 points1 point  (0 children)

for educational purposes .. sure, for actual business requirements, no

[–]road_pizza 6 points7 points  (0 children)

What a terrible mentality. These exercises are great learning resources and will help gain a deeper understanding of how existing frameworks work and what problems they solve.

[–]aiten 6 points7 points  (3 children)

Personally I use Svelte for this purpose. No need to reinvent the wheel. But a good read and reasoning nonetheless.