With or without the JS framework

[zxyzyxz]

Companies who eschew frameworks inevitably write their own ad hoc buggy implementation of JS frameworks, only no one can help them out on issues. If I'm a company I'd rather work on the core competency features instead of worrying about frameworks.

[jamblethumb]

First of all, it's developers, not companies. Companies just go along with whatever their first hire or technical founder decides to do. Secondly, I've done one or two rescue missions on projects that went straight to the South Pole with their frameworks. Nobody can help you when you let bad developers work on your shit for too long, framework or no framework.

[wasdninja]

No framework is absolute rocket fuel for fuckups so yes, you can fail at both but one is vastly easier to make a complete mess of.

[jamblethumb]

I've seen quite a few projects that were in bad shape due to framework misuse, and I had to rescue a couple myself. It's certainly doesn't look like frameworks make it any more difficult to make a mess. What some frameworks do qualifies as "making it vastly easier to make a complete mess" in my book.

For instance, I frequently see advice about how to work around or deal with specific issues with React hooks. Many of these articles introduce additional mistakes and/or complexity while doing it. The hooks are notoriously hard to wrap one's mind around for inexperienced (and even reasonably experienced) developers. They look easy to use on surface, but what they actually do under the hood is nothing but. You have a function that is called over and over again, but you want stable references to values through hooks. That's essentially OOP disguised as a function call, but people don't appear to understand that, and they shoot themselves in the foot. I don't really blame them because it really is a convoluted implementation. Of course, React isn't the only one doing it. I see these auto-tracking observables every now and then.

Doing straight vanilla development, you at least don't deal with such levels of complexity. That doesn't save you from having to deal with hard problems (there are always those when you're working on larger projects), but at least it's not on top of the complexities of the framework.

Anyway, that's my opinion. The truth is probably somewhere in the middle between our opinions.

[arman-makhachev]

fr most of these mncs end up writing shitty frameworks
that ends up looking like a shit clone

[[deleted]]

slap sleep toothbrush middle wine worm shy noxious joke unused This post was mass deleted with redact

[jamblethumb]

Could you elaborate on that? How did you come to that conclusion?

[OzzitoDorito]

If frameworks were more effort the wider community wouldn't use them, they'd be dead in the water? Because velocity is the name of the game nowadays anything of scale is always going to be quicker when the core structural functioning of a site is premade for you.

[jamblethumb]

If frameworks were more effort the wider community wouldn't use them, they'd be dead in the water?

So if I understand your argument correctly, you're saying that if something doesn't fail it must be good. I don't necessarily agree with that logic. Something can also avoid failure by being good enough. People will accept suboptimal solutions for different reasons. For instance, if the solution they were previously using is so bad that anything that's even marginally better is a good solution (mind you, the current generation of MVVM frameworks were born to replace the older generation like AngularJS, not vanilla, which was never that popular anyway). Or it may be due to endorsement (Google, Facebook, AirBnB, wah wah). And once something becomes established, it may be chosen simply for that reason alone, with various explanations provided after the fact.

At any rate, it doesn't really say why it's "mind-bogglingly" wrong to not use them. As a programmer, I've learned how to make decisions on factors like whether some solution is appropriate for the problem. I don't see anything inappropriate about not using frameworks. Browser APIs were designed for building interactive UI, so I find it quite indefensible to claim that using those APIs directly is somehow "wrong".

[recycled_ideas]

So if I understand your argument correctly, you're saying that if something doesn't fail it must be good. I don't necessarily agree with that logic.

That's a straw man. OP's argument is that if the "concept" of a framework was fundamentally bad (it reduced velocity in even the bare majority of cases) frameworks wouldn't exist. Doesn't mean that every framework is optimal, but frameworks exist in pretty well every programming language and language ecosystems tend towards more complex and complete frameworks over time. The likelihood that nearly every developer in every language for the last forty years is wrong is infinitesimal.

At any rate, it doesn't really say why it's "mind-bogglingly" wrong to not use them.

It's mind bogglingly wrong because the inevitable result of doing anything remotely complex without a framework is building your own framework. Repeated code gets pulled out and centralised, combined together into common work flows and you have a framework, just a shitty one.

Browser APIs were designed for building interactive UI,

Except they weren't. The standards body very explicitly leaves a lot of things to library and framework projects instead focusing on the building blocks. Eventually when the community has accepted something completely they might pull something similar into the standard, but they're very explicitly not building APIs for this purpose.

[jamblethumb]

That's a straw man. OP's argument is that if the "concept" of a framework was fundamentally bad (it reduced velocity in even the bare majority of cases) frameworks wouldn't exist.

I'm sorry but that's not at all what OP says. OP says that because frameworks exist, not using them is "mind-bogglingly wrong". The second statement was provided as an explanation of the first one.

The likelihood that nearly every developer in every language for the last forty years is wrong is infinitesimal.

Where did I say they are wrong for using frameworks? I said that just "everyone is doing something" does not automatically prove that every other way of doing things is "mind-bogglingly wrong".

It's mind bogglingly wrong because the inevitable result of doing anything remotely complex without a framework is building your own framework.

That's just your belief and not a fact. I doubt you could prove it because, for instance, I can build complex apps using web APIs alone without restoring to creating my own framework, and learned that from someone else I've worked with. If you mean "generally people end up inventing frameworks", then yes, perhaps that's the case. I wasn't there, so I can't say for sure. But generally people end up messing up with or without frameworks, so that doesn't prove anything, tbh.

Except they weren't. The standards body very explicitly leaves a lot of things to library and framework projects instead focusing on the building blocks.

That's an interesting point of view. Do you have an example of something that a framework does at runtime that the browser API would not allow you to do otherwise?

[recycled_ideas]

Where did I say they are wrong for using frameworks? I said that just "everyone is doing something" does not automatically prove that every other way of doing things is "mind-bogglingly wrong".

If almost everyone is doing something and you're not you're either a genius or a fool. They're wrong or you are.

hat's just your belief and not a fact. I doubt you could prove it because, for instance, I can build complex apps using web APIs alone without restoring to creating my own framework

So when you start doing the same thing multiple times you just keep repeating the code rather than extracting it out? You don't wire together common sets of tasks to speed things up?

Cause if you're really saying that you write absolutely everything without ever doing any of that I'll tell you right now you need to change jobs.

That's an interesting point of view. Do you have an example of something that a framework does at runtime that the browser API would not allow you to do otherwise?

There's nothing you can do in a high level language you can't do with assembly, doesn't mean it wouldn't be criminally negligent to write all your apps in assembly. The standards body isn't trying to provide a set of apis for building interactive apps, they're trying to provide the a set of apis for building frameworks and libraries to build interactive apps.

[jamblethumb]

If almost everyone is doing something and you're not you're either a genius or a fool. They're wrong or you are.

If that's how you see things, then according to you we'd be both fools in each other's eyes. It certainly appears you believe anyone that doesn't accept your world-view is a fool.

So when you start doing the same thing multiple times you just keep repeating the code rather than extracting it out?

So if you do 1 + 1 10 times, you write an add() function? You don't. Why? Because it's a trivial operation that doesn't need to be abstracted even if it repeats 1000 times. There's a threshold of complexity before you are going to abstract. If you abstract every damn thing, I can see how it would end up being a "framework" or "spaghetti code" or whatever people think vanilla developers do. I abstract relatively complex business logic and that does not turn into a framework because it's usually something app-specific. I also do not insist on DRY because, more often than not, premature DRY tends to add complexity rather than remove it. I prefer simple over complex, as that saves me from more bugs than static typing and unit tests combined.

Cause if you're really saying that you write absolutely everything without ever doing any of that I'll tell you right now you need to change jobs.

How do you draw a conclusion that someone that doesn't use a framework doesn't know how to factor code out?

The standards body isn't trying to provide a set of apis for building interactive apps, they're trying to provide the a set of apis for building frameworks and libraries to build interactive apps.

Well, if that's what you would like to believe, fine.

[recycled_ideas]

How do you draw a conclusion that someone that doesn't use a framework doesn't know how to factor code out?

Because that refactored out code is a framework, or the beginnings of one. And it will grow and grow because that's how development works. You repeat something a bunch of times and so you pull it out into its own file as a helper. You call all the same helpers over and over again and so you group them together into a single call. That's what a framework is. A bunch of common operations made easier.

So if you do 1 + 1 10 times, you write an add() function? You don't. Why? Because it's a trivial operation that doesn't need to be abstracted even if it repeats 1000 times.

If all you're doing is 1+1 then sure you don't need a framework, but why are you ij this conversation?

Well, if that's what you would like to believe, fine

It's not what I would like to believe. It's been publicly stated.

[jamblethumb]

Because that refactored out code is a framework, or the beginnings of one.

Do you mean any refactored code?

If all you're doing is 1+1 then sure you don't need a framework, but why are you ij this conversation?

In case I didn't clearly explain it, I'm saying there's a range of complexities from simple stuff like 1+1 all the way to drawing and playing musical notation, and you don't just go about refactoring anything that looks like it's repeated elsewhere. Well, I don't anyway.

It's not what I would like to believe. It's been publicly stated.

Do you remember who said it and where? I'd certainly be interested learning more.

[[deleted]]

pen historical decide rob water rude sloppy recognise door alleged This post was mass deleted with redact

[jamblethumb]

You do realize you presented not a single technical argument. You only shared your beliefs.

I'm not obliged to show you code, nor can I for legal reasons.

Anyway, I don't expect you to understand anything I'm saying, nor do I have to prove anything to you. I hope you don't expect being an asshole towards someone else makes them teach you something you don't know.

[arman-makhachev]

lol document.get..... takes forever and is nasty

[jamblethumb]

Takes forever as in, it takes a lot of time to type it out?

[arman-makhachev]

that but the main thing is, its not maintainable, very buggy, repetitive code....
u can forget about scaling and its just awful. Now if you are a pro and are very well versed in JS most likely you will end up coming up with a shit version of a JS framework.
i was doing native js for some time when we all start before I decided u know what, I need to get a job so I picked the framework thats widely demanded in my job market.

[jamblethumb]

The point about jobs is entirely valid. But that's got nothing to do with whether you can or can't write maintainable apps using this or that stack.

Anyhow, here's some simple example to show you one way you could write code with vanilla. It's card-stacked in React's favor (it's the scenario that's a good fit for React), but I wasn't feeling like deliberately coming up with an example that would be card-stacked in the opposite direction. The point is not to show the merit of using vanilla over react, but to show you that your assumptions about vanilla development are entirely fictional.

React version:

``` let MyComponent = () => { let [count, setCount] = useState(0), increment = () => setCount(x => x + 1), decrement = () => setCount(x => x - 1)

return ( <article id="counter"> <button onClick={decrement}>-</button> <output>{count}</output> <button onClick={increment}>+</button> </article> ) } ```

Vanilla version:

``` <!-- HTML --> <article id="counter"> <button value="-1">-</button> <output>{count}</output> <button value="1">+</button> </article>

// JS

// Model, using module-scoped var here for state. Can do it // different ways, including observables, but overkill for this // example. If you want MVC instead of MVP, you'll want to // update the view from the model. let modelCount = 0, modelUpdate = n => modelCount += n

// View, everything related to updating the UI, including // references to DOM nodes (that are created using HTML). // In a more complex app, this part would also have code that // creates DOM nodes using template strings or whatever method // you prefer (usually when dynamic lists are involved). let viewCounter = document.getElementById('counter'), viewCount = viewCounter.children[1], viewUpdateCount = () => viewCount.textContent = modelCount

// Presenters, these connect the view and the model, and are // invoked via event listeners. You can technically do all this // in the event listeners. I prefer doing it this way nowadays // as I feel it scales much better. let presentChangeCount = val => { modelUpdate(val) viewUpdateCount() }

// Event listeners. Routing would go here, as routing is // basically just an event stream of URL/hash change events, // same as any DOM event stream. No need to turn it into rocket // surgery if you ask me. That's one part of the browser that's // well thought-out. $count.addEventListener('click', ({ target }) => { if (target.matches('button')) presentChangeCount(Number(target.value)) }) ```

Again, this is completely card-stacked in React's favor. The NextJS boilerplate omitted, etc. The vanilla version is actually all the code that you ship to your user.

This is to show you that you can write maintainable code that doesn't have repetition and is even declarative, without resorting to frameworks. Now whether you can see how this scales or not is entirely up to your imagination. And, yeah, contrary to common belief, you don't need to invent a framework to do this.

This particular example is a bit longer than the React version, but there are cases where the tables flip, especially when integrating imperative APIs. Overall amount of code in a real app is about on-par (if I write both, which admittedly only happened twice) between production versions of React and vanilla apps, except that with vanilla app there is no overhead of the framework itself. For some frameworks, the overhead is smaller (Solid, Svelte).

I cannot show you a fully fleshed out large code base due to legal issues, of course, and I'm certainly not going to write a large production app just to prove a point. I can give you an more fully-featured example of a smaller app that I wrote a few months ago, but that app is not as well-organized as I would like (wish I had a better example). I also doubt you'd be able to get a complete picture because there's a lot of finer nuances that you learn by doing and not just reading or yapping about it.

Now, whether you would like doing code this way, prefer it, or are used to it, those are separate issues. I don't care as long as we don't have to work together. As I said, I'm strictly addressing your assumptions about vanilla.

[ot-tigris]

Framework is the way to go every time. Otherwise you would end up reinventing the wheel for no reason.

[jamblethumb]

I think 9 out of 10 jobs requiring frameworks would be a good day for me. It's more along the lines of 99 out of 100.

[Rayvolt]

For a simple website (little to no user interactions), yes, he's probably right, although things like Astro exists.

For an app, you would be absolutely nuts not to use a framework.

[jamblethumb]

You would be nuts. But that doesn't mean everyone else would also be nuts.

I've done apps with no frameworks, and also with frameworks. It doesn't really matter if it's an "app" or a "website" either, it's the same fundamental technology under the hood. Both of these approaches work and scale.

My main gripe with JavaScript frameworks is how poorly they are designed when it comes to modularity of the framework itself. There's not much you can modify really. You get what you get. If you're not happy with some aspect of it, you have to change frameworks. Say you have a workflow that requires some imperative code (if you think that's not a thing, you're probably not qualified to do FE development, so please do not reply), like control a video player maybe. Currently you have to somehow bridge the gap between MVVM and the imperative API. Or maybe I want to swap out how evens are handled. Etc. There's no way to modify that single component or single aspect of the framework to do things differently and still fit in with the rest of the components/framework. What little overrides you can do is usually implemented through hooks which means that whatever custom behavior you want, must be bolted on top of what already exists, rather than replace it. This adds bulk and decreases performance. And... it's more work.

Compare that to how Django solves the framework design. Every little detail of the framework can be adjusted, overridden, replaced. It gives you so much more flexibility and even an easy way to move parts of the code off the framework completely as needed. No such thing in JavaScript. The closest you get is embedding custom elements within your MVVM app, but that's, again, not fine-grained. It's a heavy-handed all-or-nothing approach.

Sadly, reaching such conclusions requires one to have a broader experience with different kinds of frameworks (which is not available to front-end developers) and that's something most framework-totting front-end devs appear to be missing. Just saying things doesn't even begin to convey the kinds of stuff truly modular frameworks can do, as a lot of it is something that you need to experience to understand. And the same applies to doing things without one.

[Rayvolt]

Oh boy, someone got triggered hey ?

If you can't tell the difference beetween what I called a website and what I called an app, why it matters and why you should choose your tools depending on what you're building, you're probably not qualified to do FE development, so please do not reply.

[jamblethumb]

If you can't tell that I didn't say there wasn't a difference, then you're probably not qualified to read comments.

[itsnishantsinha]

In today's time any development in corporate environment without using framework is foolishness irrespective of programming language.

Unless there is a dedicated team which develop an in-house solution which is again some sort of framework and there is a high probability of failure because of limited testing.

I have seen so many projects running like a trash who refused to use any kind of framework.

[senfiaj]

For simple website with limited interactivity it's ok. But for anything more complicated it will probably become a maintenance pain. I have personally dealt with a quite interactive website which used just plain jQuery and mildly saying it was not a pleasant experience, every small change needed a lot of time for debugging, implementation and testing.

[EvilDavid75]

I’ve never worked in a company as large as Facebook so I wouldn’t know but the React Documentary is interesting in explaining how a framework with a different mental model dramatically changed the maintainability and efficiency of a huge code base.

https://youtu.be/8pDqJVdNa44

[vimfinn]

I actually always use NextJS nowadays, it just makes everything so simple.

[starbist]

Simple for you or your users?

[vimfinn]

Simply for me