simon83

Oh yes of course, I totally forgot about our rich Swiss friends. Salaries close to SF are possible there I heard.

There is no one in Europe making €100K+ annually.

Just kidding... at least I don't know anyone personally. But maybe the Head of R&D of the company I work for could be close to that mark, at least he's driving a Porsche.

Yeah.. not useful I know, sorry.

But this time it'll work, really!

I'd love to see the code of your vanilla js SPA :) Or does the server render the HTML, and JS just adds a little bit of interactions? Because then you are right, you may not necessarily need React (but it can also render on the server)

I definitely also read that one back then (I keep stumbling upon this website every now and then, it contains some really interesting articles), but I remember that it was too vague for me to understand his point about why OOP sucks. I searched further until I found the article I mentioned, it was much longer and more detailed than this one, and not by Joe himself.

I knew this would trigger a remark ;) I'm absolutely aware of the importance of separation of concerns. And our SPA is not small.

I just became less dogmatic about it. We all have been taught how important it is to separate HTML/CSS/JS, but then came React along and put HTML into JS, many people were outraged, including me. I thought I'd never use that crap that violates basic principles of software design, but here I am and I'm loving it. In the context of UI it makes sense to me. Same with Redux.

Could you please give me an example in which cases you think it could become problematic to have actions, action creators and reducers in a single file? In an application that is not small?

> Redux developers seem to say their issue with prior frameworks was that it was difficult to understand where state changes came from.

Prior to React/Redux we used two-way data binding with first kendo then Knockout.js in a non trivial SPA. It was a nightmare to figure out where certain change events came from. It became a big ball of (un)observable spaghetti. Now you will tell me that our problem was that we let it come this far, and I totally agree with you, but the whole app was started years ago by inexperienced web developers (they were C/C++ devs), then it grew historically into an unmaintainable monster. This was long before I joined the company, and my team is now like the 4th generation working on and refactoring that code.

Redux makes it laughably easy to figure out where state changes come from. Not only that, but time travel debugging is a thing. For the parts that are mostly React/Redux, we made a little debug UI for QA so that they can serialize the last n states, send it to a database and automatically link it to issues. It's still more or less a proof of concept and not as useful as it could be, because not everything is stored in Redux yet, but it did show us that once we are where we want to be it will be an incredibly useful tool to reproduce bugs. Besides that writing unit tests for React/Redux is also easy, compared to other libs/frameworks.

May I ask with what kind of technologies you've been working with so far? Because reading your comments gives me the impression you live in a perfect world, with highly experienced and disciplined team mates, with no problems what so ever. If so congrats, you've won the lottery I guess.

Joe Armstrong said that in the context of code re-usability in OOP. At first it took me a while to understand what he actually meant with that, because OOP is about making code re-usable, after all. But then I read an article that explained this quote in great length and other potential pitfalls of OOP, and then it all started to make sense.

I would write all of this in my own words, but it would become really long and I don't have the time at the moment. I tried to find the original article I read, but I'm unable to, but here is a similar article I just found: https://medium.com/@cscalfani/goodbye-object-oriented-progra...

I'd understand if the inflammatory writing style and the memes are not yours, but I skimmed through it and I think it does explain some of the problems well. I'm sure there are better written articles on this subject, but I have to leave now unfortunately.

Ok, maybe I underplayed it a bit, and I certainly also had a different opinion when I started to get into Redux.

It is true that if you do Redux "by the book", as taught in the official documentation, then it is indeed quite verbose and confusing in the beginning. But once it makes "click" and you start to understand what the point of all these moving parts is, then it's possible to come up with thin abstractions on top of it to reduce the boilerplate. It would have been great if there was a common "standard" way how to do this, but on the other hand, having the flexibility and power to do things how you want, to make it fit your team and project, is quite nice.

For example, we never liked those huge switch statements in reducers. We just use plain objects, where the key corresponds to the action name, and the value is the reducer function. Not really a big deal, but it just shows that you have the freedom to lay out your Redux app however you see fit.

We also saw no real value in strictly splitting up actions, action creators and reducers among multiple files. We simply put actions, action creators and reducers that belong together in a single file.

And then there is the possibility to use middle wares, which can greatly help in debugging and tracing down actions.

So far everyone in my team is very happy with Redux (and React of course).

True, I'm not old enough with my 33 years to remember that ;) But I do have quite a few years of experience in OOP and GUI programming (not just web stuff).

I had no real clue about functional programming prior to React. I always did OOP before.

Once I got in touch with React, I got interested in FP. Then I read the "Mostly Adequate Guide to Functional Programming" [1] and it was kind of an revelation for me.

I still do OOP, and I'm far, far away from being an FP expert, but I think if I'd take the effort to learn a real FP language then I probably wouldn't want to go back to OOP, and that's something I fear :) I've read a few blog posts from people who stated that learning FP kind of made them "unemployable", because they suddenly saw all the problems and annoyances that OOP brings with it (unfortunately I can't find the link anymore).

This quote regarding OOP by Joe Armstrong, the creator of Erlang, is quite fitting: "You wanted a banana, but what you got was a gorilla holding the banana, and the entire jungle."

[1]: https://drboolean.gitbooks.io/mostly-adequate-guide/

I'm sorry, I read your comments, and I could write a 5000 word essay, trying to show you that your perception of Redux is totally wrong, but I'm not going to bother, because I'm sure this won't change your mind in the slightest.

> extra thousand lines of Redux code to remember state

Sorry for yet another ad hominem attack, but this just shows that you are doing something wrong. Yes, Redux requires some amount boilerplate code, but if you need thousands of additional lines of code for state management, then you are lacking code abstraction skills.

> rip out all the Redux and Redux tooling and write this.app.globals.myvar='selected'

It's obvious you have no idea what you are talking about.

I guess when you say "aging" team then I imagine your team members mostly spent their time in the OOP world, and Angular is definitely a better fit in this case.

React and Redux promotes a more functional style (even though React components are classes...), and a lot of OOP people I personally met were not so comfortable with it.

Personally I love the functional concepts that it taught me, and I would never want to use a framework like Angular again. I'd rather make the leap and look into a real functional language for the frontend, like Elm, ClojureScript, PureScript,...

I always thought I was too dumb to understand the Gang of Four book. I thought everyone else must be so much smarter than me, because everyone praised this book. I really had trouble getting a clear picture in my head of the ideas, concepts and how it all fits together, due to the, as you say, excessive abstraction.

I guess it was mostly due to my inexperience in software design in general. I haven't tried to read it again since then, but I'm sure by now I'd at least understand some of the words in there :) So I wouldn't recommend it for beginners, but I think even experienced developers could still learn something new.

Like I said, I really don't expect to find the "true" answer to all this. My point was basically that our current scientific knowledge may not be able to explain everything. We can observe the brain and see what's happening, but the brain and the mind is still a big mystery in science (as far as I know, it's been so many years when I read about this stuff).

And I believe you immediately, without checking first, when you say that electricity can provoke such experience. In my youth I was also interested in brain wave states and how to "manipulate" them with binaural beats, for example. So it seems plausible to me that electricity can provoke a change in the current brain wave state, and thus induce OOBE like experiences. I think there was even a Kickstarter campaign or something for a device which was supposed to aid in experiencing lucid dreams. It also worked by inducing some electricity, as far as I remember.

I can't really answer your question, I'm no expert in this field, but I can tell you that I did experiment with lucid dreaming/out of body experience techniques in the past and this usually involved the strangest body sensations. So what you describe may be similar.

I never really succeeded, but I had a few, very short OOBEs. They only lasted a few seconds because I always got too excited the moment I realized it finally happened, and so I immediately woke up.

When you say this happens randomly when you are falling asleep, then this sounds to me a bit like the start of an OOBE.

Here is what I did and felt when I tried to experience an OOBE: lay down comfortably and try to let your body fall asleep. Take deep breaths, observe your body and look out for certain sensations, try to focus on the here and now so that the mind stays awake. Most of the time I just fell asleep and woke up in the morning, without remembering anything.

But if you stay focused enough, you may start to feel and hear some kind of vibrations in your body, which may intensify if you stay focused. This phase is usually referred to as the "separation of the mind from the body". Once the vibrations are over, and you stay focused, you may start to get the feeling of "floating" and other strange body sensations. Sometimes it felt like my feet started to float, then my legs, and finally my whole body. If you are really good at this then you can try to "open" your eyes and look around. It may be really dark at first, but with enough focus you can literally say "let there be light".

I was only once at this stage, my body started to float, and I "opened" my eyes after a while when I suddenly "saw" the ceiling right in front of my face. I got so excited that I immediately got "sucked" back into my body, and then I woke up.

Nothing really happens in the physical world, an observer will see you falling asleep, but the whole experience always feels so damn real, the beginning is almost always the same and many people can confirm this. It's incredible and fascinating. Unfortunately I never got really good at this and I lost motivation. I was around 17-18 back then and seeking for the meaning of life.

Another fascinating part is that there is no real scientific explanation for this phenomenon. Of course it's usually labeled as some kind of dream state, or just a chemical reaction in our brains.

It depends on who you ask, but for some people this is esoteric nonsense and just simple dreams, for others this is the gateway to a another reality/dimension/quantum world. Personally I have no idea and never figured it out, and I don't care anymore. I got older and I have other problems now, like paying my bills. But it's still fascinating stuff and I like to think back about it every now and then. The internet is full of information and reports about this topic, some serious, some less serious.

Anyway, thanks for making me remember about all of this, after a very long time. It was a fun experience.

I can confirm this. I wasn't able to get into meditation on my own, and so I took the more extreme route and visited a dedicated 10 day Vipassana mediation course.

The effects were incredible and lasted for quite some time even after the course. It's hard to explain, but they teach you to be more empathetic and to listen to the "vibrations" in your body. Once the course was over and I was back in the real world my body was vibrating (not visibly of course) like crazy when I was interacting with other people, simply due to my happiness and love for everything, everyone and the whole universe. I know this sounds like some crazy new age foo, but it's really not.

All in all this was one of the hardest, but also best experiences in my life. Unfortunately once I got back home, daily life and stress took over and I stopped meditating. But I plan to visit another course again as soon as I can, and then I will try to stick with regular mediation. I can highly recommend this.

When I google for "webpack someproblem" then the the first results are usually pointing to the webpack 1 docs. I often don't even find documentation for webpack 2 on the first page, unless I explicitly search for "webpack 2". It took me some time, but now I'm always appending the version number to all my searches. I think Angular has/had the same problem.

Edit: and luckily it's easy to discern the webpack docs: v1 docs look ugly and are lacking information, v2 docs look much nicer and are more detailed ;) They did a great job so far improving the documentation.

Are you really sure it wasn't possible to use external libs prior to the allowJs flag? I vividly remember a colleague fiddling around with TS when 1.0 was released, and we had discussions about definition files and how lacking they were. But I'm pretty sure he was able to declare an external module as "any" in a d.ts file, and then he could simply require it and use it without type information. As far as I know, the allowJs flag allows you to import/require your own .js files (as opposed to external modules), before that this wasn't possible apparently. Without this functionality I don't know how it was possible to gradually convert a code base to ts. We probably wouldn't be using TS now without the allowJs flag. I guess we are lucky to have picked up TS in a state where most of the early issues have been resolved (not saying there are no issues left).

I totally understand your frustrations with VS, though most of the problems you mentioned seem to be related to the TS integration in VS, and not with TS directly. But issues like yours are the reason why I lost hope in VS. I try to use it as little as possible.

Yep, sticking plasters over problems describes it perfectly ;) Many refactoring attempts, but never completed, because JS makes it really hard. And yes, code quality is bad. Most of it was written by people who never wrote JS/HTML before, then it grew historically and here we are with this mess.

But besides TS being very helpful in a messy code base, personally I would also always start a new project with TS. For me the benefits greatly outweigh the minor annoyances (I really see them as minor)

> I sincerely hope it doesn't die on you after you convert your codebase. I wouldn't wish that on anyone.

Pretty sure the product I'm working on will die long before TS :) I think TS is here to stay, and if MS decides to drop it, for whatever crazy reason, then the source code is available. And there is still the option to take the compiled JS code, and hope for some "cleanup" tool, like Decaffeinate, or gradually clean it up yourself... Not nice I agree, but I see no dead end here.

> it's that the TypeScript compiler throws a tantrum when they aren't perfect, which is >50% of the time, to be generous.

Really not sure why our experience differs so much from yours. Like I mentioned, we use a shitload of popular libraries, and for every single one there was a d.ts file available. If I see a definition that is wrong/outdated/broken then I create a fork, fix it and make a pull request. Doesn't usually take longer than a few minutes (depending how outdated the definition file is). Instead of complaining, I try to actively help improve the situation. Most of those d.ts files are written by normal developers in their spare time, after all, so it doesn't help to curse those people.

> Another selling point listed on the front page of its website: ES2015 features. Except it doesn't provide Promises, Map, Sets (and I can't remember if they added Object.Assign support, but it also was not supported when I was using it). When you provide your own polyfills, TSC complains unless you provide typings and add specific config values informing it what you polyfilled.

Yeah it's weird, and I don't get it either. Our solution to this is to run the compiled JS code through Babel. We use webpack for this and it's pretty much hassle free. On the other hand, for someone new to TS/JS this may not be obvious. So I agree there is a tooling problem in this regard, but once you know about it, it's a non issue. So yeah, it would've been nice if the TS compiler did properly polyfill things.

And don't get me even started on Visual Studio. I hate to work with it. It's nice for small projects/solutions, but we have a rather big solution, with a couple "Azure cloud classic" projects, and the whole thing is soooo fucking slow. Changing a single value in a ServiceConfiguration.cfg file will freeze VS for almost a minute, for example. There is lag and delays everywhere. The "TypeScript for Visual Studio Extension" was also very problematic, so we disabled all TS features in VS. We use Sublime/VS Code only since a very long time to edit our JS code. VS is a sad joke for a frontend developer.

As someone with 10+ years JS experience and now 3+ months TS I can not agree with you and the gp. It's total hyperbole what you are writing.

We are converting our huge and messy JS code base to TS, which uses a plethora of libs like jquery + plugins, bootstrap, kendo, knockout, and now React (don't ask me, I don't make the decisions), and we are not even close to done yet. So far TS has been a huge productivity boost. Refactoring is a breeze and the compiler found so many subtle bugs that our JS code had. Converting JS to TS is mostly straightforward, just a few type annotations here and there, the compiler can infer types mostly by himself.

Sure, TS has it quirks, the type definitions of external JS libs is not perfect, allowJs can sometimes be a pain, but so far there wasn't really anything as bad as you make it sound. where we would say "screw TS, let's go back to ES/babel". Quite the contrary, none of our JS devs would go back to plain JS. JS is a huge pain in the ass to refactor, especially on large and complex code bases.

> I fear Typescript is here to stay. If that's the case, I'm moving to Swift and iOS, or changing career completely.

Good riddance then, I'd say :) I'm sure Swift or iOS development has no quirks whatsoever.

That's exactly my point, these salary ranges are "normal" here. For the average developer with little responsibilities in life this may be more than enough. And so goes my theory, but please don't quote me on that: IT workers are undervalued because most of them only need a computer, internet access, a comfortable bed and fast food to live a happy life. And so they just accept whatever they are offered, because they don't need that much money. And why would you pay someone a lot of money to do something he/she loves doing anyway? We are being exploited in my opinion. CS is no simple stuff and not everyone is capable of working in that field.

> the rule of law, which capitalist societies follow

I'm not so sure about that... money makes the rules, and people are easy to buy. You can't tell me there is no shady stuff going on behind the scenes. I strongly believe that the majority of rich people are doing shady things to gain more money. Of course I have no evidence, but human behavior is predictable and it's obvious what's going on.

Capitalism seems alright in theory. The problem is people and their selfishness.

And no, I'm not for communism. Again, nice in theory but won't work if run by people. I don't think I'll ever experience a truly "fair" society in my life.

Since when is it beneficial for multi million (billion?) companies to act in the interest of their customers? This isn't communism.

Pretty sure none of your implementations will beat the FizzBuzzEnterpriseEdition [1].

[1]: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

I currently live in Stuttgart, which is apparently slightly less expensive than Munich. I don't think a 49k€ entry level salary for someone with a masters is good. It's probably enough to afford the basic necessities and a small apartment in Munich, but that's it. But then again, most companies seem to think this is good enough, it's so surreal.

I've been told many times in the past that a degree is not that important, what counts is experience. I haven't studied due to my laziness in my youth, but my experience looking for a job has shown me that a degree does matter. Some companies won't even invite you for an interview if you don't have a degree. I feel like I'd have a much better chance to negotiate a better salary with a masters or even bachelors degree.

I'm in Stuttgart. My biggest handicap is probably that I never studied anything. As a nerd I totally lost interest in school, and so I started to work rather early instead of studying.

And there is no denying that the quality of life is much better here in Germany than in the US (unless you make shittons of money of course).

I'm currently working as a web developer, with a focus on frontend development.