
Do You Really Need a JavaScript Framework? - MattBearman
https://www.bugmuncher.com/blog/do-you-really-need-a-javascript-framework/#.Wagv52fpHFc.hackernews
======
payne92
TL;DR OP chose Ember for a small project, found himself [1] "fighting with
Ember a lot", and felt that it would have been easier/quicker to build just a
Rails CRUD app in the first place.

This is a standard challenge with any framework, but the issue is especially
acute in Javascript-land.

Many JS libraries and frameworks exist to cover missing libraries and
functions that would be "batteries included" in other languages. As core JS
has evolved (along with CSS), the value of those frameworks decreases, but
their legacy is deeply present in Github, StackOverflow discussions, and other
libraries.

JQuery is one example: a minuscule wrapper around document.querySelectorAll()
plus ES6 arrow functions gets you 75% of the way there, without having to
understand how/where JQuery is being "clever" in various event handling corner
cases.

Bootstrap is another: flexbox is not perfect, but it replaces a lot of CSS
cruft and JS hackery.

Moral: above and beyond the usual tradeoffs for framework decisions, make sure
the framework/library is still as relevant _today_ as it was N years ago.
Don't just go with inertia.

[1] The author's name is "Matt".

~~~
mschuster91
> Don't just go with inertia.

Well. Inertia is powerful: A new project I start in jQuery today? Next to 100%
chance I can pick up a dev who has seen jQuery, even in three or four years.
Worldwide.

A new project I start in AngularJS or whatever is the current fad? Good luck
if the framework hasn't done yet another BC break or hasn't vanished into
oblivion by then.

~~~
jrs95
At this point, I think React seems popular and stable enough that there's not
much of a point in going with jQuery for the sake of stability/popularity. And
there's still a huge pool of people with AngularJS 1.x experience, too. What's
more important, in my opinion, is what tools are going to be easiest for you
and/or your current team to get stuff done.

------
LyndsySimon
Reducing complexity in general, especially for new and small projects, is very
good advice.

For the past several years I've started new personal projects with
PostgreSQL+Python+[Flask|Django] on the backend and Bootstrap+Knockout on the
frontend. I recently tried to start a new project with React instead, and
while the actual act of development on a working React-based codebase is
fairly nice, getting it to that state apparently requires a load of
dependencies that I simply wasn't prepared for.

I retreated back to using Bootstrap alone for the prototype and found it much
easier to work with than I remember. I'm sure part of that is that I've gained
a ton of experience since I last used jQuery without a UX framework like
Knockout, Ember, or React - but part of it also seems to be that browsers have
come a _long_ way since then.

In fact, I'm considering eschewing all front-end dependencies for my next
prototype - ES6 has far better support in modern browsers than I recall, as do
the more recent CSS capabilities like flexbox.

I figure that at best I'll have a lightweight, clean project that works well
enough for a prototype; at worst I'll learn a lot about where modern web
standards are.

~~~
aphextron
>In fact, I'm considering eschewing all front-end dependencies for my next
prototype - ES6 has far better support in modern browsers than I recall, as do
the more recent CSS capabilities like flexbox.

I think this is a good idea for personal projects and solo developers. But
I've found that as soon as you bring other people on board, you end up
spending more time explaining design decisions and dealing with unforeseen
complexities related to scale than building features. It's really tempting to
go without a framework for sake of simplicity, but you tend to hit a brick
wall in productivity until eventually just reinventing the wheel and rolling
your own "framework" which can end up an undocumented bespoke nightmare if you
aren't _extremely_ careful. I wouldn't equate reducing dependencies with
reducing complexity. Good abstractions are what programming is all about.

~~~
graphememes
You get that with Javascript frameworks anyway.

React - Component Design, Folder Structure, CSS Implementation, Data
structuring, Testing Frameworks, Linting Frameworks, GraphQL vs Traditional
REST vs GRPC...

It doesn't solve all of your problems like you think it would. You still have
onboarding, and you'll always need onboarding.

~~~
swsieber
And since JS frameworks tend to be moving so fast, you'll _always_ need
onboarding... even with current devs.

------
5trokerac3
Does the author have any experience with anything but Ember? How interactive
are their interfaces? How does the person responsible for UX feel about only
using server-side rendering? Did he/she just do a crappy frontend
implementation and is now falling back to a fixed mindset rationalization?

~~~
MattBearman
I feel like I answered most of these questions on the post, but anyway:

1 - I've tried a number of frameworks, although ember is the only one I've
used extensively. As I said, the issue was mostly with the thick client / thin
backend api set up rather than specific ember stuff, with the exception of
ember being overly opinionated.

2 - not interactive enough to require a js framework

3 - BugMuncher is just me, so I'm also the UX guy and I think server side
rendering is awesome

4 - no (in my own humble opinion)

~~~
tmikaeld
Just wanted to ask about 3:

Why is server-side rendering awesome?

I've only found that:

1\. It consumes a lot of server CPU that's of limited capacity

2\. It's often slower than rendering on the client (Since the client usually
isn't under load)

3\. You loose interactivity in the browser because you have to reload the
whole DOM on every new page

~~~
SomeHacker44
He said he was using Rails. Rails has the ability not to do #3. Google
"Turbolinks".

~~~
tmikaeld
Since I've never used Rails, I've never heard of it before.

Have to say, that's quite impressive :)

------
sumoboy
Sounds a bit like crying to me. You built something using a framework and it
didn't workout, "so what", rebuild it again. What's next, another blog post
about why Rails wasn't right either because of scaling issues? There is no
write once and live forever model. Build what you need today, learn, and if
you have to rewrite it 10 times then do it.

Frameworks save people time. Not every framework is perfect or maybe 90% of
the functionality is never used, but alot of good stuff that solves problems.
Maybe the lack of research on your part before you chose something like ember
is the real root cause, or maybe the lack of building a proof of concept to
determine if ember was the right choice before yapping about your own failure
with a framework that you really don't know.

------
msimpson
> I used quite an early beta of Ember to build BugMuncehr’s new feedback
> interface.

> I wanted to add a full REST API to BugMuncher, even though no-one had asked
> for it.

> I committed to using Ember before I knew enough about it.

> I didn’t keep it simple, I was stupid.

> Web apps often look complicated from the outsite, but underneath most of
> what they do is simply Create Read Update Delete, and you really don’t need
> a fancy JavaScript framework to do that.

So, to summarize, you failed at your first usage of a JavaScript framework due
to your own bad decisions. Therefore, all the benefits SPA structure can offer
the multitude of other projects is meaningless as, "...most of what they do is
simply Create Read Update Delete." Honestly, you've just swapped the bandwagon
effect for confirmation bias as you fell back to Rails.

~~~
MattBearman
I never said "all the benefits SPA structure can offer the multitude of other
projects" were meaningless, in fact I specifically said there's a time and
place for them. My point was most web apps, particularly an SaaS control
panel, may be better served with a simple CRUD app

~~~
msimpson
> I never said "all the benefits SPA structure can offer the multitude of
> other projects" were meaningless, in fact I specifically said there's a time
> and place for them.

No, you said:

> There’s a time and a place for JavaScript frameworks, and whatever it is
> you’re building probably isn’t it.

Do tell us when a SPA structure is appropriate... Then, explain how that
sentiment is any less "arrogant" than Ember.

------
aaron-lebo
As soon as you are doing more than simple HTML forms, a framework is useful.
There are some things that HTML does very well, but you hit the limits on
interactive UIs fairly quickly, managing state with plain HTML and HTTP is a
pain.

Also, it's possible Ember is bloated. The nice thing about Mithril and some
other frameworks is it takes so little to have routing, reusable, components,
etc. We're talking 20-30 lines. At that point you are hurting yourself if you
have a UI of any complexity and you aren't using a modern approach.

------
plastroltech
I am surprised at the number of people who think they can do everything
without a framework and that everything would just be better if they weren't
weighed down by the horrible affliction of using one. Frameworks provide real
value and while not required for many small applications they can be a huge
advantage in large enterprise applications.

For example if you are using Ember you gain the advantage of a client-side ORM
called Ember Data which handles caching and cache invalidation for your API
data. Did you handle that in your non-framework application? If you did, how
long did it take you to implement? How well tested is it? How many developers
besides yourself have reviewed it? How much documentation did you write and
how long does it take to bring new developers up to speed on it? If it breaks,
who will fix it?

Multiply that by ten or twenty depending on the framework and you start to see
what the benefits are.

------
jrs95
Here's a relevant post DHH made just a couple days ago:
[https://m.signalvnoise.com/hybrid-development-is-how-we-
give...](https://m.signalvnoise.com/hybrid-development-is-how-we-give-our-
teams-of-three-superpowers-2021a84437d)

------
kristopolous
Absolutely not. I've literally never thought while actually coding in 20 years
that something would be easier with a framework, not once.

However, almost every day, I think things would be easy without the framework
constraints of projects I've inherited.

Often I subvert them because I don't have time for the ceremony and
formalities and instead I have actual work to do.

And 100% of the time, without exception, the result is faster, simpler, and
more maintainable without the thousands of lines of framework code and the
FactoryFactoryProviders tagging along.

Making things as fancy as possible isn't a virtue. It's grossly inept and
deeply negligent. They are the antithesis of engineering. the prime objective
is to remove complexity and have direct functionality.

~~~
aaron-lebo
I don't see avoiding frameworks is superior to using a microframework like
Sinatra. The point of a good framework is it abstracts things that you have to
do repeatedly.

You can't really operate without a framework in some domains, if you aren't
using an existing one, it's because you've written your own.

~~~
kristopolous
at some point it's a debate on definition. To me, a "framework" as a strawman
(and unfortunately, usually in reality) has the following features

* hoses the stack trace and makes stepping through code useless and futile

* introduces nearly indistinguishable vague abstract ideas that have very real differences in code that are not well-documented

* changes core api and underlying functionality every few months and breaks backwards compatibility

* makes code action-at-a-distance spaghetti where one task is strewn around multiple files in different directories through some mystical dance of indirection

* is an order of magnitude slower while claiming to be zippy, lightweight, and fast

* constrains and restricts how you can use the language and express your ideas

* rewrites or suppresses core diagnostic, logging, and debugging features built into the language with their own variation (usually called something like EasyLog or SplendidDebug or some nonsense)...

* shoehorns your problem into a very specific and narrow domain

* introduces new configuration files and changes their formats at nearly every version

* does things very naively (such as busy-polling a file to look for changes, pegging a cpu core, instead of using inotify(2))

* has marketing like a new iPhone so everyone is onboard with the hot-newness of it all

* will be dead and abandoned in about 18 months.

It's essentially people who don't know what they're doing trusting other
people who don't know what they're doing all surrounded by mountains of hubris

------
choward
> So what’s wrong with JavaSript Frameworks?

> Having separate codebases for the API, control panel and feedback interface
> seemed like a good idea, but in reality it just meant more software with
> more dependencies to keep updated, more tests to run, and a much more
> complicated deployment process.

Huh? What am I missing here? He made the mistake of creating separate code
bases blames it on using a Javascript framework? He could have kept in in the
same code base just like using Javascript without a framework.

He then complains about Ember and that's all the explanation we get for why
Javascript frameworks are bad. That paragraph didn't even remotely answer the
question.

> Even if I was a seasoned pro with Ember, it’s still a case of two frameworks
> vs one, two codebases vs one, two test suites, two deployments processes,
> you get the idea.

He makes the same argument again but even worse. Why do you need 2 codebases
and 2 deployment processes? You don't. I still don't get how this has anything
to do with Javascript frameworks. Sure, you need 2 test suites, but you also
do without a Javascript framework.

I do agree that more code bases and deployment processes is more complicated,
but has absolutely nothing to do with Javascript frameworks.

------
ge96
Yeah I feel guilty and also not hired full time, currently using plain LAMP
and freelance, but I can develop with it. In particular with WordPress, I'm
able to open plugins read the code and change/add to them. Speed of
development too. But yeah... Starting to learn Angular will decide which PHP
Framework... Throw Go in there too. Damn... Gotta catch up.

Edit: I don't personally use WordPress but saying the stack is LAMP/LEMP so I
can work with it. It's just a matter of dealing with the random unclosed PHP
tags and figuring out the interconnected classes. It's good for learning how
to structure code I still have to use classes myself but assume I need a
reason to use object oriented like a video game.

Same with implementing personal GIT server and CI/CD design.

One thing, I imemented defuse/php-encryption recently with memcache was
watching the server's htop and see the php-fpm pool requests appear in the
processes neat.

So far using Angular CLI, the real time updating is sweet, also the event
bindings loops on what appear to be HTML... Yeah gotta spend more time on it
this Angular 4 in 60 minutes was a good intro but gotta use it.

~~~
jrs95
For what it's worth, I found React to be much easier to grok than any of the
current competition (even Vue)

~~~
ge96
I was slightly confused at first I thought rxjs was React nevermind haha.

Thanks for the insight. I don't know it may be bad I'd like to get hired and
everytime I check indeed I keep seeing Angular. so I should learn it but not
arguing with faster dev, secure, best practices...

Was thinking too what's the difference with being hired somewhere versus
getting your own clients... I don't know. Good to be single

Also I don't have a car to get to the jobs so... I'm thinking I'd rather have
the "burn rate" and work online/learn more in the mean time. Do my 2 days
restaurant work.

Edit: sorry rambling, I love this freedom, work, sleep whenever. I don't have
a sleep pattern and sometimes can't sleep at all. Then I can crawl into a dark
spot and sleep almost an entire day. Still surreal getting paid from the
internet.

~~~
jrs95
If you do keep seeing Angular, it's likely the old AngularJS 1.x stuff. At
least, that's how things are where I'm at.

~~~
ge96
I couldn't tell the difference. Offhand it seems nuts like when you create a
project and it builds all the folders. I am under the impression to deploy you
just move the folders over... Something said somewhere "they're just static
files" unless you're using postgresql or something as well. Yeah... Man I'm
behind.

Thanks

------
ape4
Frameworks always mention `routing`. Its not very hard to write some
javaScript that sends url A to function A, etc.

------
turtlebits
Most likely will get bashed for it, but.. I absolutely love Angular 1.
Productivity is through the roof for me. (caveat, I build small
dashboards/automation/tooling frontends). And no fancy build process,
sometimes I just work off 2 files (1 HTML, 1 JS)

~~~
mathieuuu
I am working on a product with multiple engineers and we adopted Reactiflux +
SPA + Node + a bunch of fancy tools.

While I love that stack, it took me a while to realize that for most of my
side projects, building alone a prototype with all those things is killing my
productivity. A messy Rails api with angular1 or even Rails + ERB are way
quicker.

Letting go best/latest practices and go for the the non-fancy (and sometimes a
bit dirty) way is harder than it seems.

------
jahbrewski
I just built a small client project in vanilla JavaScript + jQuery.

It was beautiful.

------
oblib
I looked at a lot of them at todomvc.com and decided I didn't want or need a
framework. Instead I chose to use Apache web server, CouchDB, PouchDB, jQuery,
and Bootstrap.

I chose those tools after boiling my brain over which of the JS Frameworks
there was "best" and really couldn't come to a conclusion.

After a few beers one night it occurred to me that maybe I should look for
what was "easiest for me" instead and that changed how I looked at it
entirely.

------
thinbeige
Good thought but I am not sure if OP's examples illustrate his thought well.

Same thought, another example: I like React + its ecosystem quite a lot but
often, no, actually most of the times, I realize that I don't need React
because the project I am just building is more or less kind of a landing page
with some simple UI.

Then, I rather use Pug (former Jade) + Stylus + Node. Super simple, proven and
you can go quite far.

------
JustSomeNobody
To answer the question directly, no you do not.

However, please do enumerate all the wheels you'll be reinventing if you
choose not to.

If you _do_ choose a framework, please make sure it covers most of the
requirements of your project. If it doesn't, or you're not sure, then maybe
you don't understand something so ask for help.

------
triskweline
There are server-side libraries like Unpoly
([https://unpoly.com/](https://unpoly.com/)) that give you most of the
benefits of heavyweight JavaScript frameworks, but without the complexity and
code duplication.

------
owebmaster
Do you really need a backend framework?

I'm doing some projects using only React/React Native and static edn files to
load the data and it has been a great experience.

~~~
LyndsySimon
> Do you really need a backend framework?

Actually, probably not. It's trivially easy to create a simple Python web
application using only Werkzeug, or even using WSGI directly.

~~~
owebmaster
Or generating all static versions of the content you want to serve.

------
dwaltrip
This question doesn't have a yes/no answer...

