81–90 of 96 posts
It's under the Apache License and the components look pretty good. I particularly like the Date Picker: http://www.jetbrains.org/ring-ui/date-picker.html
This great! I'm sad that _none_ of these components were built with accessibility in mind.
That seems like a fair comment, I wonder why you're being downvoted?
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.
Earlier quoted context omitted.
We're trying! ( https://anvil.works ) 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 th…
Is there a blog post out there on the reasoning behind choosing Python instead of JavaScript for that component model + API? Just seems odd to add a 4th language to the mix.
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.
Earlier quoted context omitted.
Enterprises are already moving in this direction.
Facebook is a large geek shop; not how the vast majority of enterprises work or can work for that matter.
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.
Earlier quoted context omitted.
Is there a blog post out there on the reasoning behind choosing Python instead of JavaScript for that component model + API? Just seems odd to add a 4th language to the mix.
I'm just guessing but by using Python, they can go with a more robust module system, and there's a semantic break between Anvil's Language and its output. 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,…
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...
Earlier quoted context omitted.
That seems like a fair comment, I wonder why you're being downvoted?
Because it's neither constructive nor fair. The comment is merely "true". 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 relea…
The commenter is merely trying to push this into the cultural norm. I concur with such sentiments.
Earlier quoted context omitted.
Because it's neither constructive nor fair. The comment is merely "true". 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 relea…
if enough people call out the lack of accessibility in UI libraries, it brings that requirement into the cultural norm. 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.
Earlier quoted context omitted.
Oh, neat - I hadn't heard about that. 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).
DataGrip is awesome. Only complaint is the subscription model. 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).
Earlier quoted context omitted.
JetBrains is everything that Embarcadero aspired to be. It's perhaps the only for-profit organization I'm happy to give money to.
I was until their recent insistance to copy Adobe design and removing "distracting" colors in their UI. Also since their new licence scheme it seems releases quality can be hit or miss.