loading...

A discussion regarding pure JS apps

renannobile profile image Renan Lourençoni Nobile ・1 min read

Recently, the necessity to build a portal for my team to share the current projects and their progress came into the picture, so I tought that this time I could ditch the frameworks and go with the majestic pureness of Javascript.

On the same theme, David wrote the article 'Why you shouldn't use a web framework' a while back:

Now, I understand the principle behind the article, and I find it very interesting, so, when talking about JS apps (React, Angular and everything else-like), what are the advantages and disadvantages of writting an app without a framework and would you recommend that/can you give any resources that represent a real world app (not just an issue tracker or todo app)?

Thank you all.

Discussion

pic
Editor guide
Collapse
ben profile image
Ben Halpern

dev.to was vanilla JS on the frontend for most of its history until recently and still doesn't use a "framework" per se, but we do now use Preact for writing new UIs.

I'm not sure I'd skip the framework if you're really looking to be productive. I went vanilla as a forcing function to keep the frontend logic simple and basic while the project's direction, and for the major performance benefits of just not including more code.

If it is indeed simply an internal portal, it is possible that you don't need stateful complicated UIs in the first place and it definitely could make sense to simplify like that.

As things have grown, the original vanilla code is probably the worst part of the codebase, and that is probably tough to avoid.

Collapse
alephnaught2tog profile image
M. Shemayev

The project I am on right now is currently all vanilla JS for the front end. Which is really nice in its own way for a lot of things -- and there is a chunk of it that has a decent amount of UI, which is growing, and holy shit I forgot what a big pain in the ass it is to do that kind of thing involving stateful UI stuff in pure JS without something like React. I think frameworks are often jumped to too soon or relied on too much -- ie, very few things can or should be done purely in React as all one big thing, IMHO -- but hoooo boy.

Collapse
ben profile image
Ben Halpern

Stimulus is a project in the Rails community which is an attempt to meet in the same middle. I buy it as a pretty decent option in a lot of conventional cases, but haven’t given it a spin yet.

Collapse
renannobile profile image
Renan Lourençoni Nobile Author

Thank you Ben, maybe I`ll go with Preact too, I believe we'll have a very basic state (maybe no state at all, things are being defined yet).

But since Dev.to is using it, I'll definetely give it a go.

Thanks again.

Collapse
ben profile image
Ben Halpern

Since it’s an internal tool I’d probably go with React over Preact. Preact is basically a lightweight implementation of the React API, which is great for high-traffic sites, but not all that important for an internal dashboard. It would be fine but probably just easier to go with the mainstream thing.

But I’d definitely be an advocate for using plain React without a state management system like Redux. IMO this is where simple problems get complicated.

For your needs, you’re probably good with whatever you pick. Just be cautious about over-designing and over-tooling and you’ll be good. Plain ole React really is quite simple, so makes for a good choice.

Collapse
shoupn profile image
Nick Shoup

I would look at it in this way. A framework is just that. It's good for somethings like managing state, or routing, and templating, etc. But if you don't need most of that, then you'll really be fine sticking with vanilla. In fact, if you need only one thing out of most of what a framework offers, I'd stick with vanilla. But that's just my two cents. There's lots of great front-end frameworks out there, and you'll probably get a different response from most devs, depending on their experience.

I love Angular, but do I think it's necessary for all front-end? No. In many cases it's more than what's needed.

Collapse
krofdrakula profile image
Klemen Slavič

I don't know of open source apps that I can point to that would implement something like Clean Architecture, but I would wholeheartedly recommend Uncle Bob's approach to frameworks: don't.

At least, not in the way that framework authors recommend using it. In his words, using a framework and accepting its idiomatic contract means you also sign up to being completely bound to it. You're married to it, and a divorce can be costly.

The way he recommends approaching the problem is to have a layered approach where you treat everything that doesn't deal with your business rules as a plugin to your business rules and entities.

Say you're writing an accountint app. Why would you put your business rules into Models, which inherit ActiveRecord, which in turn implements some SQL that indirectly limits what kinds of interactions your objects can perform?

To him, the database is just a plugin, a detail. The web (HTML, JS, CSS, HTTP, etc.) is a detail. If the code that uses the framework depends on your business rules by importing from a gem, npm, jar, dll or whatever package mechanism you use, you will never be dependent on a particular framework.

Sure, building a REST server or choosing React as your view library is fine, but don't extend those objects with your logic. Create objects within the framework that depend on your logic! If you ever need to switch from Rails to Next, ASP.NET MVC or Spring, it's just a matter of binding a different frontend to the same logic.

Collapse
quii profile image
Chris James

I think you're asking the wrong questions.

David isn't saying never use frameworks, he's saying use them when you need them

So how do you know?

what are the advantages and disadvantages of writting an app without a framework

David goes in more depth but:

  • Dont have to learn someone else's view of how your code should be structured
  • You dont need to buy any books
  • You'll probably have less JS to send to your clients
  • You probably dont need everything the framework is giving you

and would you recommend that/can you give any resources that represent a real world app

Think about your requirements and whether that needs a framework to do what it's doing.

Recently, the necessity to build a portal for my team to share the current projects and their progress came into the picture,

For an MVP of this I wouldn't even think about writing any Javascript

You asked for an example.

Here is my website, it lists posts and displays them. It was so easy to write, definitely easier than anything you'd write in react

100% zero JS. Yeah sure it's a "simple blog". But a lot of websites, when you boil them down a big, are simple blogs really.

  1. Get some text from somewhere according to some kinda key / query
  2. Stick it on a page as text

If you really need some client-side rich behaviour, then by all means a framework may serve you well. Just make sure that's what you actually need.

Collapse
ben profile image
Ben Halpern

I think Preact is a pretty safe bet. It’s a 3kb lib based on the most popular JS view API and interchangeable with other things.

One library to help write views is not creating the situation you’re describing. I’ve been involved in projects where all the things went down like you’re describing, but this is not one of them.

Collapse
danieljsummers profile image
Daniel J. Summers

One of the cool things about this site is that, even when it wasn't open source, the developers discussed their thoughts behind things. Ben posted a discussion thread giving the reasons they were considering Preact, and soliciting feedback on the experience.

In my experience, the main point of the "don't use frameworks" posts also includes "...until you realize you need it." :)

Collapse
niorad profile image
Antonio Radovcic

Pro: You get to write everything from scratch
Con: You have to write everything from scratch