
You probably don't need a JavaScript framework - Svenskunganka
https://slack-files.com/T03JT4FC2-F151AAF7A-13fe6f98da
======
edejong
I still remember doing a PoC for an end-to-end secure messaging app with web
support, around 3 years back. It was written in plain JS with jquery and one
or two libs for crypto bolted on. Simple, easy, but not very maintenance
friendly written. Took around 2000 lines all in all. One of four clients
(Android, iOS and a bot framework in Scala/Java).

Then the web-boys came in to rewrite my... well, contraption. In came Grunt,
NPM, Angular, some CSS framework, unit testing. Much more, but I forgot the
names of all of it, you know the drill. I have to admit, looking at each of
these components independently, one could hardly argue with their usefulness,
but together they buried a relatively simple and elegant messaging system in
tons and tons of incoherent, unmaintained, inextensible and incompatible (with
websockets at the time) stuff.

The line-count went up, of course, easily to 15000 lines. I couldn't
understand my own designs anymore, since they got spread out over dozens
different files. Refactoring became almost impossible. The web-boys however,
didn't understand asynchronous messaging, cryptography and eventual
consistency very well and we lost each other, making a babylonian tower, far
away from our original goals.

The quality of your solution is not in your libraries, or your frameworks,
instead it's in being fluent bottom-up before grabbing a library or two.
You'll see you often don't even need them.

(edit: small typos, edit2: please explain down-votes, I'd like to know and be
happy to answer any questions)

~~~
jlg23
I can relate to your experience but you, just as me, seem not to be a typical
front-end developer - the "web-boys" (a term which probably got you the down-
votes) on the other hand are. If one asks them why they do things the way they
do them, they usually have a coherent answer and are happy to explain it.

As someone else pointed out in this thread, a great advantage of established
frameworks is that they provide a coding standard for a team. People who do
this stuff every day can easily follow the standard, understand the flow and
be very productive. They did invest lots of time to learn about all those
tools and libraries and probably had an overall productivity gain compared to
writing native JS.

If you don't really enjoy front-end development, and your comment reads like
you don't, get on your high horse and join me for a ride while the "web-boys"
make our hacked UIs usable for end-users and maintainable for the next "web-
boys" who have to hack on it. When we get back we'll probably be very grateful
for a great UI(X). ;)

~~~
exodust
> _" They did invest lots of time to learn about all those tools and
> libraries"_

Unfortunately that claim doesn't hold up to what I suspect is happening most
of the time. At least in my experience at work I've seen tech leads or someone
similar introduce frameworks without so much as "apparently it's quite good,
so let's use it".

One case in particular, Angular was chosen and turned out not to be suitable -
it ran very slowly with the tasks it was chosen to do in the browser on a
particularly busy web page. Learning the limitations of Angular would have
gone a long way to avoiding the poor result. Not enough learning, too much
embracing shiny new things.

~~~
jlg23
> introduce frameworks without so much as "apparently it's quite good, so
> let's use it"

And if they all want to use it - let them use it. The productivity gained by
agreeing on a framework usually outweighs the performance loss over the "best"
solution. Yes, my native JS implementation of a gallery app is much faster
than the React version (reviewed by an experienced React-dev and judged
"good") but if that project goes public and other people have to work on it
I'll be damned if I make them learn my way of doing things. I'd expect these
devs to implement a feature quickly and that means they use the framework they
are most comfortable with. If it is good enough, it is good enough.

Aiming for perfection killed way too many projects, accepting that the
productive path is not always the nicest or cleanest (according to some
arbitrary metric) is what makes projects succeed. e.g.: Writing perl code is
definitely not the best thing to do, performance wise (when counting clock
cycles), but it does (did) allow some folks to be incredibly successful. See
this awesome essay of this very site's founder:
[http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

~~~
developer2
>> The productivity gained by agreeing on a framework

This is a false dichotomy. This only applies once the developers have _real
experience_ with the framework. Throwing a brand new framework at the devs
without at least a month to _play_ with it - play, not work! - is doomed to
failure. Expecting first-time use of a framework on an actual project to go
well is a horrible mistake.

There is a _lot_ to learn with any reasonably sized framework. Making devs use
an unknown framework without time to learn it will result in a project that
doesn't use that framework properly. Thousands of lines of code will be
written... to duplicate functionality the framework already provides, but that
the devs don't know exist. The rush of deadlines means that the devs skip
reading documentation or researching the "right way" to do every task, and you
wind up with a project that _technically_ uses the framework... except that
the entire project will be written in a way that someone with previous
experience with that framework would never have allowed to happen.

Some frameworks have so much to learn that it's essentially equivalent to
having to learn a new programming language. Would you ever expect someone to
learn C in a week? Java? Python? No...? Then please don't expect devs to pick
up a new framework on the spot with no time to self-train on it.

~~~
jlg23
You are quoting me but I am not sure you are responding to my comment.

>> if they all want to use it - let them use it

>> they use the framework they are most comfortable with.

> Then please don't expect devs to pick up a new framework on the spot with no
> time to self-train on it.

I never said I did.

~~~
developer2
Haha. I thought of that and posted a sub-reply, according to timestamps, just
5 mins before you posted this. I read your whole comment, and just intended to
clarify that the very act of choosing a framework does not necessarily mean
increased productivity, if the devs don't know the framework in question. A
tangent based solely off the quoted part, for something I've seen time and
time again over the years (new framework, no time to learn it, rushed
deadlines).

------
dwg
To begin, React isn't a framework. It’s a tool. Would you compare a table saw
to a workshop? That doesn’t make sense and neither does comparing React to a
framework—especially if you’re saying you don’t need one.

Furthermore, using a virtual DOM is not the purpose of React. Virtual DOM is
merely a part of how React works. People don't buy cars to get an engine. They
buy cars to get around places. People don't use React to get a virtual DOM
engine. People use React to make building and maintaining apps easier.

Let’s say you decide you’re smarter than everyone who worked on React or some
other library, and you can build your app without them. Great, if you’re
building a small app this is probably just fine. Scale your app up, however,
and you’re going to end up with a framework anyway. The only difference is
that it will be your own framework, and chances are it will be difficult to
understand, hard to maintain, and full of bugs, and you may even be stuck with
it because of how much it would cost to change.

Using libraries, or even frameworks, is how you leverage the collective
intelligence of dozen, hundreds, or even thousands of very smart minds (a few
of whom might even be smarter than you). Especially proven ones with many
successful projects using them.

You’re welcome to give this up to be a cowboy, but me: I’ve been there,
thought I was that smart, and realized how much better off I am by not trying
to reinvent the wheel every time.

The rest of the article mentions other points which don’t seem particularly
related to framework decisions to me at all, so I’ll let them be.

~~~
BinaryIdiot
> To begin, React isn't a framework.

The way I look at it:

\- If you use a library that augments your style of work but doesn't change it
then it's a library. Maybe a tool.

\- If you use a library that replaces or changes your style of work then it is
a framework.

React is a framework in my opinion. It can be used as a library but it's
almost never used that way; most people incorporate JSX and much of the
virtual dom into their workflow.

But this is pedantic. I feel comfortable I could make an argument for almost
any JavaScript library being a framework as well as not being a framework.

> Scale your app up, however, and you’re going to end up with a framework
> anyway. The only difference is that it will be your own framework, and
> chances are it will be difficult to understand, hard to maintain, and full
> of bugs, and you may even be stuck with it because of how much it would cost
> to change.

While correct I cannot disagree with you enough. If you write clean, as-
simple-as-possible code with clear separations of concerns it's dead easy to
maintain and not necessarily "full of bugs". It really just boils down to how
well a developer can architect an application to determine if their own
framework is going to be a huge bottle neck / issue or a breeze. I've been
through both :)

> You’re welcome to give this up to be a cowboy, but me: I’ve been there,
> thought I was that smart, and realized how much better off I am by not
> trying to reinvent the wheel every time.

I'm not a fan of this sentiment. If it makes the most sense (and it doesn't
always) I try to avoid using frameworks but I would _hardly_ call myself a
cowboy (though perhaps I will going forward, ha).

The DOM API, as this article shows, provides _quite a bit_ of functionality
that many popular frameworks / libraries provide and as long as you don't need
to target old browsers you're fine here.

Yes, angular and react do a lot for you but you can still write effective web
applications without them with minimal "reinventing of the wheel". Just
because someone provides a way to do X in a framework doesn't mean it's not
easy to still do X without a framework. Many times the bulk of the framework's
capabilities are supporting its own, specialized workflow that isn't always
necessary.

~~~
bluejellybean
Good post, very well said and says most of what I wanted to say on the
subject.

I was much more in the camp of 'use/learn frameworks as much as possible for
productivity', started a new job and have really become much more moderate on
the subject. There really is a balance and the type of application you're
building matters. The best thing about writing your own framework is that
you're able to structure to fit the exact needs of a business. The
productivity gains can be extremely massive as well. If you can build a custom
system that scales to your needs, it can certainly be worth doing. The flip
side of course is that you may ( Probably? ) have a fairly simple/basic
product. If you don't have heavy business logic to model, the heavy automation
and tooling that is available can be a damn good way to go.

------
darawk
The point of React isn't its performance (though that is nice). The point of
React is the simplicity and composability of functional components.

You can create this on your own of course (and I have), but the solution of
"just use the DOM" ignores an enormous amount of progress that React made with
component _design_ , not performance.

~~~
takno
The main contention of the article is that this "simplicity" is illusory. You
end up writing just as much code, but now you've added a complex dependency
you don't really understand but have to make your customers download, and
ultimately have to test against

~~~
gjolund
That seems incredibly anecdotal. Perhaps if you don't understand the framework
you are using.

Ember (for example), takes care of huge swathes of complexity for you. I can't
imagine trying to build a:

* client side router * data transportation/cache layer * view layer * model layer * build pipeline

... and more, in less code that just

`npm install -g ember-cli` `ember new my-app`

And then having a common app structure with thousands of other people that can
provide help and insight.

You people really are kidding yourselves. I feel bad for whoever is paying
your salaries.

~~~
BinaryIdiot
> I can't imagine trying to build a: * client side router * data
> transportation/cache layer * view layer * model layer * build pipeline

Why can't you? Routers are _easy_ ; you likely don't need more than a few
lines of code to accomplish most of what you need. Caching and data
transportation is also easy and simple (there are a million cache libraries if
you don't want to write a small one). Views and models have been done since
the 90s and are relatively easy as well (in fact I wrote one in just a few
minutes the other day to drop some dependencies from a personal project).
Though models are not always the best way but I'm digressing.

Build pipelines usually add more complexity than needed in my experience. I
almost always, eventually, nix whatever complicated build pipeline I start out
with and go with something dead simple.

Most of this stuff has been done for over 15 years on the web. It's at the
point where it should be mostly boilerplate / routine if you're not using a
framework.

~~~
deathanatos
> Routers are _easy_ ; you likely don't need more than a few lines of code to
> accomplish most of what you need.

Router as in delegating a URL to a handler for that URL? I wrote one once …
and it is deceptive and _not_ easy; most of the server side ones that I've
encountered (e.g., Django, Flask, nginx) do a poor job.¹

The naive implementation of a mapping of regexes to handlers is dead simple to
implement, but not very ergonomic to really use. Something that understands
that paths are hierarchies works a lot better. Then it's also nice to have
something that can stub out a component to a variable (and preferably type
check that), e.g., "/customers/:customer_id", and pass you "customer_id" after
validating it to be an integer, a UUID, or whatever. Then you need the
capability to delegate an entire subtrees to a subrouter, and maybe if we
could just get some handling of delegation based on the method in here, but
HEAD needs to be automatic…, and canonicalization of URLs would be nice too.

¹I feel like this is one of those things that until you've seen something
better, you're still wanting the faster horse.

------
sod
A) There are people that love frameworks. B) There are the ones that don't.

The type A ones just gave up to the complexity and bury it with foreign
frameworks.

The latter ones invent their own ecosystem. And are very productive with it.
It's fast and beautiful. And you know every screw and bolt. There is a feature
request? No problem, you know immediately how to solve it. I know many of
them. And nearly all of them are the best I have ever known.

But here is the big "but". Would programmer type B want to work with a 2 year
old project from another type B programmer? And there you have your answer why
there is such a hugh appretiation for frameworks. Its easier to throw 10
programmers of type A onto the same project.

~~~
seanwilson
> The latter ones invent their own ecosystem. And are very productive with it.
> It's fast and beautiful. And you know every screw and bolt. There is a
> feature request? No problem, you know immediately how to solve it. I know
> many of them. And nearly all of them are the best I have ever known.

You're forgetting type C that don't know anything about existing frameworks so
decide to reinvent the wheel by writing an unmaintainable mess of spaghetti
code... I'm guessing type Bs are very rare. Once you've seen enough untestable
jQuery soup you'll learn to appreciate frameworks.

~~~
wccrawford
I would go so far as to say that to a new programmer on the team, Type B and
Type C programmers' code looks much the same.

I'm a type B. I've written entire systems from scratch that fit me like a
glove. I could fix any problem in no time flat, and it was very stable.

But when it came time to have other people work on it, it didn't fit them like
a glove. It barely made any sense to them at all. They eventually got up to
speed, but they were never as productive in it as they would have been in a
decent framework-based system.

I was actually quite happy when they decided to rewrite the whole thing... And
then it turned out I left about a year later, so it was a good thing they did.

------
WalterSear
You don't need one, but if you don't eventually adopt one, you'll end up
writing one.

~~~
takno
Sure, you may well end up writing one, but it's likely to be a fraction of the
size. My current entire app is running at half the size of jquery, which is
getting me awesomely quick page loads even on poor mobile connections. The dev
time was longer, but not crazily longer, and the surface area for testing is
somewhat smaller

~~~
Touche
In reality JavaScript size means very little when a single image might be
500k.

~~~
Svenskunganka
Unfortunately I have to disagree. The JavaScript Engine still have to parse
and interpret the code. This can take a bit of time, especially on mobile
devices.

~~~
openasocket
Parse time shouldn't be very long at all, especially compared to network
latency. How long does it take for large (~100-150kb minified) to be parsed
and interpreted? I'd be surprised if it's more than 100ms

~~~
Walkman
100ms is noticeable. It's already slow if you reach that.

~~~
WalterSear
It's barely above the threshold for detectable live feedback latency, from a
musical instrument or sight/sound correlation. As a user veiwing a page with
plenty of other latency, it's inconsequential, particularly since you can
execute your js while image assets are still incoming.

------
natrius
I don't use React for speed. I use it because manipulating the DOM to make it
reflect the application state is _hard_. It's something a program should do
for me. React is that program.

~~~
deadowl
I don't get a lot of opportunities to play around with JS frameworks, which is
odd because I hobby-code a lot in JS. I imagine the top reasons to use
frameworks are cross-browser compatibility and support for scalability in the
domain of your work. Unfortunately sometimes people use them because the only
tool they have is a hammer, so everything is a nail. Vanilla DOM manipulation
has become much easier in the past few years. I have played around with some
new DOM features in my own time, but for anything public-facing I'm going to
use a library that allows for cross-browser compatibility, and typically
that's a combination of jQuery, polyfills, etc.

~~~
elmigranto
It's not that it is hard to `document.createElement` compared to
`React.createElement`, it's just that React has a nice paradigm of syncing
your app state to what's displayed to the user which many people like. Sure it
might be better somewhere else, but React is what is popular and more easily
accessible.

------
Nitramp
One thing many people underestimate is how easy it is to run into XSS, XSRF,
XSSI when not using a framework, in particular XSS when using native DOM APIs
("location.href = ..." \- pwned. "e.innerHTML = ..." \- pwned. "a.href = ..."
\- pwned. "*.src = ..." \- pwned.).

You might not need a framework, but you'll need a structured approach to avoid
those problems, and frameworks can help a lot with security.

~~~
Achshar
None of those are "pwned" if you know what you're doing. Idiot proofing is a
real feature I grant you but it's not something you can blame the native DOM
APIs for.

~~~
MaulingMonkey
Anyone who knows what they're doing is one dumb moment away from not knowing
what they're doing. I suspect I know no programmers that don't average at
least a dumb moment per day. Your code reviewer is one dumb moment away from
not catching it in your code review - which may be as simple as skimming a
little too fast because the diff was a little too big. tl;dr: This:

> None of those are "pwned" if you know what you're doing.

... can be rephrased as "All of these are still 'pwned' on a daily basis."

------
vhiremath4
"Another example is the Fetch API"... That API has very limited cross-browser
support. One of the largest reasons web frameworks exist is to bridge the gaps
between browser incompatibilities/offering legacy support.

I don't know if this person has even really scaled and deployed a web
application that must work across several browsers - especially older browser
versions. I always wonder that whenever I see people bashing frameworks. Like
the author said, start with asking why the framework was created. Just make
sure you come up with the right answer to that question next time.

~~~
zxcvcxz
Yeah I find it hard to believe that the people who go on about how convoluted
web development is actually get paid to do web development.

1) Where are all the people hiring web devs who don't know a single library or
framework?

2) Why do huge tech companies like facebook and google develop web frameworks
if they're unnecessary?

~~~
takno
Do Google even really use angular? I know none of their core products use it.
As to Facebook, their website is painfully slow, seems like it's not a model
of the right way to do stuff

~~~
sotojuan
I don't think their main website uses React fully yet. Instagram does and
that's pretty fast—same as most other well-done React apps.

~~~
vmasto
Facebook.com contains more than 20,000 react components. They use React at
pretty much every dynamic aspect on their website. They also use React Native
in a lot of aspects of their mobile apps, both for iOS and android.

------
etatoby
The article's author does not seem to understand what React is for and why
people use it.

The article is full of sentences like: it's true React is fast, but basic
Javascript is even faster. Duh? It's true React is quite small, but if you
don't use it, your site will be even smaller. No sh*t Sherlock?

React was invented to simplify the program structure of medium-to-large
applications by replicating the successful data flow of the Web itself:
namely, the state of the application is in one place only (the URL in the Web,
the state object in React); HTML is generated from that state using one set of
reusable and composable templates; and crucially, user events only affect the
state, not the HTML itself.

Personally, I'm going back to basic HTML + progressive enhancement, for a
variety of reasons. But React is the sanest of all the client-side
architectures I've seen so far, including bare-bones web api.

~~~
dualogy
"for a variety of reasons"\---care to share in brief?

------
teen
The cycle continues...

No framework -> Backbone -> Angular -> React -> No framework

We should be back towards using a simple MVC skeleton by the end of 2016.

~~~
trgn
I always kind of liked the simplicity of Dojo-stores, and its observable
QueryResults. Simple CRUD, to-the-point, tiny footprint, ... Put a view on it,
BOOM, app.

(fan of modern frameworks btw, just saying vanilla MVC is kewl too)

------
educar
The main point of frameworks/libraries is to set coding guidelines for the
team. It's fine to go off and invent your own framework but this causes
maintenance issues for the people coming in next. Most likely, there are no
docs or examples for the code you just wrote (especially the framework bits).
When a framework which has a community is chosen, these boring things like
docs/examples/references/blog posts get fixed over time. So it's best to pick
one so that the code is easier to maintain in the long run. Besides, the focus
should be on the app and not the framework/library and writing your own is
just distraction.

~~~
coldtea
> _When a framework which has a community is chosen, these boring things like
> docs /examples/references/blog posts get fixed over time._

Not in my experience. I've seen frameworks come and go like that over the span
of 15 years and teams rewriting for the new "hotness".

So, one year they do Angular, then Angular 2 comes out, invalidating a lot of
their code/experience, then they get to React, then they're told that they
should structure it like Flux, then Redux comes along, and who knows what in 2
years.

Just imaging that merely 5 years ago Backbone was the preferred edge JS
framework. In fact wasn't even that at that point -- it was only just released
5 years ago...

~~~
jimbobimbo
Release of a new framework doesn't render all existing code based on an older
framework useless. Nobody mandates moving all existing Angular 1 codebases to
Angular 2.

~~~
coldtea
Mandate moving them, no.

But eventually they'll bit rot, and all the new features, and community
support will move to 2 -- and you're stuck with the worst of both worlds: a
framework with stuff you don't need AND with few left to maintain it.

------
Svenskunganka
I apologize for not adressing your concerns with the post earlier, I've just
added an update to the bottom of the post with some replies to some comments
I've read.

Please keep in mind that my intent is not to mock you or your framework of
choice. My goal with this post is to try to inspire you to try building
something with the native DOM and Web API and see for yourself. Some may enjoy
it, others may not. And if you feel comfortable with your current way of
building your web applications with a framework, that's completely fine.

Also, please keep in mind that I cannot address every use-case in a single
post. As much as I'd like to, that's going to take way too much time.

~~~
Michielvv
Although I agree with the idea that Frameworks can easily make your life worse
instead of better. Especially at the time the Framework moves forward to a
version that is not at all compatible with what you are doing.

However, in your update you are suggesting to use Object.observe as a simple
alternative to React. I looked it up and
[https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/observe)
says it is deprecated and even removed in some browsers.

Using API's that are not widely supported and then not relying on a well
supported framework to abstract them, seems to me an even worse maintenance
nightmare than sticking with a Framework.

------
scope
\- shows an example using mutation observer API and fails to mention it only
works on IE 11+

\- follows the _widely_ accepted format of "rant about some popular
framework/library/language by mimicking a tiny portion of it"

\- uses _shock factor_ to get the reader's attention

> React, Virtual DOM, Webpack, TypeScript, JSX… HOLD ON! Let’s pause for a
> second here and think.

YES, you don't always need a framework/library BUT if you want to build
something maintainable & scalable, it's better to opt for battle tested
approaches (which is especially true when it comes to the web, having browser
quirks)

------
mhd
It's interesting that by comparison, a lot of these modern JS frameworks are
positively tiny. No comparison to e.g. Cocoa, QT, MFC, Rails, Spring and all
the things usually called the f-word. React itself barely qualifies for
"library", more like "helper functions".

So, having started outside the web world, I really don't understand the
hullabaloo. It reminds me of a certain point in Windows development, when
shareware etc. was a thing, but download speeds, RAM and disk space were still
low. Creating smaller programs was a thing for some developers, both for
distribution and an alleged "bare metal" feel (whether they were that much
better than e.g. a big package including all of Tcl/Tk is another matter).
Programming Win32 with assembly. The ATL. Compressed executables. People
recomming a new weird command-line oriented operating system made by some
crazy Finn.

Both ATL and Win32ASM bring in yet another feature: Programming in my
favorite, possibly new idiom. Another reason for creating these mini-
frameworks in the JS world. All glued together by slapdash micro-libs and
utilities, that might be there one day, might be gone tomorrow.

I might finally be getting old and cranky, but I actually feel that some
bigger frameworks wouldn't hurt. Some kind of standard library included, given
that this won't come out of standards or the global community. More opinions.
A set of standard components/widgets, not just three score methods of
displaying them and two score of connecting them to a score of different
backends.

Go all in: If you really want to just use the web browser as a delivery system
for all kinds of GUIs, give me a GUI framework. I think that strangely enough
ExtJS used to have more competition there...

Either that, or make more use out of the old-fashioned tenets of HTML, do more
with text and links and stick to progressive enhancement. The middle ground of
shiny but tiny GUIs that seems to be the rule for modern "SPAs" is neither
fish nor flesh. (And I don't think that "isomorphic apps" is the answer here,
either.)

------
mortenjorck
This might be the post that convinces me to write a companion piece on why you
probably don't need a CSS framework, either. Browser renderers have come so
far since Bootstrap's peak: Flexbox has all but obviated its primary value
proposition, and when CSS grids make it out of RFC, using Bootstrap for layout
will be like using Backbone to do rollover styling.

~~~
CuriouslyC
Sorry, I have to disagree strongly. For starters, bootstrap provides
consistent and attractive default styles. Additionally, if you implement your
styles as a bootstrap theme, third party components that are written with
bootstrap in mind will (usually) automatically have the correct look & feel.

Flexbox is definitely a lot nicer than the Bootstrap column system though.

------
zwily
I wrote dbmon at Instructure (first with jquery, then in ember, then in react,
where it has been for a couple years) to give us a birds eye view of a bunch
of databases. It's been kind of surreal to watch it blow up into what it has.

------
moron4hire
I'm getting so tired of this conversation. Use a framework. Don't use a
framework. Just build something already. Who cares how you made it? I'm so
sick of getting asked "what framework did you use?" I'm so sick of seeing
people pitch their projects as "ProjectName: built with FrameworkX and
LibraryY", with zero indication what the project does. If the most interesting
part of the project to you is the tools with which it's built, you're not an
entrepreneur, you're a fetishist.

------
TheCoelacanth
You don't need a JavaScript framework. You just need a bunch of stuff that you
can't use because it isn't supported in IE9.

> HTTP/2 is widely supported by web browsers already. At the time of writing,
> 70.15% of visitors has support for the updated protocol.

Oh yay, so only another 5-10 years until I can use it.

------
nogridbag
I came across this thread late, but the comments here have been quite
fascinating to read. I think as developers we're always seeing patterns in our
code and trying to figure out the best way to solve them and that's how many
frameworks emerge. Before React's emergence I would occasionally come across
UIs which were incredibly complex due to events firing left and right (and
events firing in response to those events, etc) and in an attempt to reduce
cognitive load I would try and re-structure the code with a uni-directional
flow that would re-render the entire UI when any state changes with varying
degrees of success (since applying this pattern on top of another framework is
pretty fragile). So React was immediately appealing to me. And Flux and later
redux was the evolution of that idea taken to another level.

As for the article itself I was a bit confused by it as from the
clarifications at the bottom it makes the assumption that the reader is
building a trivial application with minimal UI state. There are thousands of
boring companies like mine not named Youtube or Facebook building complex web
applications and it wasn't until I read the clarification at the bottom that I
realized the whole article wasn't aimed at me.

------
pfooti
So, I've been working with rich text editors in particular recently, and I can
tell you one thing: contenteditable is a gigantic pain in the rear. It's
uneven across platforms what it transforms user intent into (control-B: do you
get a <b> or a <strong>?), it handles paste events sloppily, and marking inner
fragments as not contenteditable (say an image embed, atmention or some other
block) is weird, especially if that item is the last thing in the list.

Contenteditable is so annoying that the first thing most rich text editors
seem to do is make their own selection state manager, because the native range
implementation in the DOM is crap. Medium in particular pretty loudly got rid
of it entirely, and that's the direction most modern web-based rich text
editors are going.

So. The best thing to do here is find some kind of framework that helps you
map from user intent into mutating a data model, and a separate way to
translate that data model into the DOM. This sounds like a framework to me,
and it especially sounds like one if you want it to work on lots of platforms.

Similarly, sure: I don't need a framework to do DOM manipulation. But I've
been using angular (1.x) for a few years now, and I can say: it makes life a
_lot_ easier. If I don't have to debug lines of javascript looking for where
different elements get injected into the DOM, I'm happy. I can just look at
the template file for the html code I'm editing and see where classes get
programatically changed based on state, not because I'm deep inside some
MutationObserver, but because I can read an ng-class directive. Easy pie.

I sure don't _need_ a framework. I could also program in ones and zeroes.
Speaking as someone who's been doing web stuff since the 90s, where the first
framework I ever wrote was a bunch of DIY C libraries to make writing cgi-
scripts easier, I can say with all honesty: using a framework makes life
easier.

Sure, it's annoying to learn, and sometimes the opinions of the framework are
different from your opinions. That's why I use angular instead of ember
(because I'm not a rails person, for the most part). Take your pick, learn it
well, and it will make your life easier.

And if you're that worried about the weight of your library, stop loading so
many hero images uncompressed.

(I will grant edge cases where library size is a big deal, but it's more of a
premature optimization thing in most places, especially now that tree shaking
is starting to make its way back into our build tooling).

------
CameronBanga
Are Slack Files an official blog from Slack? For a second, I thought looking
at the URL that this was just a URL for a Slack snippet or something similar.

~~~
philfreo
No, if you look in the footer you'll see it says "Public file shared from
Slack", which I think just means someone posted this document using Slack

~~~
mortenjorck
Weird, so Slack effectively has a stealth Medium competitor now?

------
zer00eyz
I have been avoiding JS for years (not out of hate, just the job) and every
time I dabble in the node/js framework ecosystem I end up turning away
frustrated.

I have a few small personal projects that I haven't started due to lack of
desire in building the front end I want, after reading this I'm going to give
them a shot and see how far I can go with out all the goodies!

~~~
vskarine
I was in the same boat, tried reading tutorials for Angluar/Ember/Backbone/etc
and wanted to throw up because of all the complexity and prior web
experience/knowledge that they expect you to know. But then tried Meteor and
everything there made a lot of sense to me.

~~~
quackware
Meteor is a great stepping stone to the more complicated JavaScript ecosystem
of node/react/angular/webpack etc. I was a huge fan of it when I first started
web development, but all its limitations caused me to switch over to using the
above mentioned technologies. I highly recommend it to any beginner to web
dev!

------
bikamonki
This eternal argument of js framework/non-framework reminds me of them old
days of static html when Dreamweaver will just munch a PSD file and spit out
working HTML + Images + CSS. Some of us hated it b/c the output was bloated,
super hard to read/maintain, etc. So, some of us just went ahead and coded
from scratch. I guess the preference has to do with a need to 'understand'
what's going on. Tools like React or frameworks like Angular are just the
modern Dreamweavers: don't mind the inner-workings, just follow the rules and
get the desired output.

If I can recommend a js framework so flexible it feels like a non-framework
I'd say go and learn Backbone.js It's like a flat green Lego table, no
assumptions, just structure.

~~~
ChrisDutrow
I feel this way about backbone as well. Before using backbone, I wrote complex
user interfaces in Javascript/JQuery. They were a mess.

Backbone allowed me to write cleaner code without forcing me to do anything. I
still use backbone today. The code tends to be very verbose, but the trade-off
is that it is not heavy handed. I never have to "hack" around backbone, it
just gets out of my way when I want it to.

This fits my personal preferences, I prefer simple, verbose code. I also tend
to prefer lower-level to high level. For example, I don't like ORMs. For me,
it is easier to explicitly express how I want the data to be indexed and move
in and out of a database as opposed to have an ORM manage it for me... because
if it doesn't do it right, its very difficult for me to learn how to get the
ORM to do what I want it to do. I also prefer more keystrokes and fewer
"things to have to know about" to fewer keystrokes with many things going on
behind the scenes that I cannot see. I think I may be in the minority in this
respect?

I understand that there may be better frameworks now, but I feel I need to
commit to something and stick with it, I think the cost of re-writing things
all the time is too high. I think its faster in the long run to use an old
framework that's 50% slower than switch to a better framework every two years.

For reference, this is the main project I use backbone on:
[https://demo.enterprisejazz.com/](https://demo.enterprisejazz.com/)

~~~
bikamonki
>I think the cost of re-writing things all the time is too high.

Exactly. So, unless it stops running on modern browsers, the code should
continue to execute and provide a complete solution. Although, I do try to
keep Backbone versions up to date.

I also plan to continue using Backbone but I do want to learn a 'view' tool to
improve performance of UI-rich apps. React seems too big and complicated, I am
more inclined towards vue.js or mithril.js.

I checked your demo, in case you have not done so already here are 3 tweaks
I've done to make Backbone run faster: \- Select el already on DOM for a
view's el instead of render/append. This is a huge performance improvement. \-
For big collections use plain JS array instead of Backbone native collection.
You'll trade some methods for performance, but such methods can be re-
implemented with Underscore. \- Ditch the router if you need dynamic routes.

Here's an experiment of a classic listings app. After selecting a city, 5000
random listings are loaded at once into a JS array, after that I use
Underscore for search/sort. Records in this example come from a static demo
file. A red warning pops up with total download time and total processing time
(lapse from download ready to array populated and ready for use). When I used
Backbone collection processing time would be between 5-9 seconds (depends on
processor speed).

[http://edwardspooner.com/items/index.html](http://edwardspooner.com/items/index.html)

~~~
ChrisDutrow
I actually do use an el already in the DOM. To be honest, I do it that way
because the code looks cleaner and is easier for me to understand that way, I
didn't know it was faster. The only caveat I've found with that way is that if
you remove a view and add an identical one, the events from the old view still
get fired. For views where that happens, I actually use a custom extension of
the original views that has a special destroy method that gets called which
unbinds events and stuff.

When first learning backbone, I played around with the router, but I don't use
it at all now. It was pretty hard for me to use and didn't seem to have much
of a point. I suspect for many use cases, if you really need the url path to
change, reloading the page from the server would be fine. But of course my
perspective comes from only the use cases that I've worked with.

I actually mostly don't use backbone to organize the data, mostly only to
display the data. The demo you looked at actually has little mini database
implemented in the background using arrays and objects (used as maps). I
mostly use collections for things that go right on the screen. I also (mostly)
don't use backbone's ability to sync data with the server. I have a module
that uses Jquery's Ajax for this instead. The reason I don't use backbone for
this is that I found their way of doing it breaks down with more complex
relationships within the data.

I mainly use backbone as a utility for message passing (update a model and one
place, and messages are passed so everywhere else it is displayed updates
also). And for organization: the views, pieces of the DOM within a view, and
events.

Also, I use Marionette.js, not pure Backbone.js

...I'm not trying to say my way of doing things is the right way, just
relating what I do and why for discussions sake.

Oh, and I looked at your demo. That is really cool. That's really fast for so
many records.

------
carsongross
Most people probably don't need to write much app-land javascript at all to
have reasonable UX:

[http://intercoolerjs.org](http://intercoolerjs.org)

Bonus: you get HATEOAS without knowing what HATEOAS means.

------
tomc1985
This! This times a million times!!~!

Seriously. The javascript world is INSANE. All these frameworks and few truly
need them... node.js package management is a mess... yet how many of these
coders will take the time to learn real ES5? It really isn't that hard of a
language.

I feel like calling oneself a "javascript" expert practically requires
knowledge of a framework or too. This is saddening, because Javascript itself
is a rich language with a ridiculously fast runtime, yet everyone wants to
work with a framework when a head full of sound theory and experience will do
:/

~~~
fizixer
As a javascript-noob, not even jquery? I've heard jquery solved so many
headaches.

~~~
niuzeta
The major criticism of jquery comes from its "overhead" which comes from
wrapping a lot of functionalities onto relatively(at the time of its onset)
large file[1]. While they were legitimate(internet was slow) at the time, at
its cost jquery worked as a go-to-solution for browser incompatibility. This
was a major issue which jquery solved magnificently.

And frankly, a significant portion of jquery usages are a very limited set of
functionalities: selection, class manipulation, some visible on/off, _AJAX and
promises_. A lot of those don't necessarily need jquery[2]. Some hard-core
guys go so far as to separately download only modules[3] which works.

Honestly, I wouldn't mind calling a significant portion of jquery to be "pure
javascript" as it lets me not worry about browser compatibilities and pleasant
stuff that _should have been part of standard library_. ES6 is supposedly fix
most of the complaints, but whether browsers will support them or not is a
different question.

[1] [https://mathiasbynens.be/demo/jquery-
size](https://mathiasbynens.be/demo/jquery-size) has a nice tabular info on
how large jquery file sizes were.

[2] [http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/) is
a widely cited source.

[3]
[https://github.com/jquery/jquery/tree/master/src](https://github.com/jquery/jquery/tree/master/src),
go nuts.

------
seanwilson
So instead of using an established framework the post is suggesting possibly
using these things?

MutationObserver for UI updates + Fetch API for networking + History API and a
custom router for routing + CSS for animations + HTTP/2 instead of Webpack +
npm for building + JSPM for package management + multiple polyfills for
browser support for all this

Besides not having a name and a dedicated site, how is the above any different
from using a framework? Once you've worked out how to get all these things to
play nice together, are you really saving any time from just using an
established framework that's done the work for you in the first place (i.e.
they'll use some of this stuff under the hood already)?

Just because you're leaning on native features instead of library features
doesn't make it any different from using a framework. At least with an
existing framework you know it's battle tested, has good documentation, has an
active community and is easier to maintain for new programmers on the team.

------
namuol
React is popular because it re-frames the meat and potatoes of frontend dev as
a simple input -> output problem. VDOM merely helps make this approach
performant at scale - it has little to do with why people actually use React.

Abusing MutationObserver to get "easy" 2-way data binding is precisely the
sort of antipattern that React & Friends would have discouraged.

------
nbevans
Whilst predictably this HN thread has turned into a bit of a flame war I would
like to point out the article certainly made one indisputable point. That
HTTP/2 is going to change how modern web apps are written all over again. So
then we'll all need another new framework.

------
dmix
One of the big ones is build tools.

You don't need Gulp/Grunt/etc for 90% of the stuff I've seen it used for. They
could be replaced with a Makefile plus a bunch of standard unix utilities.

You shouldn't have to install 90 libraries in order to build/install/run your
program.

------
hawkice
For those who read the comment about Object.observe: Don't use that. It's
being removed from everywhere it exists, and pulled from the standards
recommendation. Just have a set(state) function that calls your callback
instead, it's like three lines of code.

------
jrochkind1
I really wish I didn't need a javascript framework, but I find this essay
unpersuasive. He doens't seem to deal with the same kinds of problems I do.
But I like that he's making the argument, and trying to pull out the parts
where the web API has gotten a lot better. It's approaching maybe. I really do
wish.

If we're lucky, maybe we can come up with something lighter weight
(conceptually, and in terms of build tools needed, as much as in byte size)
that is closer to the built-in browser API. I definitely don't feel like I can
do what I need in a sane way with nothing but the browser API though.

------
intrasight
Back in the late 90s a bunch of us create an architecture we named AJAX. Now
in 2016 a bunch of us are still using AJAX to build web apps that work just
fine and are probably faster than these "frameworks".

------
kup0
I don't think frameworks and tools are the problem. I have dealt with the same
frustrations about these huge tool-chains but I've always seen it all boil
down to one key point: the problem is not the tools- it is not choosing the
right tools for the project at hand. Then you get websites and apps that
really bloat up because of the overkill or poor choices.

There's the whole side issue of progressive enhancement and/or making a non-JS
version of a site, but I feel like those ideals are now dead- whether it's due
to it being unfeasible, unaffordable, or something else.

~~~
samtho
Its ROI. For any new company starting off, they will quickly realize that all
non-js agents are either bots or very low-powered machines. With many new
companies, who base their entire existence on the web and customers' ability
to access it, these two groups are not their target audience so why bother
making a JS free, static site when you don't need those customers' business?

On the flip side, government sites are (or at least should be) developed with
a high degree of accessibility in mind due to laws that typically prevent
anything less. Their reach is much higher and their audience is potentially
every citizen in their jurisdiction.

------
calsy
Is it possible for someone to point me in the direction of a nice JS project
template that does not use a framework?

I would still like all the core elements of a decent JS project such as
package manager, bundler, templating BUT without the overkill of a new
framework. A project template that allows you to simply write HTML, CSS and JS
modules in an organised fashion.

A reference to a Github repo or online doc would be awesome. With so much JS
news and information these days its really hard to find any info without the
words react or angular or whatever. Appreciate any help from you knowledgable
folks.

------
inspiraller
I agree. I enjoy developing the quickest route from a-z. I can write
javascript. I know the dom, that its quicker to update one large dom container
than it is to update many smaller elements. I have worked with and understand
ajax, that rewriting a dom node before unbinding any events creates browser
memory leaks causing it to eventually crash. I would not know these things if
i had coded with the prescribed framework. If the argument for using them is
to have team coding standards then have team coding standards. The framework
creates its own problems.

------
_alexander_
Ok, we don't need frameworks, however what should we use in order to build
complex UI applications? Own solutions? And know imagine that in every project
you build your own skeleton and architecture...

~~~
jqm
I think the point is for complex UI applications (or a team with
interchangeable members) you would use a framework. But for less complex
applications you might very well not.

Enjoyed this article. I like JavaScript, I use it almost daily, I'd like to
learn React or Angular but just haven't had the real need. For the amount of
JavaScript in the apps I build there just doesn't seem to be the payoff. I did
venture into npm. What a nightmare of goop and time wasting. Although there
were some cool utilities the amount of time setting up and dealing with in
most cases didn't really pay out.

Don't manipulate the DOM. Why not? Works fine for what I do. Maintainability.
Maybe. But well organized code is well organized. If there were a lot more of
it this probably becomes a valid point but JS doesn't do everything in my
apps. It does the things JS was originally designed to do.

I figure when the dust settles I'll probably dive into a framework. But right
now stored database procedures, database triggers, a light Flask/Bottle layer
and judicious use of well organized jQuery/ native JS works really well and
doesn't have a bunch of unneeded parts.

Then again I'm still using Slackware. I like things simple. The less
abstraction and "helpfulness" between me and what I'm trying to get done the
better. Simple, powerful, modifiable tools without a lot of glitz and overhead
are my preference. I mistrust black boxes and complexity. Maybe React is the
kind of tool that could be useful... don't know. Might look into at some point
when I feel it's reached puberty.

------
sorpaas
Greenspun's tenth rule: Any sufficiently complicated C or Fortran program
contains an ad hoc, informally-specified, bug-ridden, slow implementation of
half of Common Lisp.

Now let's add Javascript to the list.

~~~
Dr_tldr
The good news is that with V8 and ES2015, we now have a formalized, (fairly)
fast, and tolerably buggy implementation of Half of Common Lisp. Oh yeah, and
it runs natively on devices owned by literally billions of people.

------
sshbio
I like this way to do, preventing complexity.

There may still be things that can not be achieved JavaScript, but aside from
those cases, I would even add "you (probably) don't need JavaScript".

------
hellofunk
>Virtual DOM is efficient and has good performance, but native DOM interaction
is insanely fast and your users will not notice any difference.

As soon as I saw this, I knew there were limits to this author's knowledge on
the subject. React was a _requirement_ for the low-latency UI we built for a
major commercial app and without it (or a similar library) the user experience
we shot for would have been impossible.

~~~
moron4hire
React Virtual DOM is faster than rebuilding the entire DOM from scratch, yes.
But making edits to DOM manually will be faster with native browser functions
and no VDOM diffing overhead.

------
statictype
React doesn't exist to handle the massive amounts of data that facebook has.

React exists to make complex UIs easier to build and maintain.

Being able to just write the code once to render a UI from some state and then
just reloading the entire UI when the state changes is an incredible
simplification of your code.

That the author kind of misses this point makes me pay less attention to the
rest of the post.

~~~
timr
_" That the author kind of misses this point makes me pay less attention to
the rest of the post."_

Too bad. The author addressed everything you said. You just didn't read past
the sentence you quoted.

Nowhere does the piece imply that you should render every state change server-
side. In fact, it goes on to show, with specific examples, of how you can get
data-binding and partial-update behavior with web-native APIs. The argument is
that most people don't need React, not that they don't need AJAX or data
binding.

~~~
dang
I think I agree with you, but your comment breaks the HN guidelines twice: the
first paragraph is uncivil and the final one goes on about getting downvoted.
It also pretty much breaks the injunction against "did you even read the
article" comments, so that's three. Please don't do these things when
commenting here, regardless of how irritatingly wrong someone else may be.

The middle paragraph is helpful and fine, and the comment would have been much
better with just that.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
timr
The first paragraph wasn't uncivil. He _said_ that he didn't read past the
first few sentences of the article:

 _" That the author kind of misses this point makes me pay less attention to
the rest of the post."_

If they had read the rest of the post, they would have seen that their
argument was addressed.

You're being unfair here. The top-rated comment is from someone
mischaracterizing the piece, saying he didn't read it...and you're calling me
out for pointing that out.

~~~
dang
I don't see that. Actually the only bit that seems uncivil to me is just "You
just didn't read past the sentence you quoted." You can't know that, and such
statements are the internet comment equivalent of elbowing.

~~~
timr
I was responding to the last line of his comment, coupled with the fact that
the comment completely mischaracterized the article based on a single line,
early in the piece.

I admit that the last line is unnecessary. I'll remove it.

~~~
d0m
(I didn't downvote you, I really don't mind, but it did sound aggressive).

Here's what you wrote: >> Too bad. The author addressed everything you said.
You just didn't read past the sentence you quoted.

>> Nowhere does the piece imply that you should render every state change
server-side. In fact, it goes on to show, with specific examples, of how you
can get data-binding and partial-update behavior with web-native APIs. The
argument is that most people don't need React, not that they don't need AJAX
or data binding.

Here's a political rewrite (Keep in mind I'm not a native english speaker):

It seems that the author addressed your points later in the article. For
instance, rather than rendering every state change on the server-side, it
explains how you can get data-binding and partial-update behavior with web-
native APIS.

The main argument of the article is that most people don't need React, not
necessarily that they don't need AJAX or data binding.

------
evan_
This looks like a great blueprint to spend way too much time writing an app
that is un-maintainable and only works in a few browsers.

------
matchagaucho
Brilliant. I get burned by cross browser issues when going without frameworks.
Would love to work exclusively with Web API.

------
codeisawesome
I don't agree with the sum of it's parts, but I like some of the...
components... in this article.

------
apeace
contenteditable and MutationObserver? What about <input> and onchange?

------
bricss
Absolutely agree. Also wanna notice that is React is the only one V from the
MVC. At least it's weight now more then Angular. Backbone can even do
everything and twice time more then React can do.

------
hmsync
In some special environment, such as Electron (Atom shell), that can ignore
the cross-browser problem, writing application using native Web API and DOM
API and ES6 is elegant and effective.

------
__s
openEtG doesn't even use jQuery, it's been alright. Only library it uses is
pixijs, & a slimmed down version at that. Originally everything went through
canvas/pixijs but over time only a few views aren't DOM

[http://etg.dek.im](http://etg.dek.im) for site

[http://github.com/serprex/openEtG](http://github.com/serprex/openEtG) for
source

It does a lot of dynamic content generation, which dom.js has proved
sufficient for

------
CommanderData
You 'probably' don't need one but 'should' use one to save yourself countless
hours re-inventing the wheel that frameworks solve.

The best thing is to try and use minimal frameworks and libraries and justify
every single one - Which I'm sure most devs already do. jQuery is still rather
justifiable. Yes, you can replace functions with JavaScript today but you'll
end up with similar looking functions.

I recently added Transit to animate using CSS3, the alternative would be to
write each animation effect I use in CSS3 down to the duration! If I need to
change the ease I spend 5x the time doing so - From a devs perspective no,
just no.

------
bitwize
If you're looking for work and the hiring manager fishes for names of
JavaScript frameworks you've used, you need a JavaScript framework.

------
known
+1 [http://www.xul.fr/ajax-frameworks.html](http://www.xul.fr/ajax-
frameworks.html)

------
callesgg
I might not need a framework but that does not mean that there is no value to
it.

I don't really need a smartphone, but it is quite useful.

------
pier25
Yeah why not? Let's reinvent the wheel every fucking time.

I'm sure your clients and your family will love that.

------
dandare
If the author thinks TypeScript is a framework there is no need to waste time
reading the article.

------
AlwaysBCoding
You probably don't need Redux __ __* but React is awesome

------
proc0
npm install --save-dev vanilla-js-loader

------
petecox
vanilla-js.com

~~~
jqm
That's pretty funny.

------
gjolund
I'm really glad I don't have to work with people who think like this.

You don't NEED a framework, just like you could theoretically build a car from
scratch.

If your app isn't complex enough to merit using a framework, then you aren't
really building something worth talking about.

Frameworks do exactly what they say, provide a common framework for your team
to work off of while they build a complex application.

I feel like most of the FUD around JS frameworks comes from simple people
building simple apps and wondering why everything needs to be so complicated.
Frameworks enforce structure, which becomes more and more important as your
app grows in complexity.

Frankly it would be great for me if this train of though picked up steam,
plenty of contract work from companies who can't maintain their "homegrown"
frameworks anymore.

~~~
tomc1985
How funny, then, that the framework people can't seem to standardize over
anything more than jquery or react?

If layers upon layers of frameworks really were the best approach for complex
applications then why can't people get behind one clear winner? Why does there
seem to be a new framework popping up all that damn time? How much money has
been lost simply keeping up with the artificially hastened pace of change?

Now, I personally have nothing against frameworks individually, but
collectively people seem to pile them on top of each other. One is enough --
the beauty of web standards is that there is a common language that one simply
needs to speak to access.

You are profiting from the community's collective lack of technical rigor.

~~~
gjolund
I profit from people's lack of technical expertise every day, and I'm proud of
it.

People come to me because they acknowledge that they don't understand the
problems they are faced with, and I provide maintainable solutions that work
for years after the contract has been completed.

How?

I choose a widely adopted framework that is suited to the task and follow the
best practices of the community that developed it.

That way when I leave people don't say my app is "A spaghetti be-spoke js app"
but instead "Its an angular/ember/react-redux app." See the difference?

One is the opinions of a single developer (or small team), the other is the
culmination of hundreds of open source developers working together to solve
common problems in a maintainable and performant way.

~~~
tomc1985
I think you're touching on exactly the problem: a 'spaghetti be-spoke' js app.
Can a JS app be anything but? Javascript is a language for the view layer.
It's supposed to be the minimal shim on top of LAMP or Rails or whatever, to
bridge the gap between static HTML and dynamic movement. It was never supposed
to run the entire app!

~~~
gjolund
You are ignoring huge problems.

How does a LAMP/RAILS app share server side rendering code with the client?

How does a LAMP/RAILS app share data models between the server and client?

How does a LAMP/RAILS app provide search engines with indexable dynamic pages?

How does a LAMP/RAILS app preserve client state between page reloads?

How does a LAMP/RAILS app synchronize client state between multiple connected
clients?

Your lack of experience working in a professional front-end environment is
telling, and is the source of your confusion.

~~~
tomc1985
_How does a LAMP /RAILS app share server side rendering code with the client?_

It doesn't, because I don't need/want it to. Any data that needs to be passed
to the client is rendered as JSON. Client-side get committed to the database
via AJAX (to my buzzword-o-rific REST api), or with good-ol' POST.

 _How does a LAMP /RAILS app share data models between the server and client?_

Again, not needed.

 _How does a LAMP /RAILS app provide search engines with indexable dynamic
pages?_

Uh, through clever use of jquery AJAX and postgres indices?

 _How does a LAMP /RAILS app preserve client state between page reloads?_

A serverside redis cache? In the database? In the cookie? LocalStorage? C'mon
man.

 _How does a LAMP /RAILS app synchronize client state between multiple
connected clients?_

By pushing a hash with current state to all clients via polling? Websockets?
Whatsitcalled where you don't close the original HTTP connection? Did you know
postgres has some pretty awesome realtime pubsub tech? I suppose if I have
some extra time I could send changesets and load them with $.merge()

...

I just want you to know that you are doing nothing to improve my image of the
JS-scene-writ-large as immature, spoiled, and childish. There are isolated
pockets of brilliance, for sure, but the everyday talk scares me.

~~~
morgante
We didn't collectively decide to move rendering to the client side for no
reason. It is unquestionably more complex to build a SPA than to have a
traditional web app.

We did it because users demand it. A SPA feels substantially faster and more
reactive. Users notice.

If Gmail used your approach, it never would have succeeded.

> _How does a LAMP /RAILS app provide search engines with indexable dynamic
> pages?_ Uh, through clever use of jquery AJAX and postgres indices?

I have to assume you're just throwing out terms you've heard of but never
understood. Database indexes have literally nothing to do with making your
site indexable for search engines.

~~~
ssmoot
Most SPAs feel substantially slower IME.

The users didn't demand this. They were perfectly happy when you delivered a
website that performed a full-round trip in 50ms a decade ago containing more
data than your average SPA can handle before choking on it.

The users want it to work. They want it to be fast. They want it to be pretty.
That's about it.

I'm tired of hearing about why GMail succeeded. It's revisionist. GMail
succeeded because they had the best spam filtering, in a simple design, and
you were probably using Google search anyways. Plus Hotmail was always going
down for hours (days?) at a time.

I've never experienced bugs in the web like I have with SPAs. I'm very
thankful that even if my budgeting software is built in Ember, making it slow
and buggy, my bank's site isn't. Making it predictable, and very fast to
render. Time to Render is atrocious on many "modern" sites.

~~~
oblio
Gmail also offered 1GB+ at a time when generous competitors offered 100MB.

~~~
ssmoot
Great point. In the time before Dropbox, S3, etc Email was THE way to share
your 50Mb zip file. And routinely having to clean your mailbox because you ran
out of storage was a huge pain.

------
keeganmccallum
I think the flame war that has erupted has a pretty simple explanation: some
people forget the state of javascript just a few years ago. I am currently in
the process of moving my team away from the monolithic dojo framework towards
using more of the vanilla web standards, but I think dojo was a great choice
at the time. The pains of cross-browser support, terrible vanilla APIs that
were completely different in IE8 vs the rest of the web, etc. made frameworks
"the way to go" in the past, and that's set us off in the direction we are
going today of immediately reaching for one. Articles like this one are great
in that they are helping to educate people on the power and ease of use that
the modern web has to offer, but I can 100% see why people are going to
skeptical for a while longer when it comes to using only vanilla javascript.

------
blue_dinner
If you don't use one and have a complex app, it will eventually turn into a
spaghetti mess of callbacks. You will end up writing your own framework that
hasn't been battle tested on thousands of sites.

For simple apps, it's probably not needed. The issue also is that you app
could be really simple now, but have features added to it regularly making it
complex.

------
frik
I wrote about that about 4 years ago, often called vanilla JS.

Back then everyone on StackOverflow was still completely bought into the
JQuery mission. I often see it when people don't fully understand something,
they choose a framework.

------
joesmo
While we're at it, let's just write everything in spaghetti ASP because you
don't need a [insert programming language here] framework.

