10 ms·

Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You need to understan

Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You need to understand the why of DOM diffing. It is not complicated. If a frontend dev doesn't want to learn that then they will be out of a job in a decade. It transfers, too. React, Vue, Elm, Reagent, etc, they are all doing this, because it is good, and none of them in isolation are complex. Mithril is actually smaller than Intercooler and is everything included, so there's no need to put together a stack if you don't feel like it. The stack you are offering is great, and it's great in the right situation, but I just wanted to push back against the "complexity" argument because it happens a lot and it makes me afraid that it is pushing devs into more familiar but less capable stacks. Your React/Vue stack might be a little more setup, but it's also going to scale. The Turbolinks/Intercooler approaches seem to be managing state with the DOM, and as someone who has spent the last six months pulling the state out of the DOM from a jQuery app, it does not scale. But anyone who has used both approaches in a moderately sized app can tell you this, it's why stuff like React exist at all.

bphogan 9y ago
Front-end stuff doesn't have to be complex, but it is. For example, a lot of places using React think they need Redux too. And React-router. And many other components. React itself is quite simple. But the architectures that developers build are often incredibly complex. This was the case with jQuery, Angular, and things that came before. I see two main problems in software development, especially on the front-end. First, developers jump on brand-new ground-breaking frameworks and use them in production, learning how they work as they go. This results in brittle systems. That's not necessarily bad, but it's not always great from a maintenance perspective. React is hot right now. But there are a ton of in-production Angular 1.x apps out there because that was what was hot when those projects started. That brings me to the second problem in tech - developers doing the "hot new thing" displaying a ton of hubris. It's "easy" and "straightforward", implying that anyone who doesn't get it just isn't smart or will be obsolete soon. I'd worry more about losing my job due to not keeping up with machine learning rather than not learning whatever new JS framework people think is hot right now. Here's the deal - web developers figured out server-side rendering 20 years ago, and managed to make turning databases into web pages easy about 12 years ago. It's possible to create applications that people love using a lot of that technology, with some JS on top. It's certainly faster to go to market with something that way. Not every app is Facebook. A lot of the stuff people work on outside of HN fall into one of two categories: 1. Apps that are behind a firewall - internal in nature, used by a handful of enterprise users. 2. Apps that won't be around in 3 years from now because the company will shift focus/replace it with an off-the-shelf product/company gets acquired. In both those cases, I'd look for the simplest approach to get something running, and simplest to maintain. Bottom line: it's easier to leverage existing skill-sets than it is to ask people to learn a whole new thing all the time. Anyway, at the end of the day, I don't really get too worked up about how another person chooses to solve the "make the browser display a web app." Every situation is different. React can be simple. So can server-side rendering with some Knockout/Stimulus/Intercooler/jQuery sprinkled around. Maintainable quality code that makes money wins in the long run. Whatever you implement it in.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
tannhaeuser 9y ago
I'd be careful with predictions wrt JavaScript frameworks. Though I personally like React, just two or three years ago Angular was the framework of choice for many (I've never been a fan of it). Front end framework churn seems inherently cyclic in nature, where a new minor generation breaks with tools of the slightly older generation to define itself on the marketplace. Moreover, it must be said that neither React nor Angular are front end libraries in itself; they merely organize DOM manipulation and event handling in a more or less bureaucratic way.
c8d3f7b49897918 9y ago
> The Turbolinks/Intercooler approaches seem to be managing state with the DOM, I won't speak for turbolinks, but with intercooler the idea is to return to a stateless architecture, the second aspect of the REST-ful architecture[1]. State, as such, is stored on the server, not on the client. It has scaled quite well in my applications: browsers are very fast at swapping new HTML into a page. The downsides can be additional chattiness with a server and a lack of interactivity if you are building a fancy (or fancy part of an) application, such as a game. In those cases, intercooler is not a good choice. [1] - https://en.wikipedia.org/wiki/Representational_state_transfer https://en.wikipedia.org/wiki/Representational_state_transfe...
pwaai 9y ago
> Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You are always going to have a hard time convincing others when you speak in absolutes while invalidating all other cases. To me these non-full stack frameworks actually meets a totally neglected market full of people that come from jQuery before even learning vanilla Javascript. Different strokes for different folks, and that goes for how perception of complexity is interpreted. Someone knee depth into React/Redux will not be able to walk in the shoes of someone just exploring or even experienced developers looking for something more simple and easier to get into.
mmargerum 9y ago
React isn't complex, but pretending JS supports immutable structures makes it hard to use. I have some pretty deeply nested json structs and it looks like a i have to flatten them out to use react. I suppose mobx might be a better way to handle this.

bphogan 9y ago

Front-end stuff doesn't have to be complex, but it is. For example, a lot of places using React think they need Redux too. And React-router. And many other components. React itself is quite simple. But the architectures that developers build are often incredibly complex. This was the case with jQuery, Angular, and things that came before. I see two main problems in software development, especially on the front-end. First, developers jump on brand-new ground-breaking frameworks and use them in production, learning how they work as they go. This results in brittle systems. That's not necessarily bad, but it's not always great from a maintenance perspective. React is hot right now. But there are a ton of in-production Angular 1.x apps out there because that was what was hot when those projects started. That brings me to the second problem in tech - developers doing the "hot new thing" displaying a ton of hubris. It's "easy" and "straightforward", implying that anyone who doesn't get it just isn't smart or will be obsolete soon. I'd worry more about losing my job due to not keeping up with machine learning rather than not learning whatever new JS framework people think is hot right now. Here's the deal - web developers figured out server-side rendering 20 years ago, and managed to make turning databases into web pages easy about 12 years ago. It's possible to create applications that people love using a lot of that technology, with some JS on top. It's certainly faster to go to market with something that way. Not every app is Facebook. A lot of the stuff people work on outside of HN fall into one of two categories: 1. Apps that are behind a firewall - internal in nature, used by a handful of enterprise users. 2. Apps that won't be around in 3 years from now because the company will shift focus/replace it with an off-the-shelf product/company gets acquired. In both those cases, I'd look for the simplest approach to get something running, and simplest to maintain. Bottom line: it's easier to leverage existing skill-sets than it is to ask people to learn a whole new thing all the time. Anyway, at the end of the day, I don't really get too worked up about how another person chooses to solve the "make the browser display a web app." Every situation is different. React can be simple. So can server-side rendering with some Knockout/Stimulus/Intercooler/jQuery sprinkled around. Maintainable quality code that makes money wins in the long run. Whatever you implement it in.

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]

tannhaeuser 9y ago

I'd be careful with predictions wrt JavaScript frameworks. Though I personally like React, just two or three years ago Angular was the framework of choice for many (I've never been a fan of it). Front end framework churn seems inherently cyclic in nature, where a new minor generation breaks with tools of the slightly older generation to define itself on the marketplace. Moreover, it must be said that neither React nor Angular are front end libraries in itself; they merely organize DOM manipulation and event handling in a more or less bureaucratic way.

c8d3f7b49897918 9y ago

> The Turbolinks/Intercooler approaches seem to be managing state with the DOM, I won't speak for turbolinks, but with intercooler the idea is to return to a stateless architecture, the second aspect of the REST-ful architecture[1]. State, as such, is stored on the server, not on the client. It has scaled quite well in my applications: browsers are very fast at swapping new HTML into a page. The downsides can be additional chattiness with a server and a lack of interactivity if you are building a fancy (or fancy part of an) application, such as a game. In those cases, intercooler is not a good choice. [1] - https://en.wikipedia.org/wiki/Representational_state_transfer https://en.wikipedia.org/wiki/Representational_state_transfe...

pwaai 9y ago

> Frontend stuff doesn't have to be complex. The idea behind React is very simple and it's really something every front end dev should know. You are always going to have a hard time convincing others when you speak in absolutes while invalidating all other cases. To me these non-full stack frameworks actually meets a totally neglected market full of people that come from jQuery before even learning vanilla Javascript. Different strokes for different folks, and that goes for how perception of complexity is interpreted. Someone knee depth into React/Redux will not be able to walk in the shoes of someone just exploring or even experienced developers looking for something more simple and easier to get into.

mmargerum 9y ago

React isn't complex, but pretending JS supports immutable structures makes it hard to use. I have some pretty deeply nested json structs and it looks like a i have to flatten them out to use react. I suppose mobx might be a better way to handle this.