Many people talk about Java, Go and similar, contrasting it with Scala, but I think it misses one crucial point. Java and Go are in many ways "done" languages. They evolve very little. Correct me if I'm wrong, but I don't think Go changed significantly since 1.x. Java hasn't been evolving almost at all until recently, and the changes introduced now are still conservative, and it will take ages before the ecosystem catches up and actually makes good use of what's introduced in Java 11+.
On the other hand, yes - Scala is in many ways a research language. It's got a number of novel features, starting from the blend of FP and OO, through implicits, ending with metaprogramming. The dark side of introducing features that other languages don't have, is that they sometimes need polishing or complete removal. That impacts the compiler (which evolves as well - compiling Scala code is much more complex than the rather straightforward translation of Java to bytecode) and high-level language features alike.
The bright side is that software engineering is very far from being a "done field" (or at least I refuse to believe it is such). There's a lot to be discovered as to how we can write code that is readable, performant and - yes - maintainable.
"Wait, but if you said Scala is a research language, is it safe for business usage?" Yes - while Scala has a research side to it, it also is a language used successfully in many companies. It has a lot of libraries that are maintained, the language authors pay a lot of attention to binary compatibility (with well-defined limits - you know what to expect!).
Businesses have benefited from using the newest available technology in many fields, and I doubt software engineering should be different. Of course, you shouldn't be reckless - but using technology from 20 years ago "just to be safe" isn't always a recipe for success.
Yes, you can build great systems with Java and Go. Same is true for Scala. And yes, you can build totally unmaintainable systems in Scala, but in Java and Go as well.
Finally, a side note about OSS. I don't think it's fair to expect anybody to maintain any kind of library in any language for free. You like the library, it solved your problem - great, you can use it for free. But if you want it maintained above what the library author donates, either through their time or through corporate sponsorship - well, you can't have any expectations here. I'm sure a lot of these migrations problems could be solved, given a reasonable business offer.
1. the background should be almost-opaque, with very little transparency. Can you share which browser/OS? Probably some missing CSS :)
2. Ha :D Maybe a grace period? Did you mostly mind the squiggly underline errors, or the red box that appears at the bottom? Giving feedback soon enough but not being aggressive is a delicate balance, there's probably room for improvement here.
Thanks for the pointer, React-forms as well as React this looks very interesting, however I think the focus there is mostly on frontend, while we are trying to approach the problem both on the frotend and backend sides.
Otherwise there are some similarities between the projects.
We would be fine using existing frameworks and their form handling systems, but all of them feel very heavyweight. Either the backing objects need to be of some specific form, or the communication protocol between the server and the client is weird, or the generated markup is a mess.
With Supler, we want to make it easy to customise the form, the form's markup and associated Javascript (to add any dynamic behaviour), so that you don't have to hack the framework, but instead so that you can use our library to generate the base and then customise further.
One of the main points of Supler is that it takes care of both the frontend and the backend, so I don't think it would be possible to keep it entirely on the frontend. E.g. you define the form once, and you have partial validation on the frontend, and the same full validation on the backend (without having to repeat yourself).
That's on purpose, of course ;). But it's not only marketing: functional as in preferring immutable data structures, and reactive as in changing the form in response to user input.
I wouldn't say these two are in opposition; while CodeBrag doesn't have support for pull request, I don't see why it shouldn't in the future.
It would be perfectly valid to use CB to review commits in the branch for which the PR is done, and then come back to it once more commits (with fixes) are added.
Also, using PR is only one style of work, and I don't think it's the "only right choice". Code reviews of code as it is written, that is during development of a feature, can help you to spot any problems faster. Waiting until a PR is done can result in a long feedback cycle.
You can use CB to track a specific branch that either your colleague is working on, or maybe you are working together.
On the other hand, yes - Scala is in many ways a research language. It's got a number of novel features, starting from the blend of FP and OO, through implicits, ending with metaprogramming. The dark side of introducing features that other languages don't have, is that they sometimes need polishing or complete removal. That impacts the compiler (which evolves as well - compiling Scala code is much more complex than the rather straightforward translation of Java to bytecode) and high-level language features alike.
The bright side is that software engineering is very far from being a "done field" (or at least I refuse to believe it is such). There's a lot to be discovered as to how we can write code that is readable, performant and - yes - maintainable.
"Wait, but if you said Scala is a research language, is it safe for business usage?" Yes - while Scala has a research side to it, it also is a language used successfully in many companies. It has a lot of libraries that are maintained, the language authors pay a lot of attention to binary compatibility (with well-defined limits - you know what to expect!).
Businesses have benefited from using the newest available technology in many fields, and I doubt software engineering should be different. Of course, you shouldn't be reckless - but using technology from 20 years ago "just to be safe" isn't always a recipe for success.
Yes, you can build great systems with Java and Go. Same is true for Scala. And yes, you can build totally unmaintainable systems in Scala, but in Java and Go as well.
Finally, a side note about OSS. I don't think it's fair to expect anybody to maintain any kind of library in any language for free. You like the library, it solved your problem - great, you can use it for free. But if you want it maintained above what the library author donates, either through their time or through corporate sponsorship - well, you can't have any expectations here. I'm sure a lot of these migrations problems could be solved, given a reasonable business offer.