
You probably don't need that hip web framework - bfoks
https://char.gd/blog/2019/you-dont-need-that-hipster-web-framework
======
btown
SPAs become necessary when the user experience requires bells and whistles,
like cross-widget consistency of like/friend request counts (the original use
case of React IIRC).

It's not "you ain't gonna need it," it's "you are gonna need it, users will
judge you by your fluidity, sure it's overkill right now, but the overhead may
be less than the pain of a frontend rewrite since you may need it soon."

I've often thought that if there was a way to gradually _codegen_ a _fluent_
React codebase from Django/Rails/Laravel server-focused frameworks, and move
template-by-template into a rich frontend + API, a lot more people would start
with those server-focused frameworks, because there wouldn't be a need for a
full rewrite. It would be a holy grail for our industry and let us develop
business apps way faster. Not an easy problem to solve. Email me if anyone
reading this wants to chat though!

~~~
ljm
The underlying concept of React is so intuitive that I would hope that
browsers provide a native implementation. Use a `<script language="jsx" />`
tag or something so you still have the old fashioned API.

~~~
socceroos
Web components

------
013a
I feel very strongly about this: The single most important thing for a growing
software project is Using Opinionated Tooling.

Too many new projects, libraries, frameworks, etc come around and broadcast
"we're Unopinionated!" like that's some great thing.

You cannot, without exception, develop complex software without asserting and
extrapolating opinions about design patterns, tools, frameworks, layout, etc
somewhere in the stack. Its impossible. You'll end up with an unmaintainable
mess.

Medium and Large companies will naturally develop a bunch of internal opinions
about things. Internal tooling. CI. Development and Deployment environments.
Those are all opinions that get built up over time, based on the experiences
of the people who build them. This is fantastic; its how companies like Google
and Amazon have reached such massive scale, but how many other companies start
failing when they try the same.

Small companies and Startups do not have these opinions. They _have_ to
outsource their opinions, at least at the start. A large company might say
"yeah we have our own blackboxed JS serverside framework, just use that it'll
do logging, tracing, error reporting, its great." Small companies won't have
that. So, use Rails, or Phoenix, or something that is highly opinionated.
Learn what works. Learn what doesn't.

This is Javascript's fatal flaw. And it is massive. And it still has not been
improved years later. There is an extreme lack of opinionated tooling. NextJS
has been doing some very interesting work introducing a more productive and
opinionated frontend development experience. The backend really has nothing
similar; the closest we got was Meteor, and it has/had too many weird
technical issues and poor design choices to be considered a good choice. The
team behind it then mostly moved to Apollo, which reverted back to championing
how unopinionated it is.

~~~
lucidone
Makes sense why Apollo is such a clusterfuck then. Have you looked at Nest for
Node on the server side? I'm using it for a client project right now and find
it the best offering for server side javascript. The ecosystem _is_ still
immature though relative to something like Rails or Laravel.

~~~
dcosson
What's wrong with Apollo?

~~~
013a
I don't feel that anything is wrong with it; it's just not the whole answer
for many projects. You end up bundling tons of middleware for things like
logging, metrics, tracing, authn, etc. If you use typescript, you inevitably
end up wanting more type safety so you'll reach for resolver codegen, which
Apollo does not do on the server (they _do_ do it for the client). And it
doesn't assert any opinions about how the _rest_ of the app should be
structured, such as business logic, dependency injection, etc.

Apollo Server would be a great component in a broader, opinionated server-side
web framework.

------
burlesona
At the end of the post he mentions what I think is a really under-rated
approach: a “normal” server rendered application with Vue components used per-
page when the UI is highly dynamic.

I’ve built a relatively large app this way and found it to be quite nice. Vue
works very nicely inside the container elements in the page where I need it,
and it’s pretty easy to bootstrap the initial state into the page using the
same serializers I do for JSON endpoints, so once it’s rendered users can
spent a lot of time on a particular screen without any further page loads.

The last bit that’s nice is bundle size. It’s not too hard to split bundles
based on unique entry pages, so you can end up with something like 30kb of
“global” JS and then a second bundle for the big meaty pages that may range
from 20 - 200kb. With caching that means 90% of screens have a very small
payload and load really fast, and the rest have a slightly slower first load
and then the same perf profile.

This has been a highly productive way to work, I’m surprised that it’s not
written about more often.

~~~
mythrwy
Seconded. This is a great way to go.

Quite often there isn't a reason to have SPA routing. But that doesn't mean
you can't enjoy lots of benefits of the fronted framework without the unneeded
complexity solving something you don't really need in the first place.

------
TJTorola
You probably need the right tool for the job. I'd argue that react, Vue, and
company are only best for true web _applications_, that is highly stateful
projects that are more akin to standard desktop apps than web pages, ex:
google docs.

If you need server side rendering that could be a sign that what you have is a
lot of public indexable information and that most often describes a
traditional web site instead. In that case your "old school" rails or laravel
solutions are almost definitely a better choice.

------
api_or_ipa
Why do we keep seeing posts like this? My team _absolutely_ needs
React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today, to ship and yeah
we ship our backend with Docker. Why do I know we need it? Because we have
years of experience in our workflow and we understand the problems we need to
solve in the development workflow and timeline our company uses. Do you know
who _doesn 't_ understand our needs? Someone writing a low-quality post about
how _their_ specific needs can be met with existing technology. Please just
leave me be and go focus on solving your own problems, I wouldn't be using
this technology if I didn't think it worked better than anything else.

/rant.

~~~
jchw
My theory is its like this mostly because on HN because there's no downvote
for posts. Everything useful that can be said about how bloated web frameworks
supposedly are has pretty much been said imo, but there's a niche of people
convinced every web app is actually simple and should be done using Netscape 4
era HTML.

I'm all for simplicity... but if you are developing a large web application,
you probably would benefit from "heavy" web frameworks (they're not really
that bad though.) What "large" is can be debated, but I'd argue most pages we
use today are "large" enough. HN is a good exception. GitHub, large
publications, webmail, online shops, anything dealing with realtime data...
It's probably worth it.

~~~
dcosson
Github is actually a great example - i think it's getting better gradually,
but for a lot time it was really obvious that it was server-rendered pages
with a few ajax calls sprinkled in to do small things like update the status
when the tests finish. And it led to all kinds of weird edge cases and
unpredictability, some things would live update, other things you need to do
hard refresh to see the latest version, sometimes when using the back button
it would reload the original version of the page before the ajax calls had
succeeded so you'd see old data.

Clearly it wasn't bad enough to drive everyone off the platform, but there's
no way you'll convince me that that was a better system that a well-written
SPA built with modern tools.

------
dwheeler
In short: Pick the right tool for the job. Some projects need systems like
React; some don't. A lot of projects do _NOT_ need complex underlying systems
- and some do. It's sad that "pick the right tool for the job" is somehow
controversial.

~~~
brodsky
funny, I just replied to another comment almost word-for-word in exactly the
same terms, before seeing yours. I agree completely.

------
drivingmenuts
To be honest, I’m still fine with jQuery and Laravel. I’ve looked at React and
Vue and while they are marvels, I ain’t got that kind of time.

But, I also don’t write mobile apps. I’m dealing with desktop and the rules
are different there.

~~~
teucris
My takeaway from this article is to use what you know if you want to ship
something. With every new project, you’re given the choice to use a new stack.
I think it’s pretty rare that you want to ship something, have the chops to
ship it, but some new magic thing is worth the time investment to make it
happen.

For instance, I really don’t want to take the time to learn Laravel. I get my
fastest work done with React and a turnkey serverless solution.

------
wwweston
"Probably" perhaps overstates the case, but it's fair to imply there should be
a _question_ about if you need it, and the default answer should not always be
yes.

Here's some heuristics I like:

If nearly all of your application's data presentation/processing needs map
cleanly to HTTP/REST semantics for the various entities in the system... you
probably don't.

If your UX involves representing/manipulating the same data in several
different ways on the page and this data is going to change, _especially_ in
ways that don't map cleanly to HTTP semantics, you should consider that you do
need the hip framework. Probability rises depending on how frequently user
interactions produce different views of the data.

If your data is a headache to represent in HTML, you probably do (also, if you
don't have an adequate general automated way to represent your data in HTML
from some model description, you will likely either gravitate to solving this
problem one way or another, or gravitate to a hip front-end framework).

If you ask yourself what problem you're solving with your front-end framework,
and the answer either includes the word "modern" or another adjective
describing a merit you aren't exactly sure relates to a specific problem to be
solved, then you probably can't yet make an informed decision about whether
you need that hip web framework. But, OTOH, making uninformed decisions is one
way of getting the experience necessary to make informed ones, so...

------
dfee
The promise of front end frameworks is realized by startups when using a BaaS
(backend as a service) - like Firebase.

The idea is that you only have to worry about one environment (the browser -
yeah, I get the irony) and one deployment instead of multiple (the former plus
backend deployment, monitoring, etc.).

The second you start worrying about SSR (server side rendering) you’re
suddenly taking on the complexity of writing a backend again.

~~~
dvasdekis
My understanding of node's birth and rapid rise was that it was "backend
tooling for frontend-devs" \- suddenly it gave the front-end teams the power
they needed to launch quickly using what they knew.

I've been looking for quite some time for "front-end tooling for back-end
devs" without success - there are some great frameworks like Postgrest or
Hasura which take you from Database through to API interface, but then you're
faced with raw Javascript and all that pain synchronising browser state with
the API via a web-worker. My attempts to use Vue & React have just resulted in
the exchange of one kind of complexity (raw Javascript state change) with
another (learning the framework).

I'm all ears, if anyone has used anything (framework, IDE, WYSIWYG editor,
some SAAS app, anything) that simplifies the journey from OpenAPI spec to a
webpage with a UI that changes as the API returns things.

~~~
ppeetteerr
There are many tools that will turn backend code into interactive UI, but they
generate a mess on the front-end.

------
coleifer
> your first version of your idea almost always doesn't need that hipster web
> framework you're thinking about using.

No, but I bet your last version will have. Right before it fades into
obsolescence, never to be seen again.

------
leowoo91
I ve been using Jquery since long time where almost every frontend article
says it's an antipattern. But it's never gonna give me up, never gonna let me
down.

------
rcarmo
Even though I do some Angular now and then, I still reach for RiotJS (and D3)
whenever I want to build a PoC. A lot of front-end stuff is just too complex
to iterate upon quickly and with minimal tooling (I keep changing machines,
and the overhead of setting up new projects/workspaces every time has always
been a pain, even with the umpteen Node-based bootstrapping tools of the post-
Yeoman era).

------
Cyclone_
He mentioned that it took a long time to get going with some of the frameworks
to get an MVP but the advantage of most of those is that while they take time
more to learn you'll be more productive with them in the long run and there
will be less spaghetti code.

------
gsklee
The frontend landscape has actually been relatively stable over the last 2
years or so, with no major new contender coming up because things on the table
now are all very mature. I don't foresee this to change any time soon with
React and Vue, both really robust and complete, covering up two extremes of
the spectrum.

The fact these recurring shitposts always began their rants with how freaking
fast things are moving (in the speed they perceived) and that they couldn't
keep it up strongly suggested that they're outta the loop for a long time or
they aren't good frontends in the first place. It's also really harmful to the
industry; I've seen a few frontend wannabes backing out because of all these
uncalled for FUDs creating mental barriers for newcomers while I've
repetitively tried to assure them it's really not that unstable in recent
years.

