Ⅰ jsp页面是应该前端程序员写还是java程序员写
我们先来了解JSP页面是什么，JSP（Java Server Page）是Java服务端的页面，所以它是动态的，它是需要经过JDK编译后把内容发给客户端去显示，我们都知道，Java文件编译后会产生一个class文件，最终执行的就是这个class文件，JSP也一样，它也要编译成class文件。JSP不止要编译，它还得要转译，首先把JSP转译成一个Servlet文件，然后在编译成class文件。当用户访问JSP时就执行了class文件。
对于前后端工程师来说,JSP虽然功能很强大，性能也不错，但是会导致前端页面代码过于凌乱。现在，前后端彻底的分离，后端小伙伴只需要提供一系列Restful接口，前端小伙伴只用负责调用这些接口，并实现页面的展示和交互。所以JSP页面前后端开发者都可以编写，但如何选择还是根据个人。
Ⅱ jsp 和 html作为前端页面的区别
jsp 和 html都可以当做页面，但是有如下区别：
html是静态页面，当客户端请求html页面时，容器找到对应页面响应给客户端。
jsp(本质上是一个servlet)是动态页面，当客户端请求jsp页面时，容器找到jsp页面首先将其转译成servlet文件，对其编译执行，最后响应给客户端。
html是由各种标签组成
jsp是由HTML文件(*.htm,*.html)中插入Java程序段(Scriptlet)和JSP标记(tag)，从而形成JSP文件
Ⅲ JSP是由前端还是后端来写代码
在我所学的只是范围内，我对前端后台的理解是：前端是做网页的，后台是拿到这些网页，利用数据库，JSP等对数据进行处理分析，
Ⅳ 前端小白想问，jsp后面是什么意思，怎么用求大神解答
现在前端用Webpack打包JS和其它文件已经是主流了，加上Node的流行，使得前端的工程方式和后端越来越像。所有的东西都模块化，最后统一编译。Webpack因为版本的不断更新以及各种各样纷繁复杂的配置选项，在使用中出现一些迷之错误常常让人无所适从。所以了解一下Webpack究竟是怎么组织编译模块的，生成的代码到底是怎么执行的，还是很有好处的，否则它就永远是个黑箱。当然了我是前端小白，最近也是刚开始研究Webpack的原理，在这里做一点记录。
编译模块
编译两个字听起来就很黑科技，加上生成的代码往往是一大坨不知所云的东西，所以常常会让人却步，但其实里面的核心原理并没有什么难。所谓的Webpack的编译，其实只是Webpack在分析了你的源代码后，对其作出一定的修改，然后把所有源代码统一组织在一个文件里而已。最后生成一个大的bundle JS文件，被浏览器或者其它Javascript引擎执行并返回结果。
在这里用一个简单的案例来说明Webpack打包模块的原理。例如我们有一个模块mA.js
var aa = 1; function getDate() { return new Date(); } mole.exports = { aa: aa, getDate: getDate }
我随便定义了一个变量aa和一个函数getDate，然后export出来，这里是用CommonJS的写法。
然后再定义一个app.js，作为main文件，仍然是CommonJS风格：
var mA = require('./mA.js'); console.log('mA.aa =' + mA.aa); mA.getDate();
现在我们有了两个模块，使用Webpack来打包，入口文件是app.js，依赖于模块mA.js，Webpack要做几件事情：
从入口模块app.js开始，分析所有模块的依赖关系，把所有用到的模块都读取进来。 每一个模块的源代码都会被组织在一个立即执行的函数里。 改写模块代码中和require和export相关的语法，以及它们对应的引用变量。 在最后生成的bundle文件里建立一套模块管理系统，能够在runtime动态加载用到的模块。
我们可以看一下上面这个例子，Webpack打包出来的结果。最后的bundle文件总的来说是一个大的立即执行的函数，组织层次比较复杂，大量的命名也比较晦涩，所以我在这里做了一定改写和修饰，把它整理得尽量简单易懂。
首先是把所有用到的模块都罗列出来，以它们的文件名（一般是完整路径）为ID，建立一张表：
var moles = { './mA.js': generated_mA, './app.js': generated_app }
关键是上面的generated_xxx是什么？它是一个函数，它把每个模块的源代码包裹在里面，使之成为一个局部的作用域，从而不会暴露内部的变量，实际上就把每个模块都变成一个执行函数。它的定义一般是这样：
function generated_mole(mole, exports, webpack_require) { // 模块的具体代码。 // ... }
在这里模块的具体代码是指生成代码，Webpack称之为generated code。例如mA，经过改写得到这样的结果：
function generated_mA(mole, exports, webpack_require) { var aa = 1; function getDate() { return new Date(); } mole.exports = { aa: aa, getDate: getDate } }
乍一看似乎和源代码一模一样。的确，mA没有require或者import其它模块，export用的也是传统的CommonJS风格，所以生成代码没有任何改动。不过值得注意的是最后的mole.exports = ...，这里的mole就是外面传进来的参数mole，这实际上是在告诉我们，运行这个函数，模块mA的源代码就会被执行，并且最后需要export的内容就会被保存到外部，到这里就标志着mA加载完成，而那个外部的东西实际上就后面要说的模块管理系统。
接下来看app.js的生成代码：
function generated_app(mole, exports, webpack_require) { var mA_imported_mole = webpack_require('./mA.js'); console.log('mA.aa =' + mA_imported_mole['aa']); mA_imported_mole['getDate'](); }
可以看到，app.js的源代码中关于引入的模块mA的部分做了修改，因为无论是require/exports，或是ES6风格的import/export，都无法被JavaScript解释器直接执行，它需要依赖模块管理系统，把这些抽象的关键词具体化。也就是说，webpack_require就是require的具体实现，它能够动态地载入模块mA，并且将结果返回给app。
到这里你脑海里可能已经初步逐渐构建出了一个模块管理系统的想法，我们来看一下webpack_require的实现：
// 加载完毕的所有模块。 var installedMoles = {}; function webpack_require(moleId) { // 如果模块已经加载过了，直接从Cache中读取。 if (installedMoles[moleId]) { return installedMoles[moleId].exports; } // 创建新模块并添加到installedMoles。 var mole = installedMoles[moleId] = { id: moleId, exports: {} }; // 加载模块，即运行模块的生成代码， moles[moleId].call( mole.exports, mole, mole.exports, webpack_require); return mole.exports; }
注意倒数第二句里的moles就是我们之前定义过的所有模块的generated code：
var moles = { './mA.js': generated_mA, './app.js': generated_app }
webpack_require的逻辑写得很清楚，首先检查模块是否已经加载，如果是则直接从Cache中返回模块的exports结果。如果是全新的模块，那么就建立相应的数据结构mole，并且运行这个模块的generated code，这个函数传入的正是我们建立的mole对象，以及它的exports域，这实际上就是CommonJS里exports和mole的由来。当运行完这个函数，模块就被加载完成了，需要export的结果保存到了mole对象中。
所以我们看到所谓的模块管理系统，原理其实非常简单，只要耐心将它们抽丝剥茧理清楚了，根本没有什么深奥的东西，就是由这三个部分组成：
// 所有模块的生成代码 var moles； // 所有已经加载的模块，作为缓存表 var installedMoles； // 加载模块的函数 function webpack_require(moleId);
当然以上一切代码，在整个编译后的bundle文件中，都被包在一个大的立即执行的匿名函数中，最后返回的就是这么一句话：
return webpack_require(‘./app.js');
即加载入口模块app.js，后面所有的依赖都会动态地、递归地在runtime加载。当然Webpack真正生成的代码略有不同，它在结构上大致是这样：
(function(moles) { var installedMoles = {}; function webpack_require(moleId) { // ... } return webpack_require('./app.js'); }) ({ './mA.js': generated_mA, './app.js': generated_app });
可以看到它是直接把moles作为立即执行函数的参数传进去的而不是另外定义的，当然这和上面的写法没什么本质不同，我做这样的改写是为了解释起来更清楚。
ES6的import和export
以上的例子里都是用传统的CommonJS的写法，现在更通用的ES6风格是用import和export关键词，在使用上也略有一些不同。不过对于Webpack或者其它模块管理系统而言，这些新特性应该只被视为语法糖，它们本质上还是和require/exports一样的，例如export：
export aa // 等价于: mole.exports['aa'] = aa export default bb // 等价于: mole.exports['default'] = bb
而对于import：
import {aa} from './mA.js' // 等价于 var aa = require('./mA.js')['aa']
比较特殊的是这样的：
import m from './m.js'
情况会稍微复杂一点，它需要载入模块m的default export，而模块m可能并非是由ES6的export来写的，也可能根本没有export default，所以Webpack在为模块生成generated code的时候，会判断它是不是ES6风格的export，例如我们定义模块mB.js:
let x = 3; let printX = () => { console.log('x = ' + x); } export {printX} export default x
它使用了ES6的export，那么Webpack在mB的generated code就会加上一句话：
function generated_mB(mole, exports, webpack_require) { Object.defineProperty(mole.exports, '__esMole', {value: true}); // mB的具体代码 // .... }
也就是说，它给mB的export标注了一个__esMole，说明它是ES6风格的export。这样在其它模块中，当一个依赖模块以类似import m from './m.js'这样的方式加载时，会首先判断得到的是不是一个ES6 export出来的模块。如果是，则返回它的default，如果不是，则返回整个export对象。例如上面的mA是传统CommonJS的，mB是ES6风格的：
// mA is CommonJS mole import mA from './mA.js' console.log(mA); // mB is ES6 mole import mB from './mB.js' console.log(mB);
我们定义get_export_default函数：
function get_export_default(mole) { return mole && mole.__esMole? mole['default'] : mole; }
这样generated code运行后在mA和mB上会得到不同的结果：
var mA_imported_mole = webpack_require('./mA.js'); // 打印完整的 mA_imported_mole console.log(get_export_default(mA_imported_mole)); var mB_imported_mole = webpack_require('./mB.js'); // 打印 mB_imported_mole['default'] console.log(get_export_default(mB_imported_mole));
这就是在ES6的import上，Webpack需要做一些特殊处理的地方。不过总体而言，ES6的import/export在本质上和CommonJS没有区别，而且Webpack最后生成的generated code也还是基于CommonJS的mole/exports这一套机制来实现模块的加载的。
模块管理系统
以上就是Webpack如何打包组织模块，实现runtime模块加载的解读，其实它的原理并不难，核心的思想就是建立模块的管理系统，而这样的做法也是具有普遍性的，如果你读过Node.js的Mole部分的源代码，就会发现其实用的是类似的方法。这里有一篇文章可以参考。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。
您可能感兴趣的文章:探索webpack模块及webpack3新特性关于webpack2和模块打包的新手指南（小结）详解react-webpack2-热模块替换[HMR]webpack配置sass模块的加载的方法详解用webpack把我们的业务模块分开打包的方法Webpack常见静态资源处理-模块加载器（Loaders）+ExtractTextPlugin插件详解webpack异步加载业务模块jQuery 移动端拖拽（模块化开发，触摸事件，webpack）
Ⅳ JSP是前端还是后端
jsp的实质是servlet，而servlet是服务器端小程序，所以jsp应该属于后端。
因为MVC分层中，jsp属于View层，现在jsp更多的作用变为了数据的展示和页面的显示，渐渐不用于逻辑的处理，所以综合起来虽然是后端的技术，但是应用上更贴近前端。
Ⅵ 一个项目的web前端使用的是html还是jsp
html啊，java有时会写成jsp，但是编译后也是html，前端写页面的话直接写html就好了
Ⅶ web前端需要学习jsp吗
jsp可以说跟前端几乎毛关系都没有，搞前端，js肯定要学，CSS也得学。jsp是服务器端执行的代码，前端主要是搞浏览器渲染的那部分。结构化稍微好一点点的网站程序前后端都是通过模板机制等方式分离的。前端专心搞界面即可。
WEB前端开发主要的职业技能，是DIV+CSS，Javascript。 前端开发的主要工作是，把美工设置的图，还原为静态HTML文件，以及在前端交互的实现。 我不是高手，根据我目前了解的。从基本到提高，由以下几个阶段构成。 1、DIV+CSS阶段，需要了解样式在页面中产生的作用和效果。并对跨浏览器兼容有充分的认识。 在这一阶段，主要工作基本就是切图。。。如果你一点基础都没有，你可能要从HTML开始学起，知道标签的语义，然后试着看看样式表的选择器，找一本书看一看，然后就是多练习，做的多了，自然遇到问题更多，经验就会增加。 2、JS表现阶段。 需要了解Javascript脚本，了解事件模型等等。。 这一步，需要第一阶段作为基础。 在这一阶段，主要工作除了切图之外，你也可以用JS写一些效果了，比如标签的切换，菜单的显示隐藏。 3、JS进阶阶段。在这个时候，你应该会遇到前后台交互的问题。那么，你会使用ajax来解决问题。由于有第二阶段的基础，通过操作DOM,把后台数据通过不刷新网页的方式呈现到前端网页上。 在这个时候，你已经是一位“前端工程师”了。 4、交互设计，面向对象的JS。 到了这个时候，你已经会很有经验的对交互设计提出你的意见了，在提高用户体验应该有自己的理解。对脚本框架，也应该有所涉猎了。
Ⅷ java开发，使用jsp渲染页面的项目中，jsp是后端程序员负责的，那前端程序员写什么只写html吗
写html和js,对接口就可以了，
Ⅸ 有前端的大神知道这个JSP题目的怎么写吗
既然有两个servlet 而且参数是通过地址带进去的
你在Aservlet里面用
String name = request.getParameter("name");
int age = request.getParameter("age");先拿到值再放入request中
request.setAttribute("name",name);request.setAttribute("age",age);
转发到BServlet：request.getRequestDispatcher("BServlet").forward(request,response);
B中接受在打印出来就行了：
String name = request.getAttribute("name");
int age = request.getAttribute("age");
PrintWriter pw = response.getWriter();
pw.print("name值为："+name+"===age值为："+age);
纯手敲望采纳，不懂可以问我
Ⅹ 前端用jsp还是html
如果只是针对这2个选择，一般是html。还要看公司需求，公司要求你用jsp，那就jsp，除非你能动之以情，晓之以理，说服公司使用html，同时也要解决不用jsp，使用html所带来的其它问题。而且jsp是前后端不分离的开发模式、html一般是前后端分离的开发模式
如果是放大到前端，现在都不是说什么jsp、html的问题，是讲要使用什么技术开发的问题。像我们使用vue来开发前端的话，都是在.vue文件上写前端代码，.html都是编译过来的，基本是都不用管.html里面的东西