DEV Community 👩‍💻👨‍💻

Kaleb McKinney
Kaleb McKinney

Posted on

JavaScript Frameworks: My Thoughts

JavaScript frameworks are all the rage these days, but an increasing number of developers, including myself, aren't so fond of them.

Why?

For me, it's because they add so much complexity for what I see as a minimal gain. Frameworks like React and Angular allow you to create reusable components in your web project, but at the same time, completely take over your front-end. This might not necessarily be a bad thing, it could be a good thing if that's the way you like to develop, but for me, I don't like it.

I'm not opposed to the idea of reusable components, I just think they should fit in to your project, not define it. This is where framework-agnostic web components come in. They can be used with any framework, or none at all.

In my opinion, that's the way it should be. I use a tool like Lit-Element to make web components that work regardless of what other tools I decide to use or not use.

That seems like a "dream situation" to me. I can still leverage web components while not having to use a full-featured framework if I don't want to. And if you feel differently about it, write your thoughts in the comments if you feel inclined, I'd like to see what you have to say!

Top comments (16)

Collapse
 
ghost profile image
Ghost

I'm no expert in the frontend side but from the outside looks like they are overused; Angular was made by Google and React by FB, probably designed for their needs, with their priorities.

So webdevs started to learn them to look for a job in big companies and endup using them everywhere, no matter how small the project is. For a big company, the problem usually is to keep the internal chaos at bay while in small ones the challenge is to keep moving and being flexible; so fo a big company, being locked-in is a small price to pay for homogeneous codebase and cheap/exchangeable workforce; not so much for a smaller one.

But that's just my view from the outside...

Collapse
 
oenonono profile image
Junk

You've nailed it.

Sincerely,
A web frontend designer and developer of nearly 20 years.

Collapse
 
ghost profile image
Ghost

thanks, is good to have some confirmation to my suspicion.

Collapse
 
markohologram profile image
Marko A • Edited on

To be honest, if you are doing some small project you don't need them. Working on larger projects, frameworks provide a lot of value. Even if you aren't using them, you are surely going to write your own in house kind of "framework". If you don't and you are constantly reinventing the wheel on every ptoject then I feel you are doing something wrong.

Or if you work in a company that has its own product and doesn't do work for others, you will definitely still benefit from a framework even if it's your own in house framework.

Collapse
 
juancarlospaco profile image
Juan Carlos

I feel the same as you, I think Compiler is the way to go, like Svelte or Nim.

Collapse
 
hkgx profile image
Hubert

nim? how are you supposed to use it in webdev?

Collapse
 
juancarlospaco profile image
Juan Carlos

Nim compiles to JavaScript and WebAssembly for Frontend, kinda like Svelte.

Nim compiles to C for Backend, kinda like Rust but with Python syntax.
:)

Thread Thread
 
hkgx profile image
Hubert

yeah, but I think that Nim is a bit too low level for such things.
also: does rust compile to c? thought that it's totally standalone.

Thread Thread
 
juancarlospaco profile image
Juan Carlos • Edited on

Nim is quite the opposite is very high level,
Types are better than TypeScript types,
code is easy to read like old CoffeeScript,
code is high level usually takes less lines of code than Python,
Nim Metaprogramming can help make stuff really friendly at high level while keeping it efficient at low level and very expressive to write.

Nim Backend Hello World:

routes:
  get "/":
    resp h3"Hello World" # <h3>Hello World</h3>

Nim Frontend Hello World:

setRenderer (proc (): VNode = buildHtml(tdiv): text"Hello World") # <div>Hello World</div>

Rust compiles to LLVM IR. LLVM IR is from another different project.

Collapse
 
awakeel profile image
Abdul wakeel • Edited on

Well, I will agree with you on frequent updates and noSQL. No SqL is such a bad idea for small startup with high paid developers. I will rather go with pstgress or any relational database.

Though between react and angular. React can be use as reusable components to plug and play anywhere. But angular is full framework and can't be used for reusable components only..

Collapse
 
oenonono profile image
Junk

Anywhere you ignore the huge size of it as a library dependency.

Today's frontend developers seem to think web frontends can be treated like backends. This delusion is one of several things killing the web.

Collapse
 
gpapadopoulos profile image
George Papadopoulos

Would you like to give us a little background info on the tool you mentioned, LitElement? Thnx

Collapse
 
mckkaleb profile image
Kaleb McKinney

Sure.
LitElement is a base class that allows you to create web components that work everywhere using the shadow DOM. An example (from their website):

@customElement('simple-greeting')
export class SimpleGreeting extends LitElement {
  @property() name = 'World';

  render() {
    return html`<p>Hello, ${this.name}!</p>`;
  }
}

Collapse
 
gpapadopoulos profile image
George Papadopoulos

Thanx mate. Happy New Year2U & your family😊

Collapse
 
dance2die profile image
Sung M. Kim

What would you think is the reason Web components aren't as popular as React, Vue, or Angular and how can WC can be used widely as those libraries?

Collapse
 
markohologram profile image
Marko A

They are still weak in features compared to these libraries. Browser support is also still an issue. I know people like to argue that IE11 shouldn't be used and I agree, but real world scenarios might require you to support it and unfortunately it doesn't support WC.

Create an Account!
Now it's your turn!
 
🗒 Share a tutorial
🤔 Reflect on your coding journey
❓ Ask a question

Create an account to join hundreds of thousands of DEV members on their journey.