Anyone tried <http://www.vaadinonkotlin.eu/> ?
# servero
orangy
10/15/2018, 11:49 AM
Anyone tried http://www.vaadinonkotlin.eu/ ?
l
lex
10/15/2018, 11:53 AMOH! NO! š±
š 2
o
orangy
10/15/2018, 11:54 AM
Why?
m
Mike
10/15/2018, 12:03 PMPersonally, I think there are MUCH better options than Vaadin for web.
React Kotlin would be a reasonable choice IMO.
l
lex
10/15/2018, 12:14 PMWhy?it is so slow, may be for intranet only)
p
pavel
10/15/2018, 4:40 PMThere are better options than vaadin if you use Kotlin, but are there better options than kotlin if you use vaadin? š
š¤ 1
š 1
n
nfrankel
10/15/2018, 6:56 PMdefine ābetterā
o
orangy
10/15/2018, 7:04 PM
Itās JavaScript under the hood, itās all undefined š
š 1
p
pavel
10/15/2018, 7:05 PMwell, they could start using kotlin native and compile to wasm
n
napperley
10/15/2018, 7:22 PMPresumably the performance would be significantly better with the Kotlin Native via WASM approach.
n
nfrankel
10/15/2018, 7:28 PMthey could start using kotlin native and compile to wasmlet the whole web-assembly dry up a bit first i attended a talk by a mozilla engineer working on that letās say it needs āa bitā of maturity
n
napperley
10/15/2018, 7:31 PMAgree on the maturity part with WASM, especially the JS interop part. Only having Int supported is severely crippling.
napperley
10/15/2018, 7:32 PMWhere is WASM currently at with the high level language support?
n
nfrankel
10/15/2018, 7:35 PMthe only thing i was demoed was rust to wasm
and the javascript interop š
n
napperley
10/15/2018, 7:37 PMAka the browser vendors haven't clicked yet that support for high level languages with WASM is very important.
o
orangy
10/15/2018, 7:46 PM
Well, K/N is also in experimental status anyway, so they can go hand to hand. I wish we had more people actually experimenting with both of these things.
n
nfrankel
10/15/2018, 7:50 PM@orangy i tried to attend the workshop at kotlin conf
it seems quite complex for now
o
orangy
10/15/2018, 7:52 PM
If someone can make a comprehensive list of specific things that are missing, it would be easier to plan some work. I remember some notes by @sdeleuze and others, but I donāt a complete list.
p
pavel
10/15/2018, 7:54 PMLast time I looked at it I found IDE support to be lacking. I think I saw something somewhere that itās supposed to get better in an upcoming version so I guess itās time to take another look.
pavel
10/15/2018, 7:54 PMAnd I really liked that snake demo at kotlinconf
o
orangy
10/15/2018, 7:56 PM
It is already better. With latest RC builds you can open stuff in IntelliJ IDEA (Community), edit, build and run via Gradle. CLion & AppCode will eventually catch up (there are technical issues).
p
pavel
10/15/2018, 7:57 PMnice!
s
sdeleuze
10/15/2018, 8:02 PMWhat is missing is what I asked here https://kotlinlang.slack.com/archives/C3SGXARS6/p1539022464000100?thread_ts=1539022464.000100&cid=C3SGXARS6, a proper MP statically typed Web and DOM API common to Kotlin/JS and Kotlin/Native, and with latest Firefox experimental features languages like Go, Rust and Kotlin can move forward on that
sdeleuze
10/15/2018, 8:02 PMRust language is too low level so it will stick to libraries
sdeleuze
10/15/2018, 8:03 PMKotlin can go Native and is high level enough to make it possible to build frontend frameworks
o
orangy
10/15/2018, 8:04 PM
I need to actually try wasmā¦ Otherwise it is very hard to reason about thingsā¦
s
sdeleuze
10/15/2018, 8:05 PMAnd building a better Web and DOM API will benefit from both Kotlin/JS and Kotlin/Native + will provide a key competitive advantage compared to other serverside languages, the possibility to avoid loosing a lot of time on JS stacks
sdeleuze
10/15/2018, 8:06 PMYou don't use Wasm directly, just Kotlin/Native need to do what Rust guy do on rheir LLVM backend
o
orangy
10/15/2018, 8:06 PM
I kinda feel we might need a #webassembly channel. Itās not entirely #kotlin-native because it has a lot of specifics, and then itās not entirely #javascript
s
sdeleuze
10/15/2018, 8:07 PMAfter that with a proper Web and DOM api you can enable a frontebd ecosystem to arise
o
orangy
10/15/2018, 8:07 PM
k/n already can compile to wasm, right? or something is missing at this point?
s
sdeleuze
10/15/2018, 8:08 PMYes this is something I raised 2 years ago, this topic concern both #javascript and #kotlin-native, both teams need to work together on that
sdeleuze
10/15/2018, 8:08 PMEspecially with your MP capabilities
o
orangy
10/15/2018, 8:08 PM
Iāve created #webassembly
s
sdeleuze
10/15/2018, 8:10 PMThis missing point is a proper statically typed DOM and Web API even Kotlin/js does not really provide that yet as discussed with @bashor
sdeleuze
10/15/2018, 8:11 PMhttps://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%f0%9f%8e%89/ and all the work on Mozilla side on Rust is worth to follow
o
orangy
10/15/2018, 8:12 PM
Letās continue in that channel, it would be easier to find stuff there later.
s
sdeleuze
10/15/2018, 8:12 PMNot sure this has to be specific to #webassembly, I was wondering if #javascript could not be turned into #frontend to have a place where Kotlin/JS and Kotlin/Native people can work together
o
orangy
10/15/2018, 8:13 PM
Well, in a thread in a #server it doesnāt have any chance š
s
sdeleuze
10/15/2018, 8:13 PMOk I will send more info on #webassembly tomorrow then
o
orangy
10/15/2018, 8:13 PM
Cool, thanks.
b
bashor
10/15/2018, 9:02 PMHonestly, I donāt fully agree with the statement.
https://kotlinlang.slack.com/archives/C0B8RC352/p1539634204000100?thread_ts=1539604176.000100&cid=C0B8RC352
bashor
10/15/2018, 9:02 PMHowever, I agree that there are things that we have to improve, e.g. add a documentation to declarations.
d
DALDEI
10/15/2018, 11:13 PMRe: vaadin kotlin: IMHO -- its awesome. But its not for everyone. For me, I spent years looking for my next UI framework and ended up with vaadin + kotlin -- very happy. Be careful not to pigenhole the product -- in V8,10,+ it has somewhat bifurcated into 2 target use cases -- predominantly Web Components, HTML+CSS authored , plus the more 'traditional' Java/server centric authoring. They can co-exist. Its definitely 'oppinionated' -- like Gradle and Kotlin are š My estimation is that using vaadin+kotlin I can not only produce higher quality web apps 10x faster and 10x-50x less LOC then other frameworks I've used -- but also, more importantly, simply able to do things that were impossible or impossible time consuming otherwise. It holds up to real world (aka the 99% of the applications that drive the business world -- the 'boring' ones š Ping me if you would like more opinionated opinions. -- I have not had to write 1 line of JavaScript , CSS or HTML -- performance is reasonable and can be targeted optimzied if you want to spend the effort on it, conversely it can do things pure browser apps simply cannot -- or it can be a pure browser app.
n
nfrankel
10/16/2018, 6:41 AM@DALDEI whatās your take on v10?
iāve been a huge vaadin fan since v4
because it abstracted away a lot of html/javascript concerns for backend devs
with v10, i feel theyāve completely embraced the front-end
so it doesnāt feel as nice for backend devs
and of course they cannot compete with angular/react/ember/etc.
plus some of the API seems halfway finished
d
DALDEI
10/16/2018, 6:50 PMI am new to vaadin as of this year. I had several discussions with internal eng team at vaadin, my personal take on this, for my use, is that Im not intersted in v10 at this time. The goal is that v10 (and v10+) will suport both modes of development 'equally'. You can do both 'java/server centric' or 'html/browser/css' centric development with full parity. The reality, IMHO, is that this isnt quite yet achieved but its very clear that its intended -- you can use v10 in a pure-java-server dev mode like v8,v7 etc -- but with less then complete coverage right now. Since my use case and skill set are server-side and I dont want to do HTML /CSS work, right now there isnt much advantage to v10 and some disadvantages. I plan on staying on v8 for the forseeable future. That said, I'll be watching V10+ to see if they do achieve their goals -- the 'widgetset' (html elements/components) in V10 are quite good -- but not yet fully realized via the server API.
DALDEI
10/16/2018, 6:51 PMI was assured that both v8 and the entiere 'server side first' developement experience is a critical feature for vaddin going forward -- that they will not be depricating server-side-first developement / java-api develpement in any forseeable releas3e.
DALDEI
10/16/2018, 6:54 PMSO ... for me, v8 is the 'bleeding edge' of Vaadin (and +kotlin)) and I have no plans on moving to v10 () and no indication that is going to be a business problem wrt to product support and prioritzaiton. () Presumably at some point V10 or v10+ will have filled out the full java/server API side at which point an upgrade may be in order.
n
nfrankel
10/16/2018, 8:12 PMthanks @DALDEI
that (unfortunately) confirms my general feeling
d
DALDEI
10/16/2018, 8:48 PMI recall also being told that at such point the 'new' architecture (Elemental/V10+ ) is considered mature and 'the path going forward' that vaadin will provide compatibility and upgrade tools to make it easier, considering fundamentally many of the api's have to be different its not a no-brainier upgrade.
Note: this is my recollection
DALDEI
10/16/2018, 8:52 PMIndependent of version -- I found Kotlin + Vaadin to be a very good mix. I use the 'karibudsl' library (parto of 'vox' ) -- it is simple and concise and not heavily inter-dependant -- i.e. you can pick and choose when to use straight java conventional calling or the DSL, under the hood its the same objects. But given the nature of concise DSL's I do not recommend learning Vaadin, Kotlin, and Vox all at the same time -- I did, and it was a struggle -- too much unfamiliar at once.