You probably don't need that hip web framework | Hacker News Reader

You probably don't need that hip web framework

char.gd

73 pointsbfoks53 comments

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!

Doesn't it ever backfire though? I've used plenty of SPAs that shouldn't have been, forcing me to wait for the page to load twice and increasing frustration. If they'd just stuck some AJAX where appropriate the experience would be so much better.

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.

Web components

I guess the main issue to be argued here is a poorly defined "it". What does every app need? State management? Lightning-fast interface updates? Counts incrementing in three places at once?

For the 10-20% of apps that get built in React/Vue that actually "need it", I believe that 90% of them would be better served by Rails + Turbolinks 5 + Stimulus.

Most of the people who rally behind the SPAs for everything mindset came up at the peak hype moment for React and friends. There's an unfortunate tendency to believe that the thing you're thinking about right now is more important than it actually is.

If you're not working at a large company, you most likely do not need these tools. Nobody is going to come in the night and take them from you, but boy, everyone would iterate a lot faster if they didn't spend so much time bikeshedding and obsessing about state mutation.

That sounds exactly like the Rails + Vue setup we are using on our current project. Its basically 90% of a standard admin style interface which we had up and running in lightning speed using the great, but boring activeAdmin. For the couple of pages that are very interaction heavy we serve a per-page Vue app. It really does feel like the perfect combo.

No.

Overly complex interfaces are part of the problem.

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.

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.

What's wrong with Apollo?

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.

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.

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.

Did anybody solve reusing single file components in a page? I tried to reuse two components in a single page and I had to inline the contents to the page I wanted them. Is there a way I could import them?

``` Singe file component 1: <template for component 1> <script for component 1>

Single file component 2: <template for component 2> <script for component 2> ```

``` {% include singlefilecomponent1 %} {% include singlefilecomponent2 %} ```

Isn't this how Facebook uses React most of the time as well?

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.

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.

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.

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.

I'm with you. Whenever I see posts like this, I can't help but think, "More job security for me."

You may be joking, but I really think some of these posts may be by design. Some of these frameworks are so easy to use and in skilled hands lead to such impressive results, that it becomes harder to get a competitive advantage with UX. A single developer can do today what once took a small team. Thus we see these fucked up ladder kicking posts where people are encouraged to go use last generation tech, so they get left in the dust by companies pushing ever forward. By the time they realize how far behind they’ve fallen, it’s too late.

> A single developer can do today what once took a small team.

When was this, in the 80's? Web productivity is just catching up to RAD platforms like Visual Basic in the 90's and still a lot more complicated than a good UI framework like Gtk/Qt.

The hard part in my experience is that a lot of teams don't know if they absolutely need it. I have worked on some projects that are more hype driven development using React/Redux/Sagas for a barely interactive webapp. It adds a ton of complexity for little to no benefit.

Can we stop grouping React, Redux and Sagas when discussing complexity/bloat? They all have totally different complexity profiles. For example React adds tons of software complexity but very little development complexity, whereas Redux is the polar opposite. And Saga is just a clusterfuck. I don't even understand how people can use it with a straight face.

Ok, but only if we can also stop saying React and Vue in the same breath. React is the spearhead of a galaxy of the biggest, heaviest, enterprisiest solutions in it's class, and it has it's place, but Vue is at it's best in lighter applications. You can do quite robust SPA development with Vue, but I'd argue it's even better when it's sprinkled lightly into a project, as a drop-in replacement for the ajaxing and updating we used to use jQuery for.

Some people just want a project with particular frameworks on their resume. "Professional side projects" carry more weight than something up on Github.

The audience for this post is at the opposite end of the market from you: two buddies building an MVP in a garage on a shoestring budget.

Genuinely curious: how long have you been doing web development and what technologies were you using before you found yourself absolutely needing React and co?

He could be right. The complexity of these front end frameworks decouples modules increases complexity by a significant amount. There is no way to prove that your current designs are the best possible way of solving your problem as designs by definition aren't proveable solutions.

To listen to him blindly is ignorant but to ignore him is just as perilous.

> My team absolutely needs React/Redux/Sagas/Webpack/whatever-you-want-to-hate-on-today

Then you're in the 1% of people that use these tools and actually need them. The point of articles like this isn't that they never make sense and nobody needs them, it's that they're way over used where they aren't needed.

> ...way over used where they aren't needed...

Bingo! Engineers love to change things like Scotty said, but they also blather on about if it aint broke, dont fix it?

But does the customer need it? To wait for the bundle to download and parse? Doesn't the customer deserve instant loading?

Because your team is the exception. Isn’t that implied by the title?

That's the thing though. Is my team really the exception? When you look at the highly immersive web that product managers and customers have come to expect, you simply can't build it without javascript. Once you've crossed that bridge, is it really easier to finagle some event handling using vanilla js/jquery or pull down create-react-app and get all the tooling necessary to 1-click-deploy to Heroku, S3 or Github pages and not have to deal with the multitude of bugs that hand rolled events and state can cause?

I am not sure exactly wtf a "highly immersive" experience is, what I do know is I'm shipping marketing pages that take like two minutes to load on "slow" connections and "old" phones (a.k.a. "our real users") and don't have top-of-page content or layout figured out (a.k.a. do their job) without a shitton of JS, CSS, a front-end "framework" and we can't ship new functionality (a.k.a. do our jobs) without a huge conversation about components, assets, and how the build process should work, disagreements on pet patterns.

I wish I could rebuild the home page in server-rendered HTML, a minimal hand-written set of JS and CSS for top-of page plus a fairly lean set for everything else, cut down to two fonts (headings and body text), preload the blocking assets, defer non-blocking assets, put pages and everything into object storage + CDN, and just... I dunno... serve our users. Any build tools or automation or content editor tools should lie on top of any of the above (Most of the "immersion" or whatever should remain intact, aside from what I see as bonuses: minor improvements to consistency in type and presentation).

I have no idea. But saying that you feel like you need a project is not a counterargument to the thesis: most teams don’t need it, even if some do. Maybe that’s right, or maybe it’s wrong, but your original comment was not a rebuttal.

You questioned why we keep seeing these arguments. Perhaps it’s because nobody on the other side cares to listen?

Why are there even "sides"? it's very obvious that this new tooling can be very useful for the modern Web. it's also apparent that a certain intersection of skill set and project requirements can do better with more classic tooling. why is there a continuous need to pull someone to one side or another? whatever happened to using the most appropriate tool for the job?

Because there are two or more sides to every debate.

The “most appropriate tool for the job” is exactly what the article is arguing for.

On the other hand, I'd say applications so trivial they couldn't benefit from something like React are the exception.

"When you're holding a hammer, everything looks like a nail."

There is a tendency for mgmt to sign up engineers to a vision quest with pre-established non-negotiable requirements whereby the customer expects what would be tantamount to solving all the world's problems in one easy to use, intuitive SPA that 'just works, always'. This is a big factor in the endless new framework releases, mutually-exclusive complexities and vulnerabilities.

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.

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

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.

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.

"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...

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.

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.

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

> 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.

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.

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).

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.

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.

Reply on news.ycombinator.com