Retozi

Also among various other tech stacks I've never seen something that hits the sweet spot between "plain sql" and "advantages of ORM-stuff" as well as jooq

Because you have to hit more keystrokes to write your program?

That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystrokes nobody questions. But when you have to type " ... : number" it's slow velocity?

In my opinion people vastly over-estimate productivity boosts of saving keystrokes. It's the tedious, boring part of the work that you would like to skip entirely, hence excess keystrokes feel way more "slowing you down" than they acutally are.

Although it doesn't matter, you actualy save keystrokes: autocomplete, auto-refactors and less low level unit-tests compensate the couple of type annotations easily.

We have a very small Ktor service in Production, and it works nice, for legacy reasons, we're using http://sparkjava.com/ for the heavy lifting. An alternative would be https://javalin.io/

I would not start with Sparkjava anymore. The way you write handlers is quite okey (compared to other frameworks), but there are issues with how it's connected to Jetty and relies on singletons that will be painful if you would like to do advanced stuff. It's on our todolist to swap Sparkjava with Ktor somewhere down the road.

To be honest, Ktor seems to have come a long way, the docs improved a lot last year and it seems well thought out. I would give it a try. It's quite easy do decouple your application Handlers from the underlying framework via functional composition, so there is no big lock-in Risk.

In my experience, all three Frameworks are way better than the regular Java-like approach with annotating classes. Request-Context specific information ("The user making the request") is very hard to get to this way and it's usually untyped. On top of it, you are locked in HARD to the Framework. Swapping out a Framework that just mounts Functional Handlers is way easier...

- TypeScript is more important than React, static typing is such a productivity boost, even for projects of all sizes.

- Start with vanilla React and create-react-app, monitor for painpoints and look for solutions for these pain points in the community, don't look at the whole ecosystem before you start building stuff.

Backend: Kotlin on the JVM.

Kotlin is a really nice language for either functional or object oriented programming. Static typing with strict null checks are again a huge productivity boost. Standard library is very complete

Beeing on the JVM without beeing stuck with Java is a big win:

- unlocks a huge ecosystem and Java interoperability of Kotlin is superb.There are a lot of lightweight frameworks for stuff around here, enterprise Java is a myth if you are free to choose what to use.

- special shoutout to the JOOQ library, the golden middleground between an ORM and raw SQL Strings.

- JVM is fast

- fat jars are somewhat like containers, can be run everywhere with minimal setup (yeah I'm looking at you python-uwsgi black magic)

Database: Postgresql. Everything you need (relational, JSON), fast, rocksolid

It feels a lot more stable than before, where every project had homegrown framework stuff on top of backbone.js or jquery, or then using ember.js. There was just an awful lot of difficult discussion on how to design event-bus abstractions, global state management and general architecture

To me it feels like the frontend ecosystem has stabilized a lot, since the react paradigm is very robust and versatile. For most difficult problems, the solution is somewhat clear. Sometimes more, sometimes less elegant, but at least the timeconsuming disussions have become less frequent within a team

The interest rate on mortages is always higher compared to the interest rate on leverage for stock (by using the stock itself as collateral).

You can get close to the yield on swiss confederation bonds if you buy well priced, leveraged ETFs.

Obviously that interest rate is as stable if not more stable than the interest rates on mortages.

Please DO NOT buy stocks with money from a mortage. you're just giving up at least 1% yield.

TypeScript is an invaluable, mature technology that provides large productivity boosts to any team that maintains a mid-sized code base.

It plays extremely well with React too, and it's benefits are independent of the tech stack. If you are used to typed components/templates, you will NEVER want to go back.

I would argue that is more important to have static typing in the front-end compared to the back-end in a web-application context. There is more state, lot's of shared entities and unit tests are expensive to write and maintain.

1. install chocolatey https://chocolatey.org/, and install everything with it

2. install conEmu for a decent command line

3. install git for windows, which comes with a bash shell that brings you all the linux commands, inlcuding ssh.

This brings a Windows PC relatively far. You can even get ssh-agent working with an according .bashrc script (along the lines of https://github.com/joaotavora/holy/blob/master/share/zsh/ssh...)

This does it for me to do node / web-dev / java/ android centered development, I prefer it over macOS and Linux.

Things I do not use:

1) Cywgin. Quite the behemoth, and I get by with git bash just fine

2) The Ubuntu Subsystem. I tried it, had trouble with ssh stuff, seems not ready yet...

3) putty. the open-ssh that comes with git is better and closer to linux.

I mean yeah, if you have a big app, complex requirements, there is a bunch of stuff you need to take care of.

However, I would like to see the tech stack that allows you to do the same with less complexity.

It's not like Android (gradle?!, java 6?!, the android api!?) or iOS development is a walk in the park if you want to do anything with production quality.

Additionally, these are tests that you will have to tediously adjust every refactor since HTML frontends and it's data APIs behind it tend to change often over the lifecycle of a product.

From my experience, "only those tests" save you hours and hours of programming time.

Using TypeScript instead of JavaScript is such a productivity boost for a team developing a sizeable single page application, any other technical decision (which Framework, tooling decisions) is almost irrelevant relative to this major improvement.

TypeScript has ALL the properties that should make adoption a no-brainer:

1) Increases developer productivity, especially over long term maintenance timeframes. (My non-scientific, ymmv estimate is at least 30%)

2) Reduces production exception rate significantly

3) Can be adopted gradually

4) Full JavaScript ecosystem still at disposal

People seem to massively underestimate the benefit of a typed language in a frontend codebase. At gunpoint, I would rather have the backend in a dynamically typed language and keep TypeScript for the frontend. Chances are that the distance between your database and the API is not far, so static typing is not that useful.

However, if you have decided for a client side rendered application, your app is stateful, dynamic and probably quite big. Static typing really helps to avoid mistakes and increases the ability to refactor quickly and correctly by order of magnitude.

There are too many hardly ever visited code branches, and tests are very costly to write for an application where users can click a lot of things.

It will take a person a couple of days to "grok" Redux, and a quite a bit longer to fully understand the ins and outs so one can make informed, confident decisions on how to solve problems "the Redux way".

Now you gain "cool" things by doing it, but here is the catch: Is the benefit worth the time investment to get there?

His argument is that for a lot of simple apps it isn't. You get very far with plain React, and a project has to have significant complexity to pay back the costs of fully understanding Redux.

I would argue a lot of people picking the React ecosystem make the mistake of choosing too much architectural complexity, not too little.

The extreme pluggability helps to broaden usage of Redux. But it is overkill for many projects. Decoupling is important, but it is not free (see parts of the Java ecosystem).

Devs should consciously decide what to introduce, and leave out stuff that simply doesn't increase development efficiency given the nature of their project.

A lot of teams don't have the "designer" problem and are just fine without JSX.

Passing data through dozens of children is not a problem in every application, a lot of simple CRUD stuff can do just fine without Flux.

Even bundling is not necessary for progressively enhanced websites, and for most SPAs a really simple, naive strategy will do just fine.

If the requirements of your project are ambitious, some complexity is not avoidable.

But the problem today is that a lot of unneeded complexity is introduced into projects because people want to adhere to "best practice" and don't question what they need and what they don't need.

In my opinion, it is a huge mistake to not actively resist complexity creeping into your project. You should only give in if it there is proof that it makes sense economically.

This issue is another variant of "premature optimization is the root of all evil"

It's really just a days worth of looking at the original flux, redux and other implementations and figure out what's best for your team and project.

It doesn't take more energy / knowledge than to hack around patterns that don't perfectly fit your projects needs with the "everything included" frameworks.

However, the React ecosystem is really not that complex. You can write clean, sizable apps with vanilla React.

Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux.

All other things are really not needed for most people, and if you do, you are facing problems so large, evaluation of libraries is a small fraction of the effort.

It's more the mindset of people "I'm missing something great" that drives them crazy and into framework fatigue. (OMG server-side rendering, falcor, relay, immutable.js arrgggh)

Usually, you are missing something you don't need, otherwise you would be looking for it actively.

If you need an object (say to use it in something like Redux), you have to write a wrapper like so: https://gist.github.com/ebi/d186c4297c84d562aeae

I've been writing React SPAs for roughly two years now.

Very few things have changed. The first app I've written roughly looks like the newest one. Couple of lessons learned here and there like everywhere else.

Yes, there are many Flux libraries and different implementations. However, a decent State management solution for React is roughly 200-300 LOC. So there are many of those 200-300 LOC libraries. So what?

If it's a big project, you should spend the time to figure out what fits YOUR project and YOUR team the best.

If it's a side project, use the most popular with the best documentation and be done with it.

Adopting something like elm might have its advantages, but also comes with practical disadvantages that, depending on your team and your project might be simply too big make the jump.

React got a lot of things right in my opinion. So much that to go from apple to fruit salad, you need roughly 200-300 additional LOCs, and you have a very robust Frontend system that, once you wrapped your head around React, has a very low knowledge barrier.

However, the good traits of React are not attributable to one concept like "FRP" but are simply "good concepts" that seem to influence other Frameworks to do "the same, a little different".

The adoption, the somewhat small API, the support from a large company, the possibility to integrate it easily in existing codebases that use other frameworks and react native has a much stronger pull than FRP in my opinion.

Apart from an occasional restart required it has been pretty solid. Performance(autocompletion etc) is very good and for TypeScript development, VSCode is pretty feature complete...

I was one of the "you save characters, you gain readability" proponents as well (I love Python too).

However, it is a terribly flawed argument. Typing characters is incredibly cheap.

Debugging and refactoring in a dynamic language. However, is very time-consuming. You might be a tad slower writing Typescript (with autocompletion and typechecking, I doubt it though). But over the whole lifecycle of a codebase, Typescript is a lot faster for everything but very small projects.

I have done refactors in Typescript in hours that would have taken me days in CS... multiple times.

Additionally the human brain can adjust to predictable noise very well (brackets). After a training period, I find Javascript and Typescript almost as readable as MY Coffeescript.

However, even when developing 8 hours for multiple months in Coffeescript, I always had a hard time to grok other people's Coffeescript. There is just too much freedom.

This does not happen that easy with Javascript/Typescript.

Generally, static typing in a complex user interface is a huge huge win productivity wise. While you type more characters, you are still faster over the lifecycle of a project. Hitting keys on your keyboard is literally the least time-consuming part of programming.

As of today, it is incredibly hard to evaluate frameworks because you generally only have the time to evaluate small examples, but those are usually easy to do anyways.

This thing here is as tricky as it gets for the scope. Even if the judging is subjective, it is highly revealing.

This should reveal potential pain points a lot better.

he mentioned it here originally: https://www.youtube.com/watch?v=rmFsUV5ICKk

his theory is that he was abducted by aliens, but it sounds like brain damage...

Boxing, Kickboxing and Football are arguably as bad as MMA in regards to brain damage, and many other sports in regards to chronic pain of some sort.

Calling MMA out specifically on this issue is a convolution of the perceived violence and the degree of injury. (I don't care if fighters bathe in each other's blood, as long as the blood stems from a cut)

The problem is that protecting the fighters is not simply a matter of adding Headgear (you can get knocked out easily with headgear as well btw) in fights, as a lot of fighters accrue their injuries in training.

If it would be only the fight that could cause harm, I would argue MMA would be safe. But the lifestyle of a fighter as a whole is extremely unhealthy.

First with methods, you have mutable state, which I believe should be avoided. It causes a lot of problems for efficient rendering.

You could make some kind of wrapper, but I guess it's not worth the hassle to save a couple of characters.

Second, Action can cause complex writes that touch more than one model (or if you have one global model, multiple state slices). You probably want to have the write functions named independently, so they can be reused over multiple actions if necessary.

There are various other videos of her rolling with other men (albeit bigger ones) like Mousasi and Luke Rockhold, and it is anything but competitive.

I think the situation is pretty comparable to Serena Williams, who would win against most "regular" men, but not be able to provide a competitive match against roger federer.

You can _implement_ both representation and logic with React. (instead of JS for logic, and some clunky template language for representation).

This does not mean that you should mix it. usually you end up with "representation" components that are "dumb", and logic components, that do not care about the representation of their children.

see https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

Just because it shares the implementation mechanism, it does not mean that they are mixed together. You can of course, but most of the time, you should not.

The "I understand CS code much quicker" argument is a valid one theoretically, but In my opinion, it does not hold up practically that well.

CS got one thing wrong that Python got right: There are many ways to do things.

When writing CS, I understood MY CS just fine... but it always took me longer to understand the CS of other people. Sometimes even longer than JS. This is such a huge drawback, and even if there is coffeelint, for teams, this is deadly.

A lot of devs need to read a fair amount of foreign code. Even worse a lot of coffeescript writers also need to read and understand a lot of JS code.

Understanding and reading YOUR code slightly faster gets mitigated by having longer to understand foreign code.

While some JS purists fail to see that Coffeescript has some benefits, CS people also underestimate how "quickly" you can understand JS code, if you're experienced. It's all about what your brain is trained to do.

In my opinion, with ES6, I would argue for most people (ceteris paribus) it just makes sense to read and write JS exlusively, if you want to maximize output-productivity of a full, practical project.

Shaving off a couple of seconds "understand-time" of your personal, well written CS vs well written JS will just not compensate other things that will take you longer to do with CS.

2. Stores contain immutable data. This allows for reference equality checking which will yield performance gains

3. Stores do not contain asynchronous code. From the view of stores, it doesn't matter if user manipulates the state directly or triggered a fetch from a server.

Using Backbone models is a valid strategy in my opinion though...

There is usually not enough emphasis on the nature of the app in these X vs Y framework discussions.

I can really see why you would choose Ember say for Discourse and why (once you got it) it is very productive.

But for other apps you might constantly fight the Framework.

Optimal patterns really depend on what you want/need to do. (Thats why TodoMVC doesn't help much).