t1amat

10 ms·

61.
by t1amat 10y ago
Neat project and potentially worth playing with. Appears to be abandoned though, sadly.
62.
by t1amat 10y ago
Very nice! I'll shamelessly add a little Game of Life comparison in SVG[1] and REGL[2]. [1]: https://sketch.expo.io/H1Z4WGIix [2]: https://sketch.expo.io/HkjUrfIje
63.
by t1amat 10y ago
It may already exist: https://github.com/wix/react-native-invoke
64.
by t1amat 10y ago
Check out Xamarin Workbooks* for the C# equivalent. (*): https://developer.xamarin.com/guides/cross-platform/workbook...
65.
by t1amat 10y ago
If you are using redux, redux-persist is trivial to bake in and can rehydrate your redux state granularly.
66.
by t1amat 10y ago
With the exception of one or two outlying areas in the US, this is probably about spot on.
67.
by t1amat 10y ago
Yarn is categorically better than npm at dependency management, in addition to its speed. Yarn uses a lock file to pin exact versions no matter what semver range you choose. When you add another dependency, it does not have the side effec
68.
by t1amat 10y ago
Since it was posted about a month ago there has been on the order of 100+ commits from a variety of people. I'm hoping @jwilm pops in to respond: - Since it started getting community activity, where do you feel the direction of this is
69.
by t1amat 10y ago
I think you found my concern. When you are in your app code playing with native API's on the JS-side of the bridge, you are playing with mostly thin proxy objects. These proxy objects serialize your intent across the bridge, evaluate
70.
by t1amat 10y ago
While technically correct it's not very meaningful a distinction in context. I'm not tasked with developing all the code required for every platform, I simply have to describe it once. Native platforms will all run off the exact
71.
by t1amat 10y ago
I've been playing a lot with React Native over the last year; professionally for almost 4 months now. This really aligns with my experience. I don't share the same opinion of going back to native code though. This really is a fa
72.
by t1amat 10y ago
For the types of problems the author is describing, NativeScript would not be there to support you. NativeScript surfaces the device API's across the JS bridge, and the serialization across this bridge and pressure on it will always l
73.
by t1amat 10y ago
Either of these[1][2] will get you a good distance. Also, check out Awesome React Native[3] for a curated list. Even if you use one of these component libraries though you will just be deferring learning the basics of React Native layout a
74.
by t1amat 10y ago
It's the opposite - instead of React Native mapping HTML elements into appropriate native components, websites are just another platform target. You write your components using normal React Native components (Views, Text, ScrollView,
75.
by t1amat 10y ago
I should mention that developer ergonomics is another key differentiator. NativeScript exists for Telerik's bottom line. For example, instead of providing a nice HMR facility, they invested thousands of hours into building a pay-for
76.
by t1amat 10y ago
NativeScript is pretty neat, for sure. I'm guessing the reason it does not get nearly as much exposure on HN is because it's quite a bit less mature with a community at best an order of magnitude smaller than React Native. Or it
77.
by t1amat 10y ago
While I can see what the author is attempting to do (define a common set of root components that all platforms can use with some preference libs thrown in such as from the `Animated` project), it seems like this has already been done (`reac
78.
by t1amat 10y ago
I've actually had the opposite experience. I've built roughly a half dozen cross platforms mobile apps with React Native now and it has been a really fantastic experience. For the most part, most of the native modules I have con
79.
by t1amat 10y ago
Lumo[1] probably fits your use case perfectly. It's a ClojureScript REPL running in a NodeJS context. You have access to both bootstrap-ClojureScript-compatible libs as well as the whole NodeJS ecosystem. The REPL has some nice ergo
80.
by t1amat 10y ago
I thought the same. Their targets are Inferno and Preact.
81.
by t1amat 10y ago
npm would be substantially more suitable. Don't forget about Windows developers, please!
82.
by t1amat 10y ago
There are many code analysis engines for JavaScript that can be used as a plugin for code completion. One commonly available as a plugin to many extensible editors is TernJS[0]. [0]: http://ternjs.net/
83.
by t1amat 10y ago
I don't think anyone would argue that web development is perfect. What is? But, thanks to the ubiquity of the web browser, it is the only way to create a common user interface across any platform. Given that context I am grateful to
84.
by t1amat 10y ago
ALT -> View -> Developer -> Toggle Developer Tools
85.
by t1amat 10y ago
This is not true. Electron comes with the full suite of Chrome Dev Tools (CTRL-SHIFT-I is default when enabled). You can certainly achieve a live-coding experience with Electron[1]. [1]: one of many boilerplates - https://github
86.
by t1amat 10y ago
All of the above. If your application can be designed as a web application, you can use responsive designs and progressive enhancement techniques to create an experience that works across any platform with a web browser - with one code bas
87.
by t1amat 10y ago
There is nothing stopping you from merging the mainline history into your feature branch to pull in the latest changes. In fact you should be doing this every-so-often for any long-lived feature branch, but always before merging into the m
88.
by t1amat 10y ago
I quite enjoyed this documentary. It was on Netflix for a time, might still be.
89.
by t1amat 10y ago
Yes, this is possible. Angular and Elm could easily communicate through Elm's JavaScript FFI.
90.
by t1amat 10y ago
This is neat, and useful as a general purpose jump-to feature. It's probably worth mentioning that some languages have packages with better functionality for that language, such as tern-mode for JavaScript.

More ›