TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

You probably don't need that hip web framework

73 点作者 bfoks大约 6 年前

14 条评论

btown大约 6 年前
SPAs become necessary when the user experience requires bells and whistles, like cross-widget consistency of like&#x2F;friend request counts (the original use case of React IIRC).<p>It&#x27;s not &quot;you ain&#x27;t gonna need it,&quot; it&#x27;s &quot;you are gonna need it, users will judge you by your fluidity, sure it&#x27;s overkill right now, but the overhead may be less than the pain of a frontend rewrite since you may need it soon.&quot;<p>I&#x27;ve often thought that if there was a way to gradually <i>codegen</i> a <i>fluent</i> React codebase from Django&#x2F;Rails&#x2F;Laravel server-focused frameworks, and move template-by-template into a rich frontend + API, a lot more people would start with those server-focused frameworks, because there wouldn&#x27;t be a need for a full rewrite. It would be a holy grail for our industry and let us develop business apps way faster. Not an easy problem to solve. Email me if anyone reading this wants to chat though!
评论 #19559855 未加载
评论 #19559583 未加载
评论 #19560648 未加载
评论 #19566238 未加载
评论 #19563540 未加载
013a大约 6 年前
I feel very strongly about this: The single most important thing for a growing software project is Using Opinionated Tooling.<p>Too many new projects, libraries, frameworks, etc come around and broadcast &quot;we&#x27;re Unopinionated!&quot; like that&#x27;s some great thing.<p>You cannot, without exception, develop complex software without asserting and extrapolating opinions about design patterns, tools, frameworks, layout, etc somewhere in the stack. Its impossible. You&#x27;ll end up with an unmaintainable mess.<p>Medium and Large companies will naturally develop a bunch of internal opinions about things. Internal tooling. CI. Development and Deployment environments. Those are all opinions that get built up over time, based on the experiences of the people who build them. This is fantastic; its how companies like Google and Amazon have reached such massive scale, but how many other companies start failing when they try the same.<p>Small companies and Startups do not have these opinions. They <i>have</i> to outsource their opinions, at least at the start. A large company might say &quot;yeah we have our own blackboxed JS serverside framework, just use that it&#x27;ll do logging, tracing, error reporting, its great.&quot; Small companies won&#x27;t have that. So, use Rails, or Phoenix, or something that is highly opinionated. Learn what works. Learn what doesn&#x27;t.<p>This is Javascript&#x27;s fatal flaw. And it is massive. And it still has not been improved years later. There is an extreme lack of opinionated tooling. NextJS has been doing some very interesting work introducing a more productive and opinionated frontend development experience. The backend really has nothing similar; the closest we got was Meteor, and it has&#x2F;had too many weird technical issues and poor design choices to be considered a good choice. The team behind it then mostly moved to Apollo, which reverted back to championing how unopinionated it is.
评论 #19560068 未加载
burlesona大约 6 年前
At the end of the post he mentions what I think is a really under-rated approach: a “normal” server rendered application with Vue components used per-page when the UI is highly dynamic.<p>I’ve built a relatively large app this way and found it to be quite nice. Vue works very nicely inside the container elements in the page where I need it, and it’s pretty easy to bootstrap the initial state into the page using the same serializers I do for JSON endpoints, so once it’s rendered users can spent a lot of time on a particular screen without any further page loads.<p>The last bit that’s nice is bundle size. It’s not too hard to split bundles based on unique entry pages, so you can end up with something like 30kb of “global” JS and then a second bundle for the big meaty pages that may range from 20 - 200kb. With caching that means 90% of screens have a very small payload and load really fast, and the rest have a slightly slower first load and then the same perf profile.<p>This has been a highly productive way to work, I’m surprised that it’s not written about more often.
评论 #19559850 未加载
评论 #19562577 未加载
评论 #19559995 未加载
TJTorola大约 6 年前
You probably need the right tool for the job. I&#x27;d argue that react, Vue, and company are only best for true web _applications_, that is highly stateful projects that are more akin to standard desktop apps than web pages, ex: google docs.<p>If you need server side rendering that could be a sign that what you have is a lot of public indexable information and that most often describes a traditional web site instead. In that case your &quot;old school&quot; rails or laravel solutions are almost definitely a better choice.
api_or_ipa大约 6 年前
Why do we keep seeing posts like this? My team <i>absolutely</i> needs React&#x2F;Redux&#x2F;Sagas&#x2F;Webpack&#x2F;whatever-you-want-to-hate-on-today, to ship and yeah we ship our backend with Docker. Why do I know we need it? Because we have years of experience in our workflow and we understand the problems we need to solve in the development workflow and timeline our company uses. Do you know who <i>doesn&#x27;t</i> understand our needs? Someone writing a low-quality post about how _their_ specific needs can be met with existing technology. Please just leave me be and go focus on solving your own problems, I wouldn&#x27;t be using this technology if I didn&#x27;t think it worked better than anything else.<p>&#x2F;rant.
评论 #19559843 未加载
评论 #19559753 未加载
评论 #19559909 未加载
评论 #19559752 未加载
评论 #19560102 未加载
评论 #19560605 未加载
评论 #19559964 未加载
评论 #19559784 未加载
评论 #19561180 未加载
评论 #19559771 未加载
评论 #19559961 未加载
dwheeler大约 6 年前
In short: Pick the right tool for the job. Some projects need systems like React; some don&#x27;t. A lot of projects do <i>NOT</i> need complex underlying systems - and some do. It&#x27;s sad that &quot;pick the right tool for the job&quot; is somehow controversial.
评论 #19563023 未加载
drivingmenuts大约 6 年前
To be honest, I’m still fine with jQuery and Laravel. I’ve looked at React and Vue and while they are marvels, I ain’t got that kind of time.<p>But, I also don’t write mobile apps. I’m dealing with desktop and the rules are different there.
评论 #19560257 未加载
wwweston大约 6 年前
&quot;Probably&quot; perhaps overstates the case, but it&#x27;s fair to imply there should be a <i>question</i> about if you need it, and the default answer should not always be yes.<p>Here&#x27;s some heuristics I like:<p>If nearly all of your application&#x27;s data presentation&#x2F;processing needs map cleanly to HTTP&#x2F;REST semantics for the various entities in the system... you probably don&#x27;t.<p>If your UX involves representing&#x2F;manipulating the same data in several different ways on the page and this data is going to change, <i>especially</i> in ways that don&#x27;t map cleanly to HTTP semantics, you should consider that you do need the hip framework. Probability rises depending on how frequently user interactions produce different views of the data.<p>If your data is a headache to represent in HTML, you probably do (also, if you don&#x27;t have an adequate general automated way to represent your data in HTML from some model description, you will likely either gravitate to solving this problem one way or another, or gravitate to a hip front-end framework).<p>If you ask yourself what problem you&#x27;re solving with your front-end framework, and the answer either includes the word &quot;modern&quot; or another adjective describing a merit you aren&#x27;t exactly sure relates to a specific problem to be solved, then you probably can&#x27;t yet make an informed decision about whether you need that hip web framework. But, OTOH, making uninformed decisions is one way of getting the experience necessary to make informed ones, so...
dfee大约 6 年前
The promise of front end frameworks is realized by startups when using a BaaS (backend as a service) - like Firebase.<p>The idea is that you only have to worry about one environment (the browser - yeah, I get the irony) and one deployment instead of multiple (the former plus backend deployment, monitoring, etc.).<p>The second you start worrying about SSR (server side rendering) you’re suddenly taking on the complexity of writing a backend again.
评论 #19559622 未加载
coleifer大约 6 年前
&gt; your first version of your idea almost always doesn&#x27;t need that hipster web framework you&#x27;re thinking about using.<p>No, but I bet your last version will have. Right before it fades into obsolescence, never to be seen again.
leowoo91大约 6 年前
I ve been using Jquery since long time where almost every frontend article says it&#x27;s an antipattern. But it&#x27;s never gonna give me up, never gonna let me down.
rcarmo大约 6 年前
Even though I do some Angular now and then, I still reach for RiotJS (and D3) whenever I want to build a PoC. A lot of front-end stuff is just too complex to iterate upon quickly and with minimal tooling (I keep changing machines, and the overhead of setting up new projects&#x2F;workspaces every time has always been a pain, even with the umpteen Node-based bootstrapping tools of the post-Yeoman era).
Cyclone_大约 6 年前
He mentioned that it took a long time to get going with some of the frameworks to get an MVP but the advantage of most of those is that while they take time more to learn you&#x27;ll be more productive with them in the long run and there will be less spaghetti code.
gsklee大约 6 年前
The frontend landscape has actually been relatively stable over the last 2 years or so, with no major new contender coming up because things on the table now are all very mature. I don&#x27;t foresee this to change any time soon with React and Vue, both really robust and complete, covering up two extremes of the spectrum.<p>The fact these recurring shitposts always began their rants with how freaking fast things are moving (in the speed they perceived) and that they couldn&#x27;t keep it up strongly suggested that they&#x27;re outta the loop for a long time or they aren&#x27;t good frontends in the first place. It&#x27;s also really harmful to the industry; I&#x27;ve seen a few frontend wannabes backing out because of all these uncalled for FUDs creating mental barriers for newcomers while I&#x27;ve repetitively tried to assure them it&#x27;s really not that unstable in recent years.