adamw1pl

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.

Not yet, but that's one of the features we want to add after this initial release. Thanks for the feedback!

Yes, you are right! Funny how this went unnoticed for so long ;) Fixed now.

We'll be posting some on our twitter (https://twitter.com/shelly_dot_dev) for a start. Plus we'll be expanding the tutorial/help area. Stay tuned :)

No reason :) The language is of course Logo-inspired. Once we'll have an "About" page or sth like that, we'll mention Logo of course.

Thanks! Would be great to get feedback once you get an occasion.

The tutorial is only a start for what we are planning, so this is an area we'd like to work on next. Hence any pointers or ideas are welcome :)

Thanks for the feedback!

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).