查看: 2157| 回复: 6
跳转到指定楼层
上一主题 下一主题
收起左侧

说说你知道的主流Web/Mobile Apps 开发框架的优劣

全局:

注册一亩三分地论坛,查看更多干货!

您需要 登录 才可以下载或查看附件。没有帐号?注册账号

x
比如:
         Web: javascript+java
         Mobile: Android + IOS   这种的

评分

参与人数 1大米 +2 收起 理由
KevinSAP + 2 给你点个赞!

查看全部评分


上一篇:有 Python开发岗 的大公司是不是很少?
下一篇:如何便宜的搞定Safari Books Online账号
推荐
lalxyy 2019-3-17 20:13:25 | 只看该作者
全局:
Web apps 后端:
个人比较喜欢C#那一套东西:尽管C#是在Java上面借鉴出来的,但是其后加入的很多modern programming language特性(比如delegate、async/await、甚至闭包/lambda以及在interface的一些开放性的设计也是比Java早好多的)让开发体验非常好。随着M$逐渐对社区友好,.NET Core应该是对于新兴web app大有可为的。其他喜欢的比较modern的语言还有Kotlin和Swift(这俩语言特别像)。
其次是Java,虽然是非常非常教科书的语言,但是从software engineering的角度来看,一些强制的regulation反而是好处——让代码比较清晰。我个人觉得Python duck typing这种设计虽然巧妙(利用了design patterns)但是不适合大型web app开发的,没有显式declare变量类型限制很容易在后期弄出bug。Java生态虽然比较保守但是没有那么固步自封吧,Spring生态体系的成长还是很让人喜悦的,尤其是Spring Boot开箱即用的开发体验非常棒。Spring生态还在持续进步,最新的Spring Framework 5提出的WebFlux给async RESTful API开了个好头。
现在带团队用的是Python/Flask,不得不说这套技术栈对于新上手web app dev的同学相当友好,有一些Python基础的同学很快就能上手写出Web API,开发生态也不错(想集成SQLAlchemy,JWT什么的都有现成的library),直接拿来用即可,大幅提高开发效率。但是目前比较头疼的就是前文所说的问题,缺乏编译时类型检查一定程度上增加了runtime error;当然,如果写好文档,这个问题能改善很多。software engineering归根结底其实是人的问题。

评分

参与人数 1大米 +1 收起 理由
csf0630 + 1 很有用的信息!

查看全部评分

回复

使用道具 举报

推荐
instant_dev 2019-3-20 09:10:37 | 只看该作者
全局:
这种Web/Mobile Apps 开发框架还是要分公司

主流大公司追求稳定, 后端 spring 全家桶 + 前端 angular/react 移动端 ios/android原生开发

创业小公司追求快速,后端 flask/django/nodejs + 前端 vue/react 移动端 react native / flutter

平时自己写个小项目的话,任何主流框架都能满足需求,主要看自己的喜好和熟练度
回复

使用道具 举报

🔗
pxu 2019-3-17 23:50:06 | 只看该作者
全局:
前端 reactjs 或angualarjs
Mobile: android,iOS (用swift) - 两种系统都 可以用第三方控件
后端:python,java,c#,go (都有各自的web 框架,其实什么语言都无所谓,都通过rest api 和json跟前端 spa(Single page application)通讯
回复

使用道具 举报

🔗
Scala688 2019-3-18 00:27:35 | 只看该作者
全局:
React , Native Android :  java/kotline , iOS :  object C , Swift,

Backend could be anything.

回复

使用道具 举报

🔗
xmanswer 2019-3-18 08:43:47 | 只看该作者
全局:
Backend: Go + Swagger全家桶 + k8s
Frontend: react

后端这一套搭CI/CD比较耗时繁琐,而且k8s需要self manage(最好另有team负责),但是一旦搭好写一个microservice跟玩儿似的。Go的语言特性就不多说了,上手快,自带框架,性能好;用Swagger把业务逻辑和API逻辑剥离开,doc gen,code gen,DTO序列化反序列化都很方便。缺点是开发stateless业务远好于stateful,k8s的statefulset还有很长一段路要走(比如前不久碰到的use case:想用EBS作s3的centralized local file cache,在不自己造轮子写一个EFS的前提下,不太可能在k8s上实现)。虽然这算是微服务架构的缺点,跟框架扯不上关系,但Swagger本身也是纯REST+Stateless,针对某些需要用到RPC的usecase就不抵事儿了。

评分

参与人数 1大米 +5 收起 理由
instant_dev + 5 很有用的信息!

查看全部评分

回复

使用道具 举报

🔗
myangelasuka 2019-4-20 01:33:51 | 只看该作者
全局:
20w 签字费。 感觉亚麻明显厚外薄里啊。。。 自家new grad 都这么欺负的嘛
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册账号
隐私提醒:
  • ☑ 禁止发布广告,拉群,贴个人联系方式:找人请去🔗同学同事飞友,拉群请去🔗拉群结伴,广告请去🔗跳蚤市场,和 🔗租房广告|找室友
  • ☑ 论坛内容在发帖 30 分钟内可以编辑,过后则不能删帖。为防止被骚扰甚至人肉,不要公开留微信等联系方式,如有需求请以论坛私信方式发送。
  • ☑ 干货版块可免费使用 🔗超级匿名:面经(美国面经、中国面经、数科面经、PM面经),抖包袱(美国、中国)和录取汇报、定位选校版
  • ☑ 查阅全站 🔗各种匿名方法

本版积分规则

>
快速回复 返回顶部 返回列表