[ericb]

We just did something crazy. We dropped the Ember app that was 3/4th's done in favor of plain JQuery and Rails 6.

I'm just done maintaining two apps instead of one and all the hell that involves. And the Javascript ecosystem can keep rolling that Sisyphean upgrade treadmill with deploy dependencies and promises everywhere and I promise to use it as little as possible. Because it is just a giant time suck. Tut tut if you will, but we are moving twice as fast now.

No one sings of your glorious battles maintaining JS apps in the halls of Valhalla.

[Aperocky]

You don’t need jquery either, native JS works just fine for most simple interactions like startup apps.

Time to say no to npm and packages like is_odd that somehow are depended on by thousands of packages. A sign of collective hysteria.

[spookthesunset]

> native JS works just fine for most simple interactions like startup apps

Oh god please don't. I worked with a startup whose "lead" (i.e. the person with the most seniority, not the smartest) insisted the whole front-end could be done with plain JS ("angular, jquery, etc... just useless bloat!!!" said the lead developer). What resulted was the biggest rats-nest soup of untraceable mess I've seen in a while. The only person on the team who understood the system was the "lead" developer. Changes took forever. Bug count was through the roof.

When you say "you don't need a framework", what you are really saying is "I'll build my own framework". Because you will be building a framework. And trust me, your framework will not be as good as what is on the market. And when you leave, all developers who didn't leave the company will rip all your shit out and replace it with a "real" framework -- all while cursing your name under their breath.

Your job at a startup is to get product-market fit. Not invent your own framework.

[sjy]

Plenty of people create rats nests using frameworks, too. Would forcing the “most senior but not the smartest” person to use a framework they don’t like really have fixed your problems?

[hnzix]

A framework at least encourages a coherent pattern.

[spookthesunset]

Even non-framework people make frameworks. Just implicitly. At least a marginally good “real” one probably had somebody think hard about it and a great one has a community around it with plenty of devs that can jump right in on your project. All of them will have better documentation and you can get questions answered on stackoverflow. No such luck with the ivory tower anti-framework bozo’s pet framework.

God I’ve worked for too many startups where some “anti-framework” bozo declared frameworks as unneeded bloat.

Avoid these startups at all cost cause whoever hired the anti framework bozo is also a bozo and whoever hired that bozo is also a bozo. Fish rots from the top.

Not a good look for a startup with more important things to do than pushing far-out technology agendas.

[ericb]

Totally agree you don't need jQuery. My criteria for inclusion was "does it make our development even slightly faster, on balance."

The answer was yes in this case. Perhaps that's just the familiarity of it, but at the end of the day, faster is faster.

I'd say my new philosophy is: let our competitors optimize for purity or trendiness or even render time while we optimize for development speed.

[ibeckermayer]

Look here son you don’t need jQuery. Go outside, dig up some Silicon, bake up some wafers, design and manufacture a cpu, strap it to a motherboard, hand-smelt some housing, throw some coal in the generator, write an OS, handcraft a browser, and use plain vanilla HTML/CSS/JS. Fucking kids these days with their _frameworks_

[sequoia]

Avoid adding tons of tiny JS deps that require maintenance= move faster

Avoid adding jQuery & write your own slideUp, slideDown etc. = move slower

[BalinKing]

Equating jQuery and is_odd feels extremely disingenuous to me, and gives the argument a purely-dogmatic feel.

[3pt14159]

I have a couple of questions for you:

1. Was your Rails app solely an API or did it also serve HTML/CSS on first load?

2. Did you build a reusable component framework for your Ember app?

3. Did you follow something like JSON API[0] and use EmberData to hook into it?

I've found that Ember apps with a Rails backend API actually fit together pretty nicely. Don't get me wrong, I like simple. I don't even have a single line of JS on my personal site nor do I use any libraries to generate it (I wrote my own static site compiler), but I've seen JQuery in practice and it makes me unhappy as the app grows because so often things get inconsistent in terms of UI. Plus there seems to be less overall structure of the frontend.

[0] https://jsonapi.org

[ericb]

1. Yes, just API/SPA 2. Yes 3. Yes

The decision is purely pragmatic, not about taste, purity, or anything else. If I can develop faster up to the point where I have the budget to worry about those other concerns, that would be a win.

[aantix]

Stimulus Reflex is probably what you want. https://github.com/hopsoft/stimulus_reflex

Lightweight, real-time updates using the same Rails views already built.

[swat535]

Soo.. the response to OP's post regarding the burden of maintaining systems built with JS frameworks is.. yet another unknown JS framework that will cease to exist in 3 months from now on?

[aantix]

Not exactly.

The Framework is Rails focused in that 1) Event handling is setup by Stimulus (a basecamp js framework), 2) Rendering is done server-side, transparently sent client side via ActionCable with dom-diffing automatically applied.

It's a way of achieving a real-time app while still maintaining performance and reusing your Rails server-side views.

[woutr_be]

I was so used to building SPAs and APIs, that it seemed the default to me. But I always felt it was slowing me down, I had to switch between multiple terminals, multiple editor windows, things had to be tested twice (on both FE and BE). I dropped that for just plain old MVC on the backend, and I find myself moving a lot fast now. I still need some JavaScript for things like dropdown, or the occasional AJAX call, but other than that, I actively try to avoid it.

[NightlyDev]

This is very true for me too. I used Vue frontend and php backend, it makes it more fun to work on the frontend, but it's definitely slower for me compared to just rendering everything serverside.

The more I learned, the slower I became. I think everyone who has been doing webdev for some years have experienced that.

[woutr_be]

In my recent project, I try to do as much as possible through serverside rendering, obviously there are things that still require JavaScript. I just extract those out as components. Right now I’m using WebComponents, but you can easily use Vue if you wanted.

Just treat it as a secondary layer for HTML, not the primary one.

[jbob2000]

You must have a small development team that turns over infrequently.

The purpose of cultivating development ecosystems is to attract developers, and quickly. We migrated to Angular 6 and were able to hire 5 front end developers and get them productive in 2 months.

[ericb]

You're not wrong about the size of the dev team and turnover.

At the same time, I'm not sure if taking 2 months to get productive is a win? Wasn't one of the angular "upgrades" a total rewrite? What is the overhead of maintaining a second tightly coupled front-end app. I found doubling the surface area seemed to square the effort, not double it. How much of that productivity is illusory and could be done with fewer people?

Some folks are upvoting the heck out of my comment. I presume some portion of those are devs who might like working in a place without JS dependency package/upgrade/language/promise hell?

[jbob2000]

I work for an enterprise company with more than 70,000 employees. Standing up a team and getting them productive in 2 months is basically unheard of at this level.

This community is heavily biased to small companies, startups, and students. I'd be hesitant to judge their approval as affirmations that you are doing the "right thing".

[ericb]

> affirmations that you are doing the "right thing."

I'm not really looking for approbations--I'm happy to play this business game with a speed optimized team and see how my strategy fairs on merits against competitors maintaining two apps to my one. I'll make that bet all day long.

I'd say hold up and question your assumption that there is a "right thing" at all.

In terms of the perception of what is the "right thing", and the startup bias of this place, that could be true. I'd add though, that there's a reason houses are not made of rebar reinforced concrete. It's too expensive to work and rework. From that, I'd generalize that certain architectural patterns work better in some cases, and in others they are overkill. Wood works fine, and it is faster and cheaper to build with. And if you have to knock it down, you can rebuild the next one for cheap too. Neither is "right."

[rusticpenn]

It depends a lot on the customers. The tools we make are mostly B2B and are "premium". We are never first to market, but our tools are trusted over our "competitiors" ( I have put that in quotes and one of our competitors owns 30% of our firm), and this means get more customers because of the trust in robust tools (rebar reinforced concrete).