JetBrains Web UI components open-sourced
blog.jetbrains.com
blog.jetbrains.com
https://github.com/Kotlin/kotlin-fullstack-sample
Combined with the fact that you can use Quasar for Erlang style processes, I think that I found my next web language.
I guess you could achieve this with Scala too but I could never get over the compilation times. Also the Kotlin integration seems somewhat more straightforward.
I also like that the company that makes my IDE also makes the ORM (https://github.com/JetBrains/Exposed) and web framework (https://github.com/Kotlin/ktor). Idk how good these are but I imagine pretty decent.
For example here is a single page app written with kotlin: https://github.com/rnentjes/simple-password-manager
I haven't measured runtime performance, but I haven't noticed anything being slower than plain javascript yet. A clean compile in this example takes ~8 second, incremental compiles takes 3-4 seconds.
The jvm doesn't play a role when targeting javascript so I am not sure what you mean with JVM variables and I don't know much about GWT. But you can debug the resulting javascript from intellij and step through the kotlin sources if you want.
I don't know how easy it is to integrate with react.
It's obvious that things that shouldn't do a lot of work, do in fact do work. Like if I press Ctrl+C on some selected text. I simply expect it to put the text into the clipboard. But sometimes it will stall, put a dialog on the screen telling me it's doing some formatting and I need to wait! What the hell is it formatting?
Every member of my team is sick of it and it's negatively affecting our productivity, so if Rider is good then bye bye Visual Studio.
Obviously a 32bit app could run a number of sub app domains, so it can still make use of more than 2gb. I think ultimately though is it's not the resource that's the issue, it's the buggyness of the system. It just feels unfinished, and it seems there's some lazy decisions made in implementation ... the formatting error on Ctrl-C sounds like it's doing too much work; other things like if I try to download a publicly available nuget package, through the god awful UI, I have the source setup as nuget.com - it then pops up a dialog asking for my credentials to my company nuget server! If I cancel it, guess what, it fails to get the package from the web.
I have a strong suspicion that it's talking to the net too often generally (I have a slow broadband connection, so I see areas that are clearly doing too many round trips).
I feel it seemed to really start going downhill when Roslyn became the compiler (which I assume is running most of the tooling). I don't know if that's anything to do with it, but I assume they had to rewrite a lot of the core components when Roslyn came along.
2015 wasn't great, 2017 is really bad. Waiting several years for them to finish the project properly is taking its toll on my confidence in a product I've used in one form or another since 1994
Dave twitter.com/davkean
Also since their new licence scheme it seems releases quality can be hit or miss.
I don't think I can go back from DataGrip, though. Too many nice things I've gotten used to (query tabs, multi-format result exports, etc).
The nice thing about DataGrip as opposed to PG tools listed above is SQLServer support. (Sometimes you don't get to pick the database you'll be working with).
I particularly like the Date Picker: http://www.jetbrains.org/ring-ui/date-picker.html
Sun Mon Tue Wed Thu Fri Sat
http://www.jetbrains.org/ring-ui/examples/date-picker/date-p...
I'd like to hear someone explaining why it isn't awful to use with a mouse.
Yes, the released components do not cover a use case that they were not designed or intended to cover.
Yes, if your use case is exactly that, you will find these components less useful as you'll have to modify them.
Yet all of that is trite, and completely unfair criticism to wager against someone on the very first day of their components release.
The commenter is merely trying to push this into the cultural norm. I concur with such sentiments.
Taking the chance to "call out" its "lack", is essentially shaming people for doing social good (open source), and not going far enough in someone's opinion.
Also it is possible to call out a critical oversight in the design of a product while not shaming them for releasing it.
It's only linked in the comments; also - they're dogfooding issues in their own YouTrack thing. It looks like JetBrains does this for all their open source projects. Can anyone with some experience compare against GitHub's issues?
It's not perfect, but it hits more of the marks I'd want than anything else I've tried.
The problem with making a WYSIWYG designer for the web is that it's a Turing tarpit. There are three whole programming languages in there, interacting in weird ways, and programmers use all of them. So your UI designer has to either create something horrible that no human is expected to edit, which doesn't work for dynamic apps (see: Dreamweaver), or you have to constrain what the programmer can do. This means inventing a sensible API that's amenable to WYSIWYG.
We took the latter approach with Anvil - we've cut the Gordian knot of HTML/JS/CSS by implementing a (VB6-like) component model, with a pure Python API. While I am, of course, biased, I think that's probably the closest we can get to what you're wishing for.
(The reason for this is that our client and server are deeply integrated. This is what lets us, eg, return a live database view from server code into client code with a simple function call, with full autocomplete. But it does mean we can't do a one-click "export as a Flask app".)
If they used Javascript, you might be confused because they'd process your Javascript into other Javascript before it's used on the site, and you can edit it. That's a bit confusing isn't it?
Knowing to begin with that the input language is a whole separate thing, is less confusing.
If we used JS, it would be very difficult to maintain the firm layer of abstraction that gets us out of the Turing Tarpit.
Also, to a first approximation, people don't learn JS on its own. You only learn it if you're already learning traditional front-end development. That's a journey we explicitly want to save people from - so we didn't want to use a language that only web devs know.
Python is a lot easier to pick up for non-Pythonistas than JS is for non-web developers.
Perhaps we should write that blog post...
It looks like the example data isn't correctly set up.
Here are a couple of sample pages based on CxJS widgets:
- https://worldoscope.cxjs.io/4v5b3k2
- https://starter.cxjs.io/dashboards/sales
Full disclosure: It's a commercial framework, I'm the author.
Enterprise cares predominantly about hireability, and Javascript has been the only language for the web for decades. Everyone who even tangentially has a brush with web technologies knows it, and if your company has a frontend team you already have people at your company who know Javascript well.
I predict Javascript will continue to see growing use serverside, at least until the point ten years from now when WebAssembly is mature enough that people can develop for the frontend as well as the backend in any language.
Also, I hadn't heard of their Upsource product before, it looks really nice.