Comment by brightball | Hacker News Reader

Comment by brightball | Hacker News Reader

Parent Full thread

100% agree on the common language front. The real challenge is when you're dealing with a language that has framework saturation, so there isn't really a "common" framework.

Ruby and Python have Rails and Django which goes a LOOOOONG way in fixing this problem. Not many languages have that one, dominant framework and usually that's because people keep inventing new ones to deal with shortcomings of current ones OR that the frameworks do so little on top of what the language already offers that it's easy to create your own. Javascript and PHP are clear cut cases for the latter since both languages are out of the box built for the web. jQuery was the last real unification in the Javascript world.

I don't entirely care which framework becomes dominant as much as I just want A framework to become dominant. React looks like it is gaining that momentum, but you immediately see the problem play out when there's a thread about how great React is followed by 100 "X is better because it doesn't handle Y the way that React does" followed by another post about how "X is worse because of the way it handles Y". There's something about the Javascript world that seems ready to create new frameworks instead of contributing to existing ones.

I took a sales class years ago and the biggest takeaway from it was "People buy pain relief". jQuery was dominant because it solved a huge pain point, cross browser compatibility, in a way that made natural sense for people working in the browser by using CSS references...AND it was built to run side by side with any other JS library (Prototype, Mootools, etc) so you could safely invest in learning it and know you'd be able to use it on any project that came along. During a time when IE6 compatibility was a big deal this was huge. During a time when a lot of people were trying to solve the problem and you'd inevitably end up on a project that chose one of the other dozen options, side by side compatibility was huge.

These were major points of pain relief that jQuery brought to the table and that's how it won.

The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and micro-libs are introduced every couple of months.

I'm really hoping that one of these React dialects will win out soon, as it's not really a "common language" until everything is mutually intelligible.

I'm not an expert in this area, but the impression that I've gotten from the React front is that one of the benefits and reason for traction it isn't a framework as much as a very good way to handle the view layer that's flexible enough to let people take liberties with the rest of their application design...and the way that it handles it works very smoothly with server side rendering as well.

Much like jQuery being able to work with other JS libraries smoothly was a big selling point, React seems to be providing a modular approach that's flexible enough to work with many of the more opinionated options out there without having to dictate everything about the application.

One of the biggest churn points around JS frameworks wanting to do things this way or that way, full single page app or hybrid server side / client side, integrate to existing site or build from scratch.

End of the day, the browser is the view layer. Most of the other frameworks that try to make it significantly more than that are always going to lose when being applied to existing systems or server side heavy systems.

The React approach is basically just simplifying and removing pain points. It's easier for Rails to define some standards on the server and database side because the server side is where the core logic of every application lives. You're not going to try to apply Rails to an existing application, so it doesn't have to worry about fighting that battle. That is a major consideration of client side code, which is why you're seeing more wide spread usage of React. It fits more use cases instead of trying to be Rails in the browser.

React is a UI component framework. The testing-in-isolation and composition you can do with React makes it very productive. It's good for reasoning about the fine details in a UI.

Yeah, it would be good to get a router and couple that with React. React is not a total solution for making a web app, and anyone that picks it up seriously will learn that very quickly.

We need lots more libraries like React that focus on one area of development and do that well rather than all these own-the-world frameworks that have both shiny and awkward parts. I want devs to do their front-end library selections very carefully and build a mosaic that fits together well for their app's particular use cases.

Doesn't seem like it will ever be that way for React to be honest. If you want a JS monolith try Ember. Angular 2 may also be that way since it uses Ember's CLI tool.

I love Ember - and one of the best things about it is its emphasis on convention over configuration. React is the exact opposite. While it's an amazing library, it only makes up one part of a front-end stack, which causes everyone to waste tons of time deciding on what the other parts should be.

A set of sane, accepted defaults would help the community tremendously. Personally, I'm hopeful that that's what React/Redux/Webpack turns out to be.

I'm going to take a leap and assume you've done some Rails work because Ember tends to have a lot of Rails users.

In Rails, there's a default view layer handled by ERB but it can be mixed and matched with HAML, Slim or any other view layer. Likewise, you can use ERB, HAML and Slim outside of Rails entirely.

There are frameworks like Meteor that let you have an interchangeable view layer. There are others that build the entire full stack framework around THEIR view layer.

If Meteor made React the default view layer...that would be a step towards unifying the fronts. One full stack system with a shared layer that can be use inside or outside of that particular framework.

This seems to be what meteor is trying to be. A fullstack. Crossing my fingers. Some devs want to pick and choose. I just want it all decided. Let me get to my app.

Yep. Meteor is taking the flexible approach. With React taking the View only approach it makes it easier to just plug in with Meteor.

https://www.meteor.com/tutorials/react/creating-an-app

It seems that what is happening with javascript frameworks is what has happened with python web frameworks, which have become splintered thereby dividing the community's mind share.

When I was first looking at python frameworks, I had to spend a not insignificant amount of time evaluating the various frameworks before deciding which one to hitch my wagon to. Had I decided on Ruby over Python, the choice would have been easy given the clear dominance of Rails.

I have limited time to learn new tools since coding is not my primary focus, and one thing that is holding me back from learning a javascript framework is trying to decide which one to dedicate my time to. They all have pros and cons, and I hope a dominant framework emerges soon, and the bulk of the community rallies around it to make it better and better.

Obligatory: https://xkcd.com/927/

I'm not convinced we need a monolithic, standard front-end web framework. If there is a framework, it should just be a collection of libraries, and integrations between those libraries. The libraries should be useful by themselves. If you want to integrate a non supported library(may God be with you), you should be able to write your own simple adapter.

What I don't like is a when a library sneaks it's way into all of my code. The rest of my application shouldn't care what technology I am using for my views. I should be able to swap between the DOM API, jQuery, React, mustache, etc without having to write a single line of code outside of my views.

Reply on news.ycombinator.com