我的团队一直在使用 Node.js、Twitter Boostrap、Mongo DB 和 Mule 为 ESB 编写仪表板应用程序。
最近，一位高管要求我们改变对像 Liferay 这样的 Portal/Portlet 容器的方法。
我们团队中的一些人有使用 Liferay 的经验，我们对此有相当负面的感受。处理整页刷新、portlet 生命周期、样式和主题问题以及有限的 DBMS 覆盖等问题是我们抱怨的首要问题。
我们看到我们的执行团队来自哪里。他们已决定要使仪表板可扩展且易于或更易于插入到其他组中。
有没有一种解决方案可以平衡用户对现代 Web 的期望与 IT 专业人员和管理人员的企业需求，他们关心使用 Liferay 构建和可扩展的应用程序？可插拔小部件在这里很重要。
Node 显然是我们的首选，Grails 之类的东西紧随其后。
谢谢，
这个问题可能不太适合 StackOverflow 的格式，但我仍然可以提供一些想法。
如果您想坚持当前的平台，您需要准确地确定您的高管希望从迁移到新平台中获得哪些功能。您可以在当前平台中构建这些功能吗？与重写其他所有内容相比，这需要多少努力？在整个团队中学习一项新技能需要付出多大的努力？我确信您的团队可以有效地学习新技能，但这仍然需要努力，并且随着您的团队学习，会有成长的痛苦。如果您可以向您的主管表明您可以以相似或更少的努力获得相同的功能，并且您仍然可以拥有相似的总拥有成本，那么您可以提出继续使用当前平台的理由。
此外，我认为您低估了 Portlet 容器的功能。我主要使用 WebSphere Portal 工作，所以也许这就是为什么我认为您提到的大多数痛点对我来说并不难管理。仅仅因为您的容器需要特定的 DBMS 来管理自身并不意味着您不能使用单独的 DB 来满足您的自定义数据需求。JSR-286 引入了 serveResource 作为一种使 AJAX 更容易在 portlet 中实现的方法。在 WebSphere Portal（不了解 Liferay）中，在不重新加载页面的情况下更改整个页面内容可能是您列表中最困难的，但我承认。
现代不一定意味着尖端技术。如果您知道如何正确使用大型软件产品，它们仍然可以运行，就像任何其他工具一样。