Ⅰ 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裡面的東西