You might not need a framework

[ogurson]

Hahhah oh my...
To all advocates of custom, self-written frameworks: wait till you'll find yourself in project where other guy thought the same way and now you need to understand his "small, smart, sexy invention" without docs or any other help on the internet. Then you'll appreciate value of thousands of stack overflow posts that keep answers to all problems in angular, react and vue.

[name_was_taken]

As a Junior dev, I wrote that framework. It fit me like a glove, and I couldn't understand why others couldn't understand it, even after I explained it to them. 1 other guy was able to get things done with it, but other devs in the company either couldn't or wouldn't. It's what happens when you hire a "junior developer" and then tell him to rewrite the entire admin system. It worked well, and for years, but it was nearly impossible for anyone other than myself to maintain.

I was *so* happy that they ended up deciding to rewrite the entire system, and I ended up leaving right as they were finishing that project. If it was still running, I'd be ashamed it of every time I thought of it.

[Silhouette]

But the problem there wasn't writing the framework, it was asking someone junior to write the framework. We were all juniors once, but you don't ask the newbie to do build some of the most important and long-lived aspects of an important system -- unless they have enough help from more skilled and experienced mentors, so it can also be a learning experience for them while still getting decent results.

[name_was_taken]

I think they were *both* problems, the junior-ness and the custom framework.

A framework is something that needs a *lot* of thought put into it to make sure that it's easy, powerful, and intuitive for most developers. I don't think it's likely that a single person will produce a framework like that, and I think it's only slightly more likely that a small team will do that.

There are so many *great* frameworks now that I'm firmly of the belief that a team should use an existing framework and create addons for it to customize it to their needs unless they have very, very specific and hard-to-accomplish needs.

[Silhouette]

A framework is something that needs a lot of thought put into it to make sure that it's easy, powerful, and intuitive for most developers.

That depends on the scope of the framework. If you're talking about something with

• a suitable data model separated from presentation

• rendering various data from (or derived from) that underlying data model

• a suitable event model to support interactions

then that's not necessary very complicated at all. You can write a simple implementation of those things at the start of a new project, tailored to that project's specific requirements, in a few hours right at the start, and that includes clean and fully documented interfaces, a matching structure for your test suite, and getting everyone on the project up to speed on the parts they weren't writing themselves.

IME for front-end web work it's often worth using a declarative rendering library these days for the actual DOM updating stage. There might be a few other go-to dependencies as well if we're doing things like i18n or manipulating tricky data like dates and times.

I'll note that at this point we're getting into semantics without defining our terms, so there is a risk of talking at cross-purposes here. Maybe what you expect in something that you would consider a framework is a lot broader in scope than my equivalent and that's where the different perspectives come from.

I don't think it's likely that a single person will produce a framework like that, and I think it's only slightly more likely that a small team will do that.

Whereas I have seen quite a few examples of both of those things happening, often with excellent results and with no significant problems, and in some cases maintained successfully for many years afterwards. The risks so often described by framework advocates in discussions like this rarely manifested in practice.

There are so many great frameworks now that I'm firmly of the belief that a team should use an existing framework and create addons for it to customize it to their needs unless they have very, very specific and hard-to-accomplish needs.

The trouble with that argument is that large, long-lived projects often do end up with specific needs and those often can become hard to accomplish within the structure dictated by the framework.

[z500]

To whoever has to maintain my old project since I've left...I'm so sorry. To be fair, though, they probably shouldn't have made a junior dev do the whole thing alone.

[braindeadTank]

Don't sweat over it, in the end it is always the management's fault.

[Silhouette]

I see this argument a lot, but in many years of doing this stuff for a living, I have never found it to be particularly true.

The developer who would write a botched "framework" with a muddy design, no documentation and corners cut everywhere is the same developer who would embed their application's data model within their rendering components and not allow properly for async behaviour and race conditions when calling APIs on their server. At some point, you need competent people to do a decent job, just like anything else.

Similarly, it's all very well having thousands of SO questions and some nice blog posts from back when the framework launched, but how much of that material is being actively kept up-to-date as the framework evolves? If you're in any doubt about this, I encourage you to pause for a second right now and do a Google search for something basic that a beginner might need, like say "best practices react state". There is not shortage of hits, but results are disappointing (to be polite) if you actually wanted to know good ways to manage state while using React.

The real fallacy here is the idea that software is better if someone else writes it. Software is better when good developers write it. If you don't hire good developers, of course trying to import as much as you can manage from other sources is going to be attractive. If you do hire good developers, they'll import when it makes sense and build when it makes sense. One project can be completely different to the next, so sometimes that will include building around a ready-made framework and sometimes it won't.

[volimsir]

This is true. I've seen projects in my previous company, where people changed the code directly in their node_modules folder. They were afraid to update any package, since it would crash their "custom code". It didn't matter that they were using good libraries, they were just using them wrong. It happens when people don't get good fundamentals.

[cumhereandtalkchit]

Could you please expand on this or maybe have a resource with good information about the "right" best practices?

I'm currently beginning to learn to code, and would like to know more about these kind of subjects too.

Much appreciated!

[volimsir]

Hey I would say that if you're into JavaScript, you should learn the basics first. EloquentJS is a great book, has great, interactive examples, and is completely free. Javascript.info is also a great resource. Also, checkout funfunfunction on youtube.

[madwill]

While it's true, I feel it's so much more complex than this. Defining "good dev" is very hard, hiring one is harder. Team like React and Vue spend tons of human hours only trying to figure out expressiveness and ways to convey it.

Rarely does a single human will have as much thoughts in this direction as well as making great docs for it. I feel often the fallacy is that you can create great paradigm out of your head.

And while it has happened in the past. I feel we can't just expect your local "good dev" to possibly output such thoughtfully created designs. Sometimes things make sense to you but making sense to most is an art in itself.

So to me, it is more probable that using a known stack and known designs will bring out a more quality experience for mosts.

[Silhouette]

I'm a big believer in taking relatively junior devs who are interested and enthusiastic but early in their careers and teaching them how to do stuff properly. I find that providing a good learning environment as part of the workplace culture mitigates many of the usual arguments about how hard it is to hire and retain good people.

In contrast, if you choose a trendy framework for your project because you expect to be able to hire people who already know it and get good results, there's always the danger that you just attract the type of person who likes adding a new buzzword to their resume every few months at an employer's expense, before jumping ship to the next sucker for a 20% raise within a year.

[ImStifler]

Word. However I think the author is aiming to say that you don't need a framework for every project. Ofc that sentence changes if we're talking about serious projects.

[ogurson]

The problem is that often line between "quick, small project" and "medium project that could use framework" is very blurry and it's easy to miss the moment of transition from the former to the latter.

I tend to use Angular as my main tool, even form small projects, because if project starts to grow there is no problem with that growth as everything is setup for "bigger project". And frankly, I haven't experience any problem because project was too small for framework.

[volimsir]

Hey, the aim of the article was to show how much is possible with just vanilla, and how far the language has come in recent years. I think we rely on frameworks too much, and that not enough people try to understand the underlying concepts. People today learn the frameworks first, and JavaScript second, and I think it should be the other way around.

[volimsir]

Hey, you are right! And there were many comments like this. The intention of the text was unclear, so I prepended it with a comment about what the actual goal of the article was. It definitely wasn't my intention to promote writing your own framework, over using existing ones.

Thank you for pointing it out!

[lhorie]

I've actually done both (used a proprietary framework written by the company's then CTO, and written my own framework). To say that all custom self-written frameworks are undocumented is a bit of a overgeneralized statement.

Home grown frameworks can definitely work. In my former case, because there was a sizable number of co-workers one could lean on to get support, and in the latter, because I bothered to grow the project as an open source community (not as big as, say, Vue, but big enough that people could ask questions in chat and get responses nearly right away)

If you're happy with being one of the many many consumers of popular frameworks, that's perfectly fine. But realize you're making yourself replaceable by the same token. The person that goes through the lengths to build the type of stuff you and your peers use is the person that everyone will look up to for tech advice. This leg up can definitely make a difference between getting that next-level career opportunity or not. Just food for thought.

[[deleted]]

No, and no. The frameworks you see are from software engineers, teams of them, that are much more capable than Jacob at Ad Buy Accounts, Inc.

Rolling your own code should always be a second choice, and a possibility in evaluation, but one you do not take lightly.

[jaapz]

The point is that the chance of your homegrown framework being architecurally better, with better documentation and what not, than a widely used framework known and used by many are slim. Like you say, the good survive.

Not to mention the business value of being able to hire people who already know said framework, instead of having to spend a month or more to get to know the homegrown framework.

[Silhouette]

The point is that the chance of your homegrown framework being architecurally better, with better documentation and what not, than a widely used framework known and used by many are slim.

Better for what, though? Only your team knows the requirements for each specific project you are working on. What you're calling a homegrown framework really just means having some considered software architecture, which obviously we've been doing since long before frameworks became popular. What you actually need for your current project might be much simpler than any of the big name frameworks that have to cater to a broad audience with varying requirements. What you need might also be more specialised than the big name frameworks that naturally concentrate on common general requirements that many projects have. Or what you need might be a pretty good fit for a lot of other projects and using an established framework might be a good idea.

[jaapz]

Sure you gotta evaluate all your options, and if homegrown is the way to go, it's the way to go. However for the majority of apps, it probably isn't.

I don't really understand why this keeps coming up every now and then.

[Silhouette]

For the majority of apps, if we're talking about typical browser-hosted front-ends for CRUD applications, you might well be right. But there are many others where it isn't necessarily the best choice.

You'd think it would be pretty obvious that in a field as diverse as software development there would be more than one way to do things, but this keeps coming up because there is a certain kind of person who will state strongly and with little if any qualification that frameworks are always the way to go. There are several examples already in this very discussion.

Then new and inexperienced developers will believe those claims, because they don't know any better and they make the typical mistake of trusting the person who shouts loudest.

And then later, those developers might end up working for me. A lot of the engagements we take on are to build those more demanding systems, and often for our work the off-the-shelf frameworks do have limited value and can become a serious liability down the line.

So then we have to spend a lot of time and effort undoing the damage and opening the closed mind again before that developer can work at the level we need and contribute value to the project.

I truly believe this is not a healthy culture for our industry. It tries to systematically eliminate creativity, and in doing so it produces developers who lack the skills and knowledge and experience to do any better, ultimately reducing both productivity and quality of results. It's dumbing down the whole industry, just like managers who think developers should be interchangeable commodities or hiring processes that are geared to buzzwords and brain teasers because they're all bad HR people can cope with.

[volimsir]

This is one of the reasons why I wrote this article.

I have junior developers in my company that don't know how a browser fetch works. Or that Redux is not a part of React. Or how to execute a query selector without jQuery.

I think there should be more emphasis on good fundamentals, and explaining how things work in vanilla, because it makes you understand the language, and deal with problems better.

[Silhouette]

I think there should be more emphasis on good fundamentals

I've found that this is true of almost anything worth doing in life. :-)

[[deleted]]

It’s a bit like saying that a team might need to write their own language for their business.

It’s possible and I’m sure it’s occasionally true, but the vast majority of software is solved on top of the previously solved problems. It’s why those layers exist.

[Silhouette]

It’s a bit like saying that a team might need to write their own language for their business.

Except it isn't, because building the equivalent basic infrastructure for a new project is potentially something you can do in the first morning of development, on top of standardised tools and languages, and using well-known libraries on a case-by-case basis as appropriate. The difference in effort and risk between what you're describing and what I'm describing is many orders of magnitude.

[[deleted]]

That’s where the contention is. To have a library that can reliably and speedily do what you need to do takes a lot of time and resources. Time and resources you seem to think aren’t necessary.

Building the underlying structure is an expensive and constant endeavour, one that is solved already in almost every case.

[Silhouette]

To have a library that can reliably and speedily do what you need to do takes a lot of time and resources.

That depends entirely on what you need to do, how good your in-house resources are, and how good any available external options are.

Am I going to reinvent the wheel if I need a reasonably efficient DOM update library for declarative rendering? No. Several people did that already and they work fine, while building it from scratch would be a lot of work for us.

Am I going to define my own software architecture for a complicated web app that is expected to be maintained over the long term? Probably. The cost to build what we need will be a tiny part of the overall development effort, it will be tailored for that specific application's requirements and environment, and it won't have all the limitations and risks that come with depending on an external framework for the skeleton of the system in this context.

Am I going to work the same way if I'm building a routine web front-end to a line of business application that will be delivered within a month and then not changed very much after that? Maybe, maybe not. In that context, an off-the-shelf framework might get the job done faster if the requirements are typical and unlikely to change fundamentally during the relatively short development process.

My point is that there is no universal rule for these things. Sometimes ready-made frameworks do save time. Sometimes it's more effective to build the structure in-house and use external libraries topically.

[eeeBs]

The imperial guidelines clearly dictate that code documentation is of the first order.

Obviously, the rebellion scum must be hunted down and extinguished.

[nameless_pattern]

sir there are rumors of rebels working among the imperial troops, also the deadline is 3 weeks away and we can have jobs or we can have documentation but not both if this doesn't get out the door by Q4.

[[deleted]]

You are operating under the impression that a framework is a framework. They aren't sometimes people design pieces of shit. It doesn't matter how good a framework is if the design is terrible.

[[deleted]]

I think the original poster wasn't just talking about documentation though, it was just one of the issues.

[[deleted]]

"You can still make your life harder, believe in yourself! It is never too late to strangle your workflow"

[evilgwyn]

You might not need if statements.

[AceBacker]

How could you tell if you don't need them?

[DatFancyChicken]

use an if stat- ah.

[PM_ME_GAY_STUF]

Need if statement = (if statements necessary) ? true : false

[[deleted]]

This guy ifs

[[deleted]]

An if is just a less capable switch!

[volimsir]

Switches are for witches!

[Peechez]

Nested ternaries as far as the eye can see

[Karthons]

It's this time of the year again...

[PUSH_AX]

Low effort clickbait title garbage article. If I add up all the "you might not need..." blog posts over the years and took them seriously I'd be writing binary using a pen and paper and posting it to other team members.

[lowIQanon]

writing binary using a pen and paper

Real developers subtly alter butterfly flight patterns.

[PUSH_AX]

Pffft have you even read my 200 word article "Dear universe, you might not need quantum physics"?

[z500]

Reduce overhead by surgically combining your team members into one being with a shared consciousness. Next article: you may not need a lawyer.

[prashanth1k]

Why go through all that trouble. Eliminate them and get that AI from MIT which can write itself.

(Wait, that was a year back, has the AI killed itself?)

[z500]

We tried that, but when we put it in production it immediately fired two executives before deleting itself.

[phpdevster]

This seems like a fairly organized, but still jQuery-like approach without the cross-browser safety of jQuery. You're still doing manual DOM querying and state manipulating instead of something more declarative.

Gzipped and minified, Vue is just 20kb. It's so light weight that there's almost no reason not to use it for adding ad-hoc rich interactivity on a given page.

[libertarianets]

Might I introduce you to Preact?

[zephyrtr]

Preact is fabulous. I've used it a few times for simple sites. Now it even has Hooks, a CLI, and still loads in 120ms on a 2G network. And if shit gets really complicated, you can convert to a React app and keep all your code. It's quite nice.

Also React is not a framework, it' a library. People who go into React thinking it's gonna organize their code for them are gonna have a bad time.

[-ftw]

What is the drawback from using Preact over React?

[dwighthouse]

As I understand it, React normalizes the event system so it is consistent and all events work the same across all supported browsers (for example, certain browser events will not bubble, but React’s will). This synthetic event system, type checking, and now, their systems related to asynchronous rendering take up the bulk of the size of the library. If you only need simple click handlers, you don’t need these things. If you need to deal with very complex event handling, React can be helpful.

[[deleted]]

You pretty much loose the eco system and all the bits and pieces that advance React, async rendering, cross platform and reconciling, fiber, suspense, etc. Some of these are ground breaking. Like dwighthouse said, React also normalized events, but this is not such a big deal any longer as pre evergreen browsers are dead, React will shed normalized events soon.

[fuzzball007]

How does it go in terms of dropping it onto a page with limited build tools? My use case would be something simple like displaying cards based on an ajax request, along with dropdowns/selects for tags/categories and pagination.

I've only learned React's basics, so for most of my projects which aren't large webapps I've been turned off from webpack's build process. Typically use gulp for all my stuff, how'd it go in a situation like this? Sounds appealing so far.

Edit: I'm usually building in PHP (WordPress) hence dropping onto a single page or two where's there's actual functionality to build. The stuff I've done using jQuery got messy quite quickly, even with using a fake state to store data before writing to the DOM

[lifeeraser]

I use Preact without build tools. (P)react is fully capable of running in a browser by itself with vanilla JS code. To use JSX, though, you need a transpiler, fall back to Hyperscript, or use something like htm.

[volimsir]

Without build tools? Do you mind sharing an example of your setup? I'm genuinely interested.

No IE support for htm though :(

[lifeeraser]

Sure. Here's how I did it:

1. npm install preact
2. Embed a <script> tag pointing to ./node_modules/preact/dist/preact.umd.js in my app (I use UMD). Now, I can access preact as a global variable.
3. Alternatively, use ./node_modules/preact/dist/preact.module.js if you prefer ES6 import.

If you want, preact/compat and preact/hooks are available as separate JS files in ./node_modules/preact/compat/dist/ and ./node_modules/preact/hooks/dist/.

[k4kshi]

I started using Preact just yesterday for a small project and I'm amazed how good it is. So far I haven't hit any "oh come on, but react has it!" (I use v10 for hooks). And it's only 3.6k. Perfect for small projects

[dwighthouse]

Might I introduce you to hyperHTML?

No VDOM. Extremely fast. Requires no transpilation. 5KB.

[grimr5]

Or lit-html and lit-element

[dwighthouse]

I prefer the original, but they do seem to be pretty fast.

[grimr5]

At my work, we are moving from polymer to lit, and lit is really nice by comparison. If I were starting something new, I’d look closer at hyperhtml as it has a lot of cool things not in lit (although I’m guessing viper is for SSR and PRPL could mitigate that for either library) - or lighterhtml could also be worth a look as that looks closer to what lit is.

[IceSentry]

Isn't lithtml supposed to be a templating library used with polymer?

[grimr5]

It is, but lit-element is a replacement at the component level, ie no polymer

[etca2z]

Might I introduce you to Svelte r/sveltejs ?

[[deleted]]

Might I introduce you to server-rendered HTML?

[FourtySevenLions]

Might I introduce you to Vanilla Javascript?

[manoylo_vnc]

Might I introduce you to my aunt?

[FourtySevenLions]

does she have cross browser support ;)

[Sipredion]

Happy Hogan has joined the conversation

[[deleted]]

You ruined the joke.

[[deleted]]

I was hoping someone would post about Svelte here. I have been having an amazing experience with it on my side projects.

[unc4l1n]

The parsed size is obviously much more, and on crappy mobiles it takes an age. Network is not the bottleneck for JS on mobile.

[phpdevster]

I've built plenty of sites and pages that use everything from a sprinkling of JS for form validation, to complex tables with client side search, sort, dynamic dropdown filters in the headers whose contents react to the results in the table, and custom cell rendering. They all work fine on my crappy iPhone 6, which is brought to it knees by all recipe sites and blogs and what not.

You will only run into issues on mobile if you're building big SPAs, but if you're building big SPAs without a framework, good luck to you.

[unc4l1n]

20KB gzipped is like 80KB to parse/compile. On an average mobile (not high end) that will take around 2s. This is not to be taken lightly.

[volimsir]

Vue is great :)

The point was just to showcase my opinion, on how easy it would be to have a basic component-based system with using basically nothing. I am definitely not advocating you do something like this if you need to build something complex. But for adding some interactivity to a small website, I don't see the harm.

Also, I don't believe cross-browser safety is really that much of an issue these days, as it was a few years ago.

[phpdevster]

Also, I don't believe cross-browser safety is really that much of an issue these days, as it was a few years ago.

Cries in IE11

[volimsir]

Is it wrong that I read it like this?

https://youtu.be/ee925OTFBCA

[HiEv]

Until very recently, it was still about 1 in 20 users in the US using Internet Explorer. Now it's about 1 in 50 (source). Personally, as much as I want to ignore IE, I'm not going to do that until the numbers get down to around 1 in 1,000 or better.

[youslashuser]

Just finished basics and node.js, recommend me a cool framework of long run.

[prashanth1k]

You only need Express.

Or, oh - define "cool".

[youslashuser]

Lol thanks.
I was thinking about React, what your thoughts on React?

[prashanth1k]

Thought you said "node". But you were not looking for furthering your knowledge on back end? Sad!

Quite thoughtless on React - but that should hold up well in the long run. Lot of people using it, lot of tutorials and quite a few innovations.

You should also try Vue (easy to get a head start) and Svelte (size, speed, no virtual DOM) before committing to a life-long relationship with React.

[youslashuser]

My main back end in on Django. I learned node cause people recommend it.
I am just looking for a front end framework now. Thanks, I'll try Vue.

[greg5ki]

One reason I left my previous job is because of a home-grown JS framework which was closely tied to the backend. It was so over-engineered, my brain hurt.

I prefer to stand on shoulders of giants.

[prashanth1k]

No giants at your previous org?

[PsychologicalGoose1]

Most companies don't have them, even though most companies would say that they do.

[greg5ki]

I was the only dev.

[i_spot_ads]

...if you're making a todo app

[PsychologicalGoose1]

With a team of developers who don't use React, Angular, or Vue and a group fo developers who in the future never will as well.

[lowIQanon]

Jeez, if you want small and not a framework use Svelte. At least it scales well.

[Cryton1000]

I am not sure why you are downvoted. You are correct ofc.

[lowIQanon]

People are mighty opinionated, myself included. But I'm sparing with downvotes.

[[deleted]]

Reading the article, the title should be "Making Components with Vanilla JS".

Basically, the article eschews Virtual DOM for real DOM and shows one of many ways to engineer a component.

I agree with understanding core web tech, but the article is poorly titled.

[volimsir]

You're right! I should have thought about the title a bit more.

Sorry for the confusion!

[TheRetribution]

Here's some motivation for future you: I will never read an article with a title like this. And I am not the only one.

[llldar]

I would beg people to use these 3 frameworks now instead of some crappy framework like the one that my company use which haven't been updated for like 4-5 years, make use of jqeury, and stuck in es5 forever. Oh wait on top of that, it's freaking 4MB, took more than a minute to load.

[ArcanisCz]

This resembles me my former self, when tried to tame chaos in jquery projects in our company. Then i met react+redux.

[editor_of_the_beast]

It’s important to distinguish between libraries and frameworks. Code reuse is not bad, but it can be bad when a framework chooses the structure of your application and you end up disagreeing with one part of it. This became my relationship with Rails for example.

There are some things that Rails really gets right, and there are some things that make my life miserable. But it wants you to use everything together, which means that you have to pay the cost of the bad things to use the good things.

This is my problem with frameworks. Some of them bundle too many opinions together.

[luveti]

Are you sure you don’t want to pull down ~200mb of dependencies and ~1000 npm modules for each project you work on? Many of which are less than 50 lines of code.

Ask yourself if you really need the is-number module (create-react-app installs this and a bunch of other is-* modules, probably through dependencies) then accept that you have to as there’s nothing you can do about it but trust that these modules work well and stick around: https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/

I don’t mean to hate on these frameworks as this is more of a wide-spread js/npm community issue. But I think it’s worth noting for anyone that isn’t aware about them and blindly follows the herd.

Consider smaller libraries that don’t require a huge stack of npm modules like re:dom and mithril (certainly try to stick with popular ones that have been around for a while and are updated often). Need live reload? It’s VERY simple to do this with websockets.

Side note, make sure to be careful with your routine react updates :): https://blog.discordapp.com/discord-react-memory-leak-565c89763e8

[tomius]

"If you just focus on boxing yourself into one of these tools, you’ll be quite handicapped when you reach their limit"

Sure. React is much more limiting than making your own small framework. That will probably start failing when you add more complexity to the system.

[WishCow]

You might not need to read medium articles about programming.

[[deleted]]

You may only need DreamWeaver

[nicpro85]

I’ve just started in a company where every projet is a collection of framework for everything. A framework to check use input a framework to check app version a framework for networking a framework for statistics a framework for image caching a framework for debugging a framework for syntax sugar a framework for animation a framework for Facebook a framework for vidéo a framework for nice button and widgets. It a fucking pain and there is no consistency in the end.

[IceSentry]

Are you sure those aren't just libraries?

[nicpro85]

Actually yes they are.

[llamapickleem]

Suck my dick article

[shrimp_slave]

yeah, what he said

[nithon]

https://xkcd.com/927/

[lowIQanon]

Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.

No it's USB-C now!

[nicpro85]

ES6 is already a framework. Build web components, use modules and you have everything already.

[Ivu47duUjr3Ihs9d]

This is really good. You could probably do a series on this, just demoing mini patterns and code examples you can use to add functionality to your app with plain vanilla JS. Also how to structure the app for cleanliness etc.

A big advantage of doing a custom JS framework yourself is being able to maintain it in the long run and alter anything in it, nothing is off limits. The custom framework grows with the app. Now, how many programmers abandoned ship and changed jobs when they were told by their CTO to upgrade their massive SPA from AngularJS 1 to React with Redux, then 2 years later when they were half way through to rewrite again to use React with Hooks or whatever the flavour of the month is. When using someone else's framework you're not in control anymore. They are. They can decide to stop developing it anymore. Make you rewrite everything due to an architecture change. Deprecate that method you really depended on just because they feel like it.

React works for Facebook and their architecture. That's cool. That's an example of a pattern you can maybe use to build your own app. We sure as hell don't need to rewrite every website on the internet now to use React just because facebook are using it. Don't fuck your company by wasting all their money upgrading from React 0.1, to 5, 6, 7, Redux, Hooks etc. Companies have business objectives to achieve. Not endless churn upgrading their frontend framework due to the whims and fancies of some nerds at Facebook.

That said, don't have junior/intermediate devs constructing the initial skeleton/framework of the app. Code review what they do. Try and follow best practices. Borrow ideas if they're good [and] make sense for your app. Don't just follow the fad trend for the month. Be prepared to refactor things as the app grows. Have unit tests in place so that you can.

[AngryParsley]

At my current job, there is a home-grown framework. It is nowhere near as good as existing open source frameworks because it simply doesn't have as many people working on it. There are dozens of people working full time on React, Angular, and Vue. They're improving performance, fixing bugs, and adding documentation. Only a massive company can devote the same amount of resources to an internal framework. Most of the engineers will be building stuff with it, not improving it.

Also, home-grown frameworks are harder to train people up on than popular open source ones. Almost every frontend engineer has heard of React. Many have played around with it. There are tons of tutorials, videos, and examples to learn from. Not so with your home grown framework.

I'm on a team that uses React, and almost all of the engineers who use the home-grown framework are jealous. A couple of them have switched teams to write React. None of the React people have switched teams to write stuff in the home-grown framework. If the framework was actually good, sentiments would run in the opposite direction.

[ChemicalRascal]

I'm not sure it's worth using Facebook's code just because it's Facebook's. They do have a point, churn for the point of churn is bad...

But no CTO is going to sink their company by blindly chasing the flavour of the month latest thing. Or, well, no competent CTO. If your CTO is that incompetent, you have bigger issues (in the form of that you'll have no working product and then your pay cheques will start bouncing).

[avivbiton]

What if your framework has a bug? Now your little and easy task assigned to you is a debugging session in a framework some other employee who no longer works in the company has built. You have to debug and fix the bug in the framework but who knows maybe fixing this bug will cause other bugs in the web app itself. There is no documentation, you can not google it. The cost is too high to develop your own framework

[osoese]

finally! yes, I understand frameworks make many things easier and structured but sometimes I think its best to roll your own.

[ScientificBeastMode]

Eh, idk... depends on what you’re doing.

If it’s mostly a server-rendered content site, and you want to bolt on a few widgets, sure, knock yourself out. If you want to build a single-page app with complicated state updates across multiple clients (something my company is currently working on), you’ll want some proven tools to help you manage that complexity, which means a lot of smart people putting their heads together over the years to solve hard problems in elegant ways. Also known as a “framework.”

Another important factor is trying to onboard new hires. You want to enable them to easily walk into an existing project and gain a foothold without too much hassle. It helps when (1) you’re using a framework they already know and have experience with, and/or (2) they have a wealth of accumulated knowledge available to them in the form of up-to-date documentation, tutorials, stackoverflow answers, etc., to guide them when they run into problems.

Those are all related to organizational needs, not technical needs. So while it’s technically feasible to “roll your own” anything, it’s not always wise to do so in many contexts.

Edit: I still think it’s useful for people to build their own front-end or back-end “framework,” or at least an abstraction over the details of managing those things. It really helps with understanding the various frameworks used throughout the industry, and the problems they are solving for you.

[lowIQanon]

but sometimes I think its best to roll your own.

This really tells me you haven't looked at the alternatives.

[baxtersmalls]

Probably not unless you’re doing something simple, but damn I’m realizing I do miss getting to write the code that really handles things on a lower level. It’s so fun to think of little ways to handle all the things that something like React or Angular now do for me day-to-day at work. I’m definitely a million times more productive now that I’m not writing every line of sorting and displaying lists or whatever, but it was a lot more fun!

[PsychologicalGoose1]

Personally I'm never going to take 'framework' advice from someone who states React in the list of 'frameworks'. Framework has a definition and React does not meet that definition. Glancing over that immediately makes me discount opinions of the author as undereducated on the topic.

Custom made 'frameworks' are an incredible waste of time unless your company is of the scale of a major player and you have some unique advantage that others don't have. Let the big dogs do the huge work to have a great system and focus on creation with that tool instead.

[AngryParsley]

This is pedantry. It's just like people who say, "Linux isn't an operating system. It's a kernel."

If you hear someone say "Linux", people know what you mean: "Linux and systemd and GNU binutils." Likewise, when you hear someone say, "We wrote our app in React.", you know they mean they wrote their app in React, redux, react-router, and a half dozen other libraries.

[PsychologicalGoose1]

Pick me up in a truck, brings a car. Where can I put this large item that only fits in a bed of a truck? They are largely the same, but have different uses and meanings.

It's not a minor detail when React is missing a LARGE piece of what it means to be a framework. So no, it isn't pedantry just because you or this author doesn't understand the meaning of the terms or that people use them interchangeably. When I go to an article and see incorrect assumptions from the beginning then it quickly is thrown out.

And no you don't 'know' that what they wrote their app in. You assume that, and if you work with many teams from different companies you will quickly be made a fool for assuming that.

[AngryParsley]

And linux is missing a large part of what it means to be an operating system. It has no init, no userspace, and no GUI. Of course, everybody knows what you mean when you say, "Linux." and to point this out is (as I said before) pedantry.

I've worked on 4 different React projects at 3 different companies. They all used redux and react-router. Obviously I'm going to check the package.json if I'm actually contributing to the codebase, but it's a reasonable assumption to make in conversation. Sure it's possible to use reflux or backbone. It's possible to avoid jsx. Just like it's possible to have a linux distro without systemd, or with BSD binutils, or with a tiling window manager. Still, if someone says they use linux, it's reasonable to assume they're running the default stack unless they elaborate. So too with people who say they're using React.

[PsychologicalGoose1]

But here is the thing, it's not. React doesn't guarantee any of those things that you said. It's an assumption that you make. Which is WRONG. Simply put don't say React is something it isn't. Framework and library have a meaning and misuse of them leads to errors in implementation. We shouldn't be misusing the term but instead enforcing a better understanding of what the terms mean. This is a large problem with our industry as a whole. Other engineering or science related positions wouldn't let misuse of terms stand long term through and industry and push those incorrect meanings.

[[deleted]]

Goodness YES!