Hacker News Reader

> React

Similarly on Flux: I implemented an immutable store where only incoming messages change state and changes are distributed to widgets in 2005.

Around the same time we started using feature flags in our application.

We also did CI around 2000. Didn't call it that of course.

Never did it myself but heard of TDD long before it became a thing. Again under a different name.

Erlang. Superior technology that forms the heart of new kid on the block Elixir. Built long before the Bay Area CS grads re-invented ageism and claimed young people to 'be just smarter'.

Sure some things are new, but there's just no respect for experience any more.

What about Go? I like go a lot because I feel like they did hit the mark and they did learn from their predecessors. Strong standard library. Clean syntax. Easily compiles to every major platform and architecture (all you need to do is set an environment variable). Everything statically compiled (as a software distributor, this is super nice!). Phenomenal testing framework.

It's not all that innovative, it's just very easy to use, and very well put together.

I tried it and was immediately put off by the monumentally dumb approach to package management (or rather: its non-existence), lack of generics and approach to exception handling.

IMHO If go were invented by anybody other than Google it wouldn't have enjoyed anywhere near the success that it did.

I'm usually extra suspicious of "hot" open source technologies with a marketing budget and/or tech behemoth behind them. It's not that they can't be fundamental steps ahead it's that the marketing can end up causing undeserved popularity.

I'm in the camp that actually prefers -- strongly prefers -- Go's style of error handling over exceptions. It's not a perfect language of course, but when you say it's successful only because Google marketed it, I think you're off by quite a lot. Go is popular in part because of the things you hate that other people like. Also, Google hasn't really done any real "marketing" of Go that I can see. They released it with what amounted to enough fanfare to say "Hey, here's a thing. We think it's pretty cool. Here you go."

And the point of Go is that it isn't trying to be "fundamental steps ahead". If anything, Go is an opinionated statement that programming was better in 1992 than it is today, so let's just fix the annoying shit from 1992 and pretend the word "enterprise" had continued to just mean the ship from Star Trek.

I have similar gripes with Go. I really love programming with CSP techniques and Go does a good job of implementing a lot of this at a lower-level. Clojure also draws from CSP and from Go's implementation of CSP, but lacks some of the nice things Go has going on here at lower-levels, however I end preferring Clojure for so many other reasons. I still would not shy away from Go, but it's far from a perfect language and doesn't really improve on a lot of things that similar languages don't do well.

I think it's not just Google, but the cult of Rob Pike, Ken Thompson, etc. I appreciate their work on so many things, so I don't mean any ill-will. I was a user of ACME editor and Plan9, but just like those projects, Go has so many polish issues in critical areas. The package management alone is ridiculous. The common theme in all these projects is for every good idea, there is an order of magnitude more critical mistakes or divisive ideas that cripple the end result in some way.

Go is alright, but it's not really that interesting to me or a monumental leap. There are a few ideas that others could cherry-pick and put into much better designed languages to take it all a step further in my opinion.

Bingo! :)

I'm a 50+ developer who has increasingly felt that "life is too short" to spend all my time trying to keep on the latest fads.

That being said, I have found myself doing more "fun" programming in Go lately, precisely because, as you said, they hit the mark with how simple and clean the language is, with little of the baggage that comes along with a lot of languages and frameworks (I'm looking at you Rails and React) today.

I am a language freak (hard to admit as who is not these days) but have to say I did not try Go yet... so yes, I must.

As a language geek myself, I've been working a lot with Elixir lately at $WORK, which has been an absolute dream. There's pioneer taxes and bug fixes we have to push upstream occasionally to some of our dependencies, but it's been extremely pleasant so far. Clean syntax, well thought out internals, 30 year old host platform designed for server programming, Lisp style macros (it really feels like a Lisp) , an "explicit over implicit" mentality, immutable everything, and a wonderful "Rails without magic" web framework to go along with it.

That almost sounds exactly like the Java argument from the late 90s

clean syntax standard libraries write once, run anyone

React is a lot more than it seems. The essential problem it tries to solve is componentization: how can you have a large team of varying skill work on separate parts of a page in a web application without one part breaking the others in hard to detect ways?

Many people focus on JSX or virtual DOM and muse about how that just duplicates the browser-- what's the point? But that isn't the point. It's componentization and encapsulation for large teams at scale, and for Facebook it works, it makes them more successful at pulling together disparate modules on a single page than their competitors, so there is some meat to this $NEWSHINY.

Now, if the browser itself had been properly designed years ago to be componentized and encapsulated, we'd have those features without inventing a new DOM or creating a new tagging language or isolating CSS. There is a web components standard that offers much of the same thing... It came out around the same time as React, but still isn't widely used outside of Google Polymer. Truth is these were developed in parallel before they knew of each other.

Anyway, React makes a lot more sense if you think of it as rewritting the browser from outside the browser. In the old days the stack that would have been hard to impossible-- you would have simply started your own browser. And people would have shamed you for not following existing standards, so you would have petitioned the W3C or served on committees to bring your real-world cases for years, being mostly ignored.

Now, devs have the ability to change the browser quickly and find things that work (and also create chaos and suffering).

Meh. Kids. ;)

Honestly mate, you're just talking about the same old, same old.

Every framework is about componentization and encapsulation.

You could take React out of your post and replace it with any framework name in the last 40 years and it would have made 'sense' at the time.

Like the author said, right now a veteran looks at react and sees the mistakes of 15 years ago when we mixed code and presentation.

The Webpack story is interesting because its author isn't (well, wasn't) even a JS developer in his day job or was part of the JS community. I don't hate Webpack but I really have no idea where it came from. Browserify was made by one of Node's ecosystem top contributors, so at least that makes sense.

And webpack's documentation is the spawn of Satan. Going outside the typical use cases is downright impossible. While it has the widest feature set out there, it's incredibly difficult to believe in its reliability. That said, since you can always QA your bundle, reliability isn't as much of an issue I guess...

> And webpack's documentation is the spawn of Satan.

An insult to our Master, Satan would never create something so awful :P

FWIW webpack's docs are getting much better for v2