f******2
发帖数: 2455 | 1 想做跨平台native app，几个问题
1、技术选型用ionic是不是目前看最好的选择了？
1.1、研究了一下网上的意见，说会产生潜在的performance问题，有没有使用过的朋友
分享一下
2、learning curve如何？隐形的坑有多少，社区解决的快吗？
另外，感谢其他相关的实战分享 |
c*********e
发帖数: 16335 | 2 老老实实用java, swift做native app.如果跨平台，用responsive 做web app就好了。
【在 f******2 的大作中提到】
: 想做跨平台native app，几个问题
: 1、技术选型用ionic是不是目前看最好的选择了？
: 1.1、研究了一下网上的意见，说会产生潜在的performance问题，有没有使用过的朋友
: 分享一下
: 2、learning curve如何？隐形的坑有多少，社区解决的快吗？
: 另外，感谢其他相关的实战分享
|
f******2
发帖数: 2455 | 3 2. web app不好推广，现在已经过了SEO的时代了，想借用appstore做推广。
1. swift和java两套班子，队伍撑不住，没那么大摊子。
【在 c*********e 的大作中提到】
: 老老实实用java, swift做native app.如果跨平台，用responsive 做web app就好了。
|
s********k
发帖数: 6180 | 4 先上一个，或者iOS，或者android，糙快猛现在被误导了，最近统计美国用户平均一个
月下载新app基本为0，别人做得好的尚且可能没机会被下载，你糙快猛的机会就更小，
尤其还是需要AppStore推广的
【在 f******2 的大作中提到】
: 2. web app不好推广，现在已经过了SEO的时代了，想借用appstore做推广。
: 1. swift和java两套班子，队伍撑不住，没那么大摊子。
|
W***o
发帖数: 6519 | 5 如果不需要native的性能，完全可以考虑上react-native
我最近做完了一个iOS的，现在web 和 Android 同时用react/react-native做，这两个
复用代码可以达到95%左右吧；如果不是追求iOS native的用户体验，三个平台都可以
用react做
【在 f******2 的大作中提到】
: 想做跨平台native app，几个问题
: 1、技术选型用ionic是不是目前看最好的选择了？
: 1.1、研究了一下网上的意见，说会产生潜在的performance问题，有没有使用过的朋友
: 分享一下
: 2、learning curve如何？隐形的坑有多少，社区解决的快吗？
: 另外，感谢其他相关的实战分享
|
l*********s
发帖数: 5409 | 6 这么高？大牛推荐下react native的书？
【在 W***o 的大作中提到】
: 如果不需要native的性能，完全可以考虑上react-native
: 我最近做完了一个iOS的，现在web 和 Android 同时用react/react-native做，这两个
: 复用代码可以达到95%左右吧；如果不是追求iOS native的用户体验，三个平台都可以
: 用react做
|
W***o
发帖数: 6519 | 7 我没看书，估计马鬃上面有书吧
看几个hello-world toy就差不多可以开工了，有问题看文档或stackoverflow
【在 l*********s 的大作中提到】
: 这么高？大牛推荐下react native的书？
|
W***o
发帖数: 6519 | 8 上个周末花点时间把之前用node.js做的monolithic后台拆分成microservices，放在不
同的docker里面，发现这样维护起来更方便了，至少不会整个app瘫痪不work了 |
c******n
发帖数: 16666 | 9 我觉得你说的有道理
我看几个小startup都是先上一个再上一个 下面一群用户哭着问啥时候上安卓 啥时候
上ios
现在大家都挑剔 猛糙快上去了 第一印象坏了很难弥补
【在 s********k 的大作中提到】
: 先上一个，或者iOS，或者android，糙快猛现在被误导了，最近统计美国用户平均一个
: 月下载新app基本为0，别人做得好的尚且可能没机会被下载，你糙快猛的机会就更小，
: 尤其还是需要AppStore推广的
|
w********m
发帖数: 1137 | 10 感觉走react是条捷径。
先出web，还是先出mobile可以随意。 |
|
|
c******n
发帖数: 16666 | 11 数据库你是怎么处理的
看了几个做法 要么I/O不高 要么overhead太大
【在 W***o 的大作中提到】
: 上个周末花点时间把之前用node.js做的monolithic后台拆分成microservices，放在不
: 同的docker里面，发现这样维护起来更方便了，至少不会整个app瘫痪不work了
|
W***o
发帖数: 6519 | 12 没啥好办法，目前用的自制docker + mongo 容器 cluster ，以后如果需要scale out
再说了
【在 c******n 的大作中提到】
: 数据库你是怎么处理的
: 看了几个做法 要么I/O不高 要么overhead太大
|
c*********e
发帖数: 16335 | 13 node.js怎么防止sql injection的？
没啥好办法，目前用的自制docker + mongo 容器 cluster ，以后如果需要scale out
【在 W***o 的大作中提到】
: 没啥好办法，目前用的自制docker + mongo 容器 cluster ，以后如果需要scale out
: 再说了
|
x****u
发帖数: 44466 | 14 nosql
out
【在 c*********e 的大作中提到】
: node.js怎么防止sql injection的？
:
: 没啥好办法，目前用的自制docker + mongo 容器 cluster ，以后如果需要scale out
|
ET
发帖数: 10701 | 15 给个app link？
【在 W***o 的大作中提到】
: 上个周末花点时间把之前用node.js做的monolithic后台拆分成microservices，放在不
: 同的docker里面，发现这样维护起来更方便了，至少不会整个app瘫痪不work了
|
W***o
发帖数: 6519 | 16 还没上架呢，不过快提交了
【在 ET 的大作中提到】
: 给个app link？
|
h******b
发帖数: 6055 | 17 ionic是最适合有web开发经验的人使用的框架。 不需要学习新技术，angular是web最
火的框架，直接封装运行。
你可以在ionic creator先drag and drop一个界面流程来给客户看，然后export代码出
来写，美化。
你可以看看ionic showcase的app，几百万下载的app大把。 app最终还是看构思，设
计，和美工。 现在手机性能过剩，除非是heavy图像/animation/游戏类的，ionic足
矣。
react native相对来说成功案例比较少，感觉只有脸书在用。 而且他是web框架
abstract原始api, 学习起来比ionic成本高很多。 |
p**r
发帖数: 5853 | 18 大神，指点一把
react native和native用户体验上差多少，或者说主要区别在哪里？
我最近要重写个视频类app，类似netflix，但是用户数比他们少几个数量级。
给点建议，注意事项，让俺少跳一些坑。
【在 W***o 的大作中提到】
: 如果不需要native的性能，完全可以考虑上react-native
: 我最近做完了一个iOS的，现在web 和 Android 同时用react/react-native做，这两个
: 复用代码可以达到95%左右吧；如果不是追求iOS native的用户体验，三个平台都可以
: 用react做
|
n*****3
发帖数: 1584 | 19 我们组最近在准备上docker，
要自己学一下
请问有什么book ， 或 video 教程 推荐吗？
不是要多func6， docker 加 GitHub加 jenkins
就成
没啥好办法，目前用的自制docker + mongo 容器 cluster ，以后如果需要scale
out
【在 W***o 的大作中提到】
: 没啥好办法，目前用的自制docker + mongo 容器 cluster ，以后如果需要scale out
: 再说了
|
W***o
发帖数: 6519 | 20 网上随便搜一下会出来一大把，我也是大概10天前才开始正式用起docker来，以前只是
略懂皮毛。
我觉得比较有用的可以看看docker-compose，这个用来set up 一群docker 容器狠方便
，Dockerfile基本不用学，就好像写DOS命令行
另外一点，可以去docker hub看看，基本popular的服务器都有打包好的，实在不需要
从bare bone比如ubuntu开始安装各种环境软件；比如我用mongodb，就在上面找最新的
image－ mongo:latest，添加到docker-compose.yml 里
面，build 自动会去pull下来给你安装好；如果你把code文件夹mount到相应的docker
，部署
一群services简直就是分分钟的事儿。
最后还发现一个捷径，在github上搜一搜，可能已经有人给你写好了docker-compose.
yml文件，托下来稍微改一改就能立马跑起来。只要有docker-compose.yml/Dockerfile
文件，换server host就好比换个厕所蹲位一样简单
记得n年以前架设一个LAMP + FFMPEG 服务器也要吭哧吭哧的半个小时，各种gcc
compile，不得不说docker确实高效
多了
【在 n*****3 的大作中提到】
: 我们组最近在准备上docker，
: 要自己学一下
: 请问有什么book ， 或 video 教程 推荐吗？
: 不是要多func6， docker 加 GitHub加 jenkins
: 就成
:
: 没啥好办法，目前用的自制docker + mongo 容器 cluster ，以后如果需要scale
: out
|
|
|
ET
发帖数: 10701 | 21 使用docker真没什么特别需要学的。
使用和部署到amazon 都是1天内能运作起来的。
【在 n*****3 的大作中提到】
: 我们组最近在准备上docker，
: 要自己学一下
: 请问有什么book ， 或 video 教程 推荐吗？
: 不是要多func6， docker 加 GitHub加 jenkins
: 就成
:
: 没啥好办法，目前用的自制docker + mongo 容器 cluster ，以后如果需要scale
: out
|
n*****3
发帖数: 1584 | 22 谢谢 ， 更我Google 后感觉的一样，
这东西 只会 越来越简单， 不值得 dig into IT
像 Hadoop 一样， 现在 只要 会点 Python 或 SQL 就可以上手
docker
【在 W***o 的大作中提到】
: 网上随便搜一下会出来一大把，我也是大概10天前才开始正式用起docker来，以前只是
: 略懂皮毛。
: 我觉得比较有用的可以看看docker-compose，这个用来set up 一群docker 容器狠方便
: ，Dockerfile基本不用学，就好像写DOS命令行
: 另外一点，可以去docker hub看看，基本popular的服务器都有打包好的，实在不需要
: 从bare bone比如ubuntu开始安装各种环境软件；比如我用mongodb，就在上面找最新的
: image－ mongo:latest，添加到docker-compose.yml 里
: 面，build 自动会去pull下来给你安装好；如果你把code文件夹mount到相应的docker
: ，部署
: 一群services简直就是分分钟的事儿。
|
d*******r
发帖数: 3299 | 23 不是自己在 Ubuntu 里一行行配置出来的，以后出了啥问题，我感觉比较难 trouble
shooting.
所以我觉得 docker 还是打包自己配置的环境比较好.
docker
【在 W***o 的大作中提到】
: 网上随便搜一下会出来一大把，我也是大概10天前才开始正式用起docker来，以前只是
: 略懂皮毛。
: 我觉得比较有用的可以看看docker-compose，这个用来set up 一群docker 容器狠方便
: ，Dockerfile基本不用学，就好像写DOS命令行
: 另外一点，可以去docker hub看看，基本popular的服务器都有打包好的，实在不需要
: 从bare bone比如ubuntu开始安装各种环境软件；比如我用mongodb，就在上面找最新的
: image－ mongo:latest，添加到docker-compose.yml 里
: 面，build 自动会去pull下来给你安装好；如果你把code文件夹mount到相应的docker
: ，部署
: 一群services简直就是分分钟的事儿。
|
W***o
发帖数: 6519 | 24 这个就是看具体需要了，我觉得docker的哲学是一个容器只做一件事，所以我觉得一行
行的配置真的是看项目需要；可以自己配置好了commit 后做一个image推到docker hub
以飨读者，就好像github里的开源项目一个思路
【在 d*******r 的大作中提到】
: 不是自己在 Ubuntu 里一行行配置出来的，以后出了啥问题，我感觉比较难 trouble
: shooting.
: 所以我觉得 docker 还是打包自己配置的环境比较好.
:
: docker
|
c******n
发帖数: 16666 | 25 react怎么样 我这边one-man-shop 感觉一个人搞这个压力有点大
最近在比较vue
hub
【在 W***o 的大作中提到】
: 这个就是看具体需要了，我觉得docker的哲学是一个容器只做一件事，所以我觉得一行
: 行的配置真的是看项目需要；可以自己配置好了commit 后做一个image推到docker hub
: 以飨读者，就好像github里的开源项目一个思路
|
W***o
发帖数: 6519 | 26 我觉得react用起来比angular要灵活一些，但是boilerplate好像多一点，目前感觉
react却少的东西就是类似angular里面的directive和一些filter，这些导致代码看起
来不够DRY
【在 c******n 的大作中提到】
: react怎么样 我这边one-man-shop 感觉一个人搞这个压力有点大
: 最近在比较vue
:
: hub
|
f******2
发帖数: 2455 | 27 对比react和angular，关键是angularjs2让人们无法适从。
ionic宣称支持2，但是估计会有很大的delay和bug频繁期。
google有出了名的不顾老版本维护，用1无异于慢性自杀
: 我觉得react用起来比angular要灵活一些，但是boilerplate好像多一点，目前
感觉
: react却少的东西就是类似angular里面的directive和一些filter，这些导致代
码看起
: 来不够DRY
【在 W***o 的大作中提到】
: 我觉得react用起来比angular要灵活一些，但是boilerplate好像多一点，目前感觉
: react却少的东西就是类似angular里面的directive和一些filter，这些导致代码看起
: 来不够DRY
|
c******n
发帖数: 16666 | 28 周末我看了下vue
大方向是好的 但是有个问题和react一样不是很适合我这边
他们做的太窄了 虽然轻便灵活了 但是啥都要自己配
第三方lib鱼龙混杂 我这边就一个人 真折腾不起 随便一个lib都要要看源码查为啥不
work
【在 f******2 的大作中提到】
: 对比react和angular，关键是angularjs2让人们无法适从。
: ionic宣称支持2，但是估计会有很大的delay和bug频繁期。
: google有出了名的不顾老版本维护，用1无异于慢性自杀
:
:
: 我觉得react用起来比angular要灵活一些，但是boilerplate好像多一点，目前
: 感觉
:
: react却少的东西就是类似angular里面的directive和一些filter，这些导致代
: 码看起
:
: 来不够DRY
:
|
a9
发帖数: 21638 | 29 没人试过aurelia吗？
【在 W***o 的大作中提到】
: 我觉得react用起来比angular要灵活一些，但是boilerplate好像多一点，目前感觉
: react却少的东西就是类似angular里面的directive和一些filter，这些导致代码看起
: 来不够DRY
|
c******n
发帖数: 16666 | 30 也还在beta当中
还没细看
【在 a9 的大作中提到】
: 没人试过aurelia吗？
|
|
|
W***o
发帖数: 6519 | 31 没试过，最近倒是试了一下cycle.js，挺喜欢它的人机cycle理论，但是代码写起来有
点拧巴，建立在RxJS (reactive)框架上的，看起来挺有意思，但还没看到有人在
production里面用
【在 a9 的大作中提到】
: 没人试过aurelia吗？
|
h******b
发帖数: 6055 | 32 a1很久以内都会是主流框架，目前他的使用率还是react/a2之和。
要是真的有几年以后还需要大量工作量的产品，你已经非常火了，改框架也不是大问题
。 那时migration的工具会成熟很多。
大部分产品几年以后就不会有大变化了，小修小补在a1上搞一辈子也不是问题。
值得更新=产品足够成功=更多工作机会给程序员=良性循环。
【在 f******2 的大作中提到】
: 对比react和angular，关键是angularjs2让人们无法适从。
: ionic宣称支持2，但是估计会有很大的delay和bug频繁期。
: google有出了名的不顾老版本维护，用1无异于慢性自杀
:
:
: 我觉得react用起来比angular要灵活一些，但是boilerplate好像多一点，目前
: 感觉
:
: react却少的东西就是类似angular里面的directive和一些filter，这些导致代
: 码看起
:
: 来不够DRY
:
|
w********m
发帖数: 1137 | 33 Angular 1用template就好足够了，
现在非往component的路线上靠
template + component碎片化啊吐
被google弄死指日可待 |
P**H
发帖数: 1897 | 34 a1在桌面上没问题。但移动端就吃力了。ionic在Android滑动都费劲。而现在偏偏移动
是市场大头。
a2和react native还是方向。
【在 h******b 的大作中提到】
: a1很久以内都会是主流框架，目前他的使用率还是react/a2之和。
: 要是真的有几年以后还需要大量工作量的产品，你已经非常火了，改框架也不是大问题
: 。 那时migration的工具会成熟很多。
: 大部分产品几年以后就不会有大变化了，小修小补在a1上搞一辈子也不是问题。
: 值得更新=产品足够成功=更多工作机会给程序员=良性循环。
|
h******b
发帖数: 6055 | 35 没那么不堪的。 安卓jellybean以后基本上很平滑了。 ionic 1好歹也是两万五星的
项目，对scrolling做了很多优化。
【在 P**H 的大作中提到】
: a1在桌面上没问题。但移动端就吃力了。ionic在Android滑动都费劲。而现在偏偏移动
: 是市场大头。
: a2和react native还是方向。
|
P**H
发帖数: 1897 | 36 ionic1的scrolling在android上已经是历史遗留问题了。可能最新的机器好点。稍微老
一点的机器，比如一年前的，就会有问题。目前一个workaround就是自己把开源的
chromium/webkit打包进去。这样做，app又会很大。凭空多了几十M。
没有说ionic 1完全不好。只是有些细节问题上还是要注意。
a2很大程度是为了解决mobile的问题。
【在 h******b 的大作中提到】
: 没那么不堪的。 安卓jellybean以后基本上很平滑了。 ionic 1好歹也是两万五星的
: 项目，对scrolling做了很多优化。
|
w********m
发帖数: 1137 | 37 a2的野心太大了，one framework。
架子这么开，就那么几个人几杆枪，资源不够用，只有跳票了。
前端主要还是公司给想法，然后社区推。
这方面react做到不错。 |
l*********s
发帖数: 5409 | 38 关键是公司得吃自己的狗粮。
【在 w********m 的大作中提到】
: a2的野心太大了，one framework。
: 架子这么开，就那么几个人几杆枪，资源不够用，只有跳票了。
: 前端主要还是公司给想法，然后社区推。
: 这方面react做到不错。
|
P**H
发帖数: 1897 | 39 公司盘子太大，吃不起的。只有一些边缘随便砍的项目可以玩玩。
【在 l*********s 的大作中提到】
: 关键是公司得吃自己的狗粮。
|
