Does this mean that Kotlin -> React -> React Native is feasible too? It's a bit ridiculous on its face, but is there a better way to run Kotlin on iOS? Kotlin is a godsend for Android but if you have to support both platforms one codebase is better
One codebase for both platforms is not necessarily what you want though.
Let me rephrase, it might be what you want for a pretty small app : if you have to create an app for a restaurant with orders and menu, a cross platform solution is probably the best use of your time.
For anything bigger, it becomes a harder sell. All these solutions tend to have the same downsides :
- limited access to new platform features. Especially damaging when Apple tells you that you are going to get featured if you do a Watch app but your SDK does not support that yet.
- one design does not scale well to two platforms with different UX and features.
- one more layer of abstraction to manage; making maintainability harder
I think that there is clearly a space for a cross platform business logic framework though. It tends to be the same on both platform with minor differences. It is a pity that only j2objc seems to clearly target this. k2objc/swift would be awesome.
Kotlin right now is a serious competitor for a full stack, any device language. An alternative may be F# which has Fable for Browser, Xamarin (mobile) and .net core for server. But Kotlin looks more integrated to me.
Coming from a C#/F# background, Kotlin is really a joy to use.
Yeah, if they play it right they can be one-size-fits-all solution. A question is if they would take risks with such approach as their motto is to "implement stuff that is winning", i.e. copying things others did and that worked well (in commercial sense) and avoid experimental stuff that doesn't bring money in.
There's an announcement and some example code for building iOS apps with Kotlin/Native here, including reusing some of the code across iOS and Android:
I'm waiting for Kotlin-based React Native alternative without any trace of JavaScript (in mobile). Kotlin JVM for Android and server rendering, Kotlin Native for iOS, Kotlin JavaScript for Web. Makes more sense than JavaScript everywhere.
How is the debugging experience? Is there a debugging experience?
I'm currently a typescript user and I like what VS code has going on with attaching to chrome and providing debugging within the ide. Source maps are okay but a seamless experience in the source language is better. Does the kotlin IDE have facilities for debugging what is going on in the browser?
You can debug the app in IntelliJ IDEA (and in the browser) and put the breakpoints in the Kotlin code, thanks to the source maps. It's kind of similar to what you get when debugging TS in VS Code, WebStorm or IJ: the IDE will open Chrome and connect to it. But it's not possible to avoid source maps – to debug you still need to compile the app to JS to run in the browser.
Actually, how do you debug those? If you put in a breakpoint, use DTrace & co or do logger output, you won't likely hit the issue. I did this with super low-level distributed systems and they were mostly resolved by hard thinking and modeling execution path in my head...
Once when developing with the 8051 family (using a development board that included a debugger), the program worked perfectly on the dev board, but when I burned it onto EEPROM, a subtle timing issue with a peripheral caused the program to fail. Much frustration ensued; had to develop that section with a long winded code->compile->burn->test cycle. Then we found out the particular 8051 variant we were using had been discontinued :(
Reason through the code. Sometimes, reason through the output assembler (in case the C code is making invalid assumptions). Stare at oscilloscope traces. Think really hard about what's happening, come up with a hypothesis, and test that hypothesis.
The hypothesis testing part is key. I've worked with embedded developers who "fix" a bug by making a code change, but can't at all explain why the change is likely to fix the bug. In many cases, the reason it seems to fix the bug is that it changes the timing just enough so that the bug happens less frequently, but without having a really solid causal explanation, it likely just means that it's going to be even harder to find the bug when it pops back up again.
Can I use this outside IntelliJ (Atom perhaps)? I despise JavaScript, GWT is underwhelming and Kotlin seems like a nice way to bypass these issues + React is becoming a de-facto standard. IntelliJ became too big/slow/feature creeped and I am not having good time with the latest code completion changes, so I am considering dropping it (PyCharm as well) for something more light-weight.
Well, I did comment once on the Koltin Jetbrains forum, about how hard they make to download ... just kotlin ... outside of the jetbrains ide
and their response, on their forum, was that they are intentionally make hard to avoid the jetbrains ide while using kotlin
now technically you still can, kotlin is open source, and you can download it standalone, if you search hard enough
i am not really sure, how jetbrains think kotlin will help it long term to increase its sales .. but this seems to be one of their objectives .. they did not create kotlin just for the sake of it (and nothing wrong with that)
I am happy JetBrains became a full-blown real software company (where I count only companies with their own programming language) instead of aping Atlassian (their main competitor), and Kotlin has some interesting ideas. They are closest to Borland we have these days; independent small company with quality development tools. Though the code completion quality dropped so much lately (e.g. in PyCharm it became completely useless) that I am now actively trying to find replacements.
>> Borland was .. a very traditional closed company
One of the great things about Borland was they published the source code to their VCL (their main platform library Delphi and C++ builder applications used). So you could read, learn from, troubleshoot and debug with the source code. At a time when Microsoft and most companies didn't.
And the VCL design patterns were/are incredibly elegant, and studying them an excellent and accessible way for an interested programmer to learn some real software architecture skills.
No idea; I do extensive tensorflow/keras/opencv/numpy/openai stuff and code completion there is a joke, I just get completely unusable hints. Maybe I am A/B tested by them or something, but I am forced to have browser with documentation/stack overflow opened these days. And IntelliJ used to be much better for me at around IDEA 12, since then code completion doesn't predict my typical choices at top places, I need to scroll down more and more. So that one is individual style-based. I also long for the days of simplicity as I refuse to keep huge amount of "how to do a certain thing in certain IDE" in my head; IDE should help me with the complexity of language and not impose another time sink on me.
Code completion has always been hit-or-miss in dynamic languages like python. Is it possible that something in your libraries (or maybe something in your programming style) changed such that the IDE can no longer make good guesses?
FWIW I've never found IntelliJ code completion in Javascript, Ruby, or Python to be very accurate. It's fantastic in Java and Typescript.
It's good you supplied the link, as you've misrepresented its contents somewhat. What they are discouraging downloads of is the standalone compiler, because if you want to compile outside of an IDE, gradle is the better choice.
As alternatives they suggest their online REPL (to play and learn without installing anything), IntelliJ (unsurprisingly their favourite), gradle, or maven. The latter are about as fully-fledged build systems as you can imagine and are easily used with any editor.
I'm sure there will be gradle plug-ins available for VS.Code or Atom, or a gradle mode for emacs.
Agreed with this. I use both React and Vue intensively, day to day. React and Vue both have pros and cons, but I would argue it's actually easier to optimize Vue apps.
Vue's reactive nature actually is superior, because something like Redux requires destroying, regenerating, and messaging around entire objects. This can create serious problems when, for example, trying to use Chrome APIs or manage component renders.
Also, although JSX is nice for developers, it's not friendly to designers. Vue, however, supports single file components that are very designer-friendly.
FWIW, Alibaba began creating their own native framework with Vue called Weex, which is now part of the Apache project. https://weex.apache.org/
Even more so when you consider that Vue itself is a React clone underneath. Templates compile directly into createElement calls internally and if you'd strip off Vue's outward complexity, the api surface, the syntax parsers, the observable system, etc., what would remain is React.
It has pretty decent TypeScript bindings iirc, but the fundamental thing it does is prevent the need to mix HTML and JS inline. If you can hold your nose at Javascript, most of the project generators for Vue.JS seem to prefer using ES6/ESnext syntax so the language is much more tolerable than, e.g. Angular and Circa-2007 JavaScript.
You definitely can. The only major requirement is Java being installed on your machine. This project installs Kotlin compiler and runtime as npm dependencies
I was trying to get this setup going the other day and found it a little fiddly with some of the Jetbrain’s documentation on Kotlin->JS being outdated it seemed and the sample application they have supplied having some issues with missing dependencies, specifically missing package versions on NPM. I’ll be trying this out straightaway, so many thanks for this!
Every time I set aside a few hours to do a React tutorial, I'm defeated by the stack.
I'm very late to docker. I always liked the idea, but didn't have the immediate need. But Python, trying to fix bugs in someone else's project, has now made that need urgent.
After spending WAY TOO MUCH TIME getting the exact right constellation of stuff installed. Switching from macports to homebrew, preinstalling the native libs, wiping all the misc failed python runtimes and starting over, bootstrapping pip, oops I screwed up once with sudo and now a hidden cache under /var/private/root is borking dependency resolution.
FFS.
I really hated Java & maven until I got a nodejs gig.
I really hated nodejs & npm until I had to fix someone else's python.
Can you clarify what you mean by "defeated by the stack"? Are you having trouble setting up a React development environment?
If you want to try using React without any build tooling or process at all, the main suggestions are:
- Use an online IDE like https://codesandbox.io , which is a complete online editor that lets you write React apps, view them in the browser, and even make use of NPM packages . CodePen and StackBlitz are other good choices for online editors.
If you do want a local project with the right build setup, the official Create-React-App tool will create projects with the build config abstracted away: https://reactjs.org/docs/installation.html
So, while the recommended way to use React is with a full build process (which lets you use the JSX syntax for rendering components, other modern JS syntax, and produces a proper bundle for deployment), you don't have to learn Webpack or Babel as a prerequisite for learning React.
Primarily because Kotlin is not a superset of javascript and thus does not inherit the quirks of javascript.
Other than that, if your backend is kotlin then you can potentially share (non JVM dependent) business logic code with the backed. Same goes for android clients. Same interfaces can be be used in client and server.
I've never really found a good use case for reusing business logic, but just reusing types is pretty helpful. Although you can also get that via something like Swagger as well.
I too am more of a fan of the Swagger/OpenAPI approach (in general terms), but I find it valuable to be able to share validation logic too. (Unless your validation requirements are extremely simple.)
Of course Swagger/OpenAPI doesn't preclude using the same language on the client and server side, so one could always combine "isomorphic" approach with the "service definition" approach.
Intriguing approach. Anyone know if there's a write-up somewhere from somebody that's tried it? It's always helpful to learn from the gotchas others have run into.
JS as a compilation target is supported by kotlin out of the box. You can use any js framework and IIRC it even understands typescript type annotations. I'm super pumped about kotlin, can't wait to write a whole app, backend and front-end in it.
This is all fairly new stuff so there're probably few users outside of JetBrains. Check out https://github.com/JetBrains/kotlinconf-app, it's all written in Kotlin — backend, frontend, everything.
