[HN Gopher] Vite - Next Generation Front End Tooling
___________________________________________________________________
Vite - Next Generation Front End Tooling
Author : legrande
Score : 366 points
Date : 2022-07-03 13:06 UTC (9 hours ago)
(HTM) web link (main.vitejs.dev)
(TXT) w3m dump (main.vitejs.dev)
| Kyro38 wrote:
| Brandon Roberts created a POC starter for Angular+Vite :
|
| https://twitter.com/brandontroberts/status/15429548608989102...
| moystard wrote:
| This is to generate a vanilla Angular project using vit, not a
| vite powered Angular project.
| canaus wrote:
| So is it safe to say that this tool is mostly trying to solve the
| developer experience side of front-end development, instead of
| trying to create a "new" technology such as SSR?
|
| I've just mostly seen "fast" and "HMR" as the features of Vite,
| but I can't see a team switching over an entire project just to
| solve something that was probably decently "solved" to begin
| with.
| sachinraja wrote:
| I don't think anyone is expecting an existing production
| project to switch over. Vite offers amazing DX for new projects
| though. Just because something is solved doesn't mean it can't
| get better.
| noduerme wrote:
| Am I alone in that I don't webpack or otherwise bundle anything
| until I deploy? If I'm building a large typescript project, I
| just run it directly out of source JS and CSS files on my dev
| server. Only when upgrades are finished and tested do I bundle
| them and put them on the production server.
| fionic wrote:
| No offense man I can't really tell what this is... hmr and dev
| tools cli with a new transpiler?... it's not next generation it's
| a patch/minor upgrade to current generation tooling and it comes
| with a [extremely] major upgrade to swap it with whatever is
| currently used.
| tzm wrote:
| Last I tested Vite (6 mo ago) it didn't support web3 lib and a
| few others. Has anyone tested recently?
| fasteo wrote:
| Old backend coder here. All I see here is
|
| >>> it's fast
|
| That's the same thought I 30 years ago when going from compiling
| a Fortran program (minutes) to compiling programs with Turbo
| Pascal 3.0 (instant)
|
| History repeats itself I guess.
| supz_k wrote:
| I yesterday migrated our Laravel project from Laravel Mix (which
| uses webpack) to Vite (https://laravel.com/docs/9.x/vite), and
| couldn't be more happier.
|
| Earlier, webpack took 3-4 seconds to re-bundle on file changes
| when running npm run watch (It is a quite large typescript +
| react project). In Vite, it is less than 300ms. And, React Hot-
| Reloading is awesome.
| GiorgioG wrote:
| Vite is excellent and https://swc.rs is another one to keep an
| eye on.
| sachinraja wrote:
| Vite could use swc for compiling in the future.
| NaN1352 wrote:
| I like that you can use --watch if you don't want or can't use
| HMR for whatever reason (eg. testing with other legacy code).
|
| Also it outputs a "dependency" file during build which you can
| use to infer the correct js/css includes - and this lets you add
| Webpack like modern js and all plugins like markdown and icons,
| to a LEGACY app in php. I did it with a Symfony 1.4 app it's
| awesome.
| albertTJames wrote:
| There is no way I'm leaving webpack after those 100 years of
| frustration and pain. Now that I have reached an almost mediocre
| level of understanding of it, I am never letting it go.
| simlevesque wrote:
| Leaving Webpack was one of the most liberating technology
| choice I ever did. Top 10 easily.
| matchbok wrote:
| The constant iteration and revolution of basic front-end web dev
| makes me happy to be a mobile dev.
| DrewADesign wrote:
| I get your frustration: only being partially invested in front-
| end web dev, the constant churn of what people consider viable
| stacks, techniques and architectures can be maddening. It can
| all seem like a race to implement the hottest javascript du
| jour in some finicky framework or library while sweeping
| inscrutable, increasingly complex webpack implementation
| details under the rug... until they pop out, or the rug catches
| on fire, or the floor gives out, or any other inevitable thing
| happens that precludes ignoring them.
|
| Maybe plastering a power strip into a wall rather than doing
| proper electrical work is a better metaphor. Everybody knows
| it's a bad idea, but someone made a thing that automatically
| provisions and deploys new strips, and someone made a thing
| that plugs stuff in, and someone made a thing that mixes and
| applies plaster which was replaced by a drywall thing but we
| still call it plaster, and someone else made a thing that does
| it in 10 rooms at once...
|
| That said, this seems like a bigger step towards simplifying
| both the development process AND the toolchain. It only works
| in newer browsers so it doesn't immediately work for all use
| cases, but it's good enough for some. We're quickly approaching
| the point where browser-native implementations of more recent,
| better designed scripting features are widespread enough to
| rely on. That _should_ both simplify and stabilize front-end
| web development for quite some time.
| xisukar wrote:
| You're being downvoted but it's wild how frontend frameworks
| pop up, take hold, and then quietly disappear with the next
| iteration of the same thing with different syntactic sugar.
| Waterluvian wrote:
| In an environment where you have choice, it takes developer
| maturity not to just leap on every new tool like this.
|
| But it's wonderfully healthy for an environment to be so
| alive and full of innovation.
|
| Bazaar vs. Cathedral and whatnot. It's easier for some to
| just be prescribed a specific SDK.
| JohnBooty wrote:
| re: Bazaar vs. Cathedral
|
| I think it's an obvious truth that too little
| innovation/choice is bad. I don't think you'll find any
| arguments there!
|
| Is there a point where too _much_ of it becomes harmful?
| For close to ten years now, I feel that experienced and
| inexperienced devs alike have been confused and repulsed by
| the utter state of constant wheel-reinvention in the
| frontend space.
|
| (Perhaps to my own detriment, I've focused on backend work
| because I'm waiting for the front-end situation to
| stabilize. Which of course may never happen. Maybe "full-
| stack dev" is something that will wind up in the history
| bin next to "webmaster") It's easier for
| some to just be prescribed a specific SDK.
|
| This is a little bit insulting. Nobody wants to "be
| prescribed a specific SDK" - there's a large middle ground
| between that, and the current situation which has been
| chaotic for nearly a whole generation.
|
| I think the situation with backend frameworks is sort of
| what many would like to see. Django, Rails, Express, etc.
| No shortage of choice and there is innovation. Yet I don't
| think anybody would call it chaotic. For me that is a happy
| middle ground.
| JohnBooty wrote:
| Yeah it's just wild. I don't ever remember seeing this level
| of.... sideways.... churn before. Feels like it's been
| absolute mayhem for close to ten years now.
|
| I thought that for sure, by 2017 or so, we'd have seen a
| relatively long lived consensus winner like we saw during
| jQuery's reign.
|
| Instead, it's just been constant roiling.
|
| The roiling is hard to understand because it's not like the
| other parts of the stack are really mutating that quickly.
| Backend dev practices/technologies and browser capabilities
| are not evolving or roiling at anywhere close to this rate.
| This sort of churn would have made sense during say 1997-2002
| when the entire stack was being invented and reinvented and
| the basic idea of browsers themselves were changing rapidly.
| steve_taylor wrote:
| Yeah, it's not like a single web framework has been the most
| widely used for seven years running. Oh, wait...
| mtlynch wrote:
| Which web framework has been the frontrunner for 7 years?
| jQuery?
|
| According to the latest Stack Overflow survey[0], the most
| popular is React, which hasn't been the top for the last 7
| years. And I wouldn't call jQuery the obvious choice before
| that, as it's been consistently fading in popularity.
|
| https://insights.stackoverflow.com/survey/2021#most-
| popular-...
| steve_taylor wrote:
| NPM download stats paint a more accurate picture. I
| didn't include jQuery because it's not a framework.
| (React calls itself a view library, but it's definitely a
| framework.)
| mkoryak wrote:
| I wouldn't call jQuery a framework. It's an API wrapper
| (warper). Your link also lists html/css as a programming
| language
| root_axis wrote:
| I downvoted it. I did so because, IMO, the comment is
| superfluous noise seen on every js thread. A tool exists to
| solve a problem, if you don't understand why it was built or
| don't like it, that's ok, but the hackneyed complaining about
| open source software merely existing deserves to be at the
| bottom of the thread.
| tonetheman wrote:
| It is not superfluous noise. It is js sadly.
|
| Js is an ever changing mass of stuff. I feel bad for
| frontend guys for this reason. Always writing for a
| language that does not even exist... always changing how
| you shove it all together.
|
| Even worse as soon as you put a foot down and pick
| something you are behind.
|
| It is exhausting even to watch much less to be in it.
| SOLAR_FIELDS wrote:
| I'm not the grandparent poster but I'll ask the question in
| a non-superflous way:
|
| Is this actually better than Webpack and
| esbuild/Parcel/Rollup/whatever that came before it? Or is
| it just another opinionated way of packaging stuff up
| that's faster because it doesn't support 10% of the feature
| set the other tools do yet?
|
| Looking at the "Why Vite" page, most of the blurbs are
| basically saying "Existing tools are slow". Well, I bet
| those existing tools are probably capable of doing 10x of
| what Vite can do currently. And how much faster IS Vite
| when bundling a large project? Nothing on that, only some
| charts with lines saying that they do it differently. They
| say 10-100x speedup on "prebundling", but if that part of
| the build is only a small portion of the overall build it
| might be negligible. Also, they say it's faster because Go.
| Well I kind of like the dogfooding of all the build tools
| for JS being written in JS - why introduce a whole new
| ecosystem here?
|
| Not trying to be a naysayer here, I'm just asking why
| mindshare should be devoted to yet another project that
| looks like reinvention of the wheel and starting the cycle
| anew again when we could instead contribute mindshare to
| existing mature projects - the reasoning given on the site
| doesn't seem to be very compelling.
| cercatrova wrote:
| > _Well I kind of like the dogfooding of all the build
| tools for JS being written in JS - why introduce a whole
| new ecosystem here?_
|
| You might find this answer helpful, about Rome which is
| like Vite but in Rust rather than Go [0], crucially:
|
| > _This justification -- Rome should be written in JS
| otherwise Rome users are less likely to contribute --
| irresponsibly focuses on a secondary goal of the project,
| at the cost of the primary goal, which is to be a end-to-
| end toolchain for one of the most popular languages in
| the world._
|
| Speed matters. It is not a sideline consideration, it
| should be one of the main considerations, over and above
| a tool being in the same language. In fact, many say that
| rewriting JS tools in non-JS faster languages will be the
| future [1].
|
| [0] https://news.ycombinator.com/item?id=28609474
|
| [1] https://leerob.io/blog/rust#the-future-of-javascript-
| tooling (https://news.ycombinator.com/item?id=29192088)
| doomroot wrote:
| The reason frontend dev moves "So quickly" is because of
| new browser developments & capabilities. Esbuild & vite
| are currently popular because they are one of the first
| build tools to fully utilize browser ES Modules. This is
| fundamentally different than what webpack does. Webpack
| was solving a Pre-ESM problem, "how do we modularize
| frontend code?" and as such as taken on a lot of bloat to
| solve this problem which has largely been solved by
| browser ESM.
| EarthLaunch wrote:
| It is better. Why are so many people determined to
| dismiss it on the basis that "things are so bad that we
| shouldn't try anything new"? That's totally backwards. In
| a situation of many bad alternatives, searching for new
| alternatives is the solution, not the problem.
|
| Complaining about bad frontend tooling would be more
| appropriate to do in a thread that's not about _a tool
| that practically solves it_.
|
| Instead of complaining about _other_ tools, these people
| who don 't know what Vite is should be curious and asking
| what it is, or what it has that's new. That is easy to
| find out.
|
| > Well, I bet those existing tools are probably capable
| of doing 10x of what Vite can do currently.
|
| Good luck with your bet.
| [deleted]
| mmargerum wrote:
| Javascript UI frameworks last longer the Microsoft UI
| frameworks. It's not like a newer framework is just replacing
| an old one because of hype. React/Vue are massive
| improvements over Angular 1.
| sascha_sl wrote:
| To be completely fair, changes occur way too often even
| when the name doesn't change. I tried to find a nice
| component library for starting out with Vue after not doing
| any frontend or JavaScript in years (I kind of quit when
| JSPM, the package manager, was hot).
|
| It took me about an hour to figure out nothing I tried to
| set up worked because I had installed Vue 3 and mostly
| everything else was still on Vue 2.
|
| Reminds me of Angular 2 rewriting their router every 6
| weeks - to the point that they just moved on to calling it
| Angular 3 at release to rid themselves of the information
| on StackOverflow that was in a constant state of
| deprecation.
| fomine3 wrote:
| React era is long.
| ntoskrnl wrote:
| Are you sticking with the tired old 2019 tech, or have you
| rewritten everything with Kotlin, Compose, Swift, and SwiftUI?
| aaaaaaaaaaab wrote:
| We're still writing iOS apps in Objective-C(++).
| lordofgibbons wrote:
| No, those are old news. We've moved on to Flutter
| mattlondon wrote:
| Sorry but if it requires NPM then I am not interested. I have
| been burnt too many times to want to use anything related to NPM.
|
| I would hope that a next generation framework would not have hard
| dependencies on the cess pit that is NPM :(. Please give us
| something fresh and interesting.
|
| This is why I am so excited by deno on the backend - finally no
| more NPM!
| oblak wrote:
| Speed gains aside, it's pretty great, though I did have to
| provide a manual path to node_modules/some_package_here because
| it wouldn't serve those files in dev mode. On my computer alone.
| No one else. Guess I had a weird setup.
|
| It has many years until it turns into yet another bloated
| "builder" if you could call it that
|
| Overall, I continue to be impressed by whatever these guys (it's
| not just Ewan) do even it's getting hard to keep up at my age.
| ggregoire wrote:
| I find it funny that, as usual, half the comments are complaints
| about "why are frontend developers always reinventing the
| wheel"... Meanwhile the 1st post on the front page [1] is about a
| new "modern" scheduling package for Python. What's wrong with
| just using Celery, APScheduler, Huey or even cron? Why do we need
| a new scheduling library? Yet I don't see any "reinventing the
| wheel" critic in the comments. Double standard I guess.
|
| [1] https://news.ycombinator.com/item?id=31969345
| j-krieger wrote:
| Correct. People are arguing as if there wasn't a new Container
| Library being released every month for C++
| ramesh31 wrote:
| "It's fast" is not going to sell me on a build tool. Make files
| are fast too. What we learned with the evolution from Gulp/Grunt
| etc. to Webpack is that you need to find a sweet spot between
| zero config and full config. The "batteries included" approach
| works until it doesn't, and for small projects I'm sure it's
| fine. But every large project inevitably ends up with all kinds
| of snowflake config that Webpack handles really well, while also
| having a robust plugin ecosystem with standard defaults.
| simlevesque wrote:
| It's one of the software that is the easiest to move to. For
| the vast majority of people, you go from a 150 lines Webpack
| config to a 15 lines Vite config, possibly the default values.
|
| It is kind of incredible. They've found "a sweet spot between
| zero config and full config" you are mentionning.
| krick wrote:
| It gave me a pause to think about how it came that I can never
| really tell what am I looking at anymore. Forget the HN title,
| which is stupid -- what does this landing page tell me? Well,
| that it's... next gen, and it apparently can catch up with me,
| which is not much, since I'm not really catching up with what's
| going on anyway. Also, that it's "tooling". Like IDE, or
| framework, or maybe a chainsaw. Can't tell.
|
| "Getting started" page tells me that "Vite" (pronounced as
| "veet") is "quick" in French, then it proceeds with quite wordy
| installation guide. It also _quick_ ly mentions that it's a
| "build tool". Finally. So, like gulp or grunt, I guess? But it
| doesn't even mention those, or any other build tools it
| supposedly replaces. And it seems unlikely, since everybody uses
| some script that comes with angular or vue or any other framework
| of your choice nowadays...
| wslh wrote:
| I remember that Visual Basic (90s) opened with an empty Dialog
| and UI controls like Windows Forms, Delphi and Xcode now. Just
| waiting for a tool as easy to use as Google Slides or
| diagrams.net (draw.io) but produceing the skeleton of an
| web/mobile app.
|
| Does the software industry have a pathology that avoids making
| such tool and makes front-end engineers irrelevant except for
| very complex use cases?
| KronisLV wrote:
| > Does the software industry have a pathology that avoids
| making such tool and makes front-end engineers irrelevant
| except for very complex use cases?
|
| Probably the fact that it's all very opinionated.
|
| Suppose you want to use Vue. Well, do you want Vue 2 or Vue
| 3? JavaScript or TypeScript? Which of the component libraries
| do you want: PrimeVue, Quasar, or another one? State
| management with Pinia or Vuex? What about validations:
| Vuelidate or maybe something like Vue Formulate, which also
| includes functionality for forms. Or would you like Vueform
| instead?
|
| Then again, the same happens if you want to use React or
| Angular, or any other option out there. There's just too many
| separate pieces to pick, though I presume that occasionally
| there are opinionated attempts at giving you a stable base to
| start out with. Honestly, even something like Ruby on Rails
| can be a nice option, though it's also understandable that
| many out there want to create their front ends as separate
| apps.
|
| Yet the majority of front end projects out there end up a bit
| like the Dropwizard framework for Java back end development -
| just stitched together from any number of different pieces,
| which sometimes will work really well together, but other
| times less so: https://www.dropwizard.io/en/latest/
| monkey_monkey wrote:
| "Next gen front end tooling" - for anyone with some vague
| knowledge of front end development would understand that this
| is going to be something like webpack, or mix, or grunt, or
| gulp.
|
| Not every front page has to assume the person going to it knows
| nothing.
| finfinfin wrote:
| Front-end tooling that I have to run on the server? Even
| people familiar with the JS ecosystem might be confused by
| that.
| monkey_monkey wrote:
| You don't have to run this on a server. This would never
| run on a server. This would be used in your local dev
| environment.
| wonnage wrote:
| your local dev environment is running a server
| monkey_monkey wrote:
| Clearly the word server is the same, but that's not
| really what's meant by a server in front end / back end
| developer discussions.
| matt89 wrote:
| I believe you are overexaggerating. It has always been true
| that you needed some kind of local server when doing
| frontend development. There are multiple browser mechanism
| that would not work in any way other than when rendering
| html/css/js that was returned from a server.
|
| Consequently a build tool (or dev-tool) that offers you a
| dev-server is really nothing weird in frontend development
| world. Same as 10-15 years ago when using jQuery and PHP
| and you would use XAMPP or LAMPP.
| finfinfin wrote:
| Just google "front-end tools" and look at the few top
| results. There are many tools for front-end development
| that are not build tools or have to run on the server.
| oxplot wrote:
| > It gave me a pause to think about how it came that I can
| never really tell what am I looking at anymore.
|
| They need to read up on https://posthog.com/blog/hacker-news-
| premortem
| dtagames wrote:
| The page might not be great, but the product is! TL;DR is that
| Vite is a development and build server that requires very
| little setup. It's "quick" to scaffold a site in Lit, Angular,
| or React. And easy to build the static version for hosting.
| That's it!
|
| I wrote a post[0] recently on using Vite with Lit. It shows a
| real use case and setup scenario.
|
| Here's the relevant summary: "Vite (pronounced "veet" and
| French for quick) is a development and build server you can run
| locally. It's perfect for writing and debugging Typescript apps
| because it updates the browser every time you make changes. And
| it's perfect for deploying your finished app because Vite can
| easily build a static copy for publication to an inexpensive
| hosting website. You can keep a local copy at one stage of
| development and the production build at another, which is often
| what you need.
|
| As a bonus, Vite comes with built-scaffolding for Lit apps
| built with Typescript, which is just what we have in mind."
|
| [0] https://medium.com/@mimixco/getting-started-with-web-
| compone...
| BiteCode_dev wrote:
| Terrible landing page for an otherwise excellent tool.
|
| It sets up JS transpiling and bundling for you in an easy way,
| then provide a server with pretty fast hot reload.
|
| This solves 2 problems:
|
| - the complicated js project stack is now simple to setup,
| unlike with webpack
|
| - saving and seeing the result of your coding is now almost
| instant, unlike with CRA
|
| It's a joy to use, given that it's from VueJS author, and I
| highly recommend it to anyone that has a lof of frontend to do.
| superzamp wrote:
| Would this replace parcel or be adjacent to it?
| keb_ wrote:
| Replace it.
| SCLeo wrote:
| I have been using parcel for web development because I
| thought webpack is very difficult to use. However, for my
| latest personal project, I tried webpack. To my surprise, I
| found webpack 5 much simpler to use then I thought it is
| (significantly easier than make or gradle, the complexity is
| not even on the same level). Everything pretty much worked
| out of box now. All I had to do was to copy the starting
| template for typescript from their website (~20 lines, half
| of which are open/closing brackets) and copy the setup for
| dev server. HMR, code splitting via dynamic imports, etc. all
| worked without any setup.
| dmix wrote:
| Webpack is probably fine for new or small projects. It's
| when you've been using it for a while, do anything complex,
| or worst of all your framework libraries update then you
| have to update Webpack which is a nightmare.
|
| Ive had Webpack break more of my deploys than any other
| piece of software in the last 3 years.
|
| Vite was basically a plug and play replacement (almost zero
| config) and I also got to drop Babel, so that meant
| replacing about 12 packages in my package.json and who
| knows how many in Yarn.lock (Mostly babel and webpack
| plugins) with 2 vite packages. It's much faster at builds
| and the chunking of small js files seemed more intelligent
| and better integrated with Vue.
| shepherdjerred wrote:
| Vite is just a few lines, and it's a much better experience
| than webpack
| tpict wrote:
| Last time I checked NPM the weekly downloads were still
| heavily slanted in favour of version 4. I wonder if that
| plays into perception of it.
|
| At work, an engineer in a different team recently
| recommended we switch to Vite because it's "so much
| faster". Warm builds are 700ms with our very uninteresting
| Webpack 5 config. It's hard to imagine that the cost of
| reconfiguring our entire build would be worth it.
| SparkyMcUnicorn wrote:
| Vite is incredibly fast compared to Webpack.
|
| I didn't really know how much time I could have been
| saving, and I never even thought of Webpack as slow.
| unsupp0rted wrote:
| > pretty fast hot reload
|
| An understatement to be sure: you can set VS Code to auto-
| save every 1 second and that way whatever you type instantly
| appears via Vite's Hot Reload in your dev browser. No waiting
| multiple seconds for a recompile.
|
| It's game-changing workflow (for some tasks).
| intrasight wrote:
| Game-changer perhaps in a bad way ;) We're losing the art
| of writing solid code and instead flail with the "hot
| reload" crutch. I miss the days of punching cards and
| submitting a deck to be compiled and run - at least in
| terms of it forcing me to verify my work ahead of time.
|
| And yes - I'm (mostly) kidding. But I did write my first
| programs on punched cards at a university course while I
| was still in grade school. Probably the last generation of
| programmers to experience that discipline.
| nightski wrote:
| We are also writing far more complicated software. Punch
| cards didn't have to support thousands of different
| devices, resolutions, screen densities, input methods,
| etc. It's a totally different world.
| crdrost wrote:
| That's totally fair but the tooling is still not where
| you'd like it.
|
| In theory, there's no reason that you shouldn't be able
| to backtrace from the website to the filesystem. If you
| can do that, then your "it reloads every second" becomes
| even faster, it becomes WYSIWYG, you are writing in the
| live constantly-refreshing UI. Well, almost: your text
| editor has Undo and Git and your web browser doesn't. But
| we could build those into the browser. Heck, Redux is
| basically Git except without any standardized verbs, just
| give Redux some standardized verbs for tracking revisions
| in a living app and you've got everything you need.
|
| If you follow _that_ trend to its logical conclusion (
| "OK I want a special way to ctrl-click or right-click or
| something to edit the HTML of a component I see") you
| eventually get Smalltalk, and we're finally back as
| productive as we could be in the 70s :)
| jjeaff wrote:
| I think it does this by not even recompiling. It just links
| all the uncompiled, uncompressed files and dependencies
| using a few functions to make them work in the browser.
| boredtofears wrote:
| I dunno if it's just me, but I've always found live reload
| to be an overstated benefit. I usually have a mental model
| of what I'm trying to code that I don't want to check until
| it's at a specific state - the seconds it takes to press
| reload doesn't really add up to that much.
|
| I'd say it's more beneficial for CSS styling but I usually
| mock up my changes in the dev inspector and then copy it
| over anyways.
| aidos wrote:
| Exactly that though. For a SPA you're going to have a
| bunch of state loaded and you don't want to refresh. If
| you're using something like tailwind where you're
| transpiling your css too then it's a major boon to have
| it hot reloaded.
|
| I've found vite to be an awesome dev experience.
| mrwnmonm wrote:
| So, this is not a framework like React, right?
| maigret wrote:
| It's more like Webpack, the software that processes your
| React code into JavaScript bundles that are optimized for
| the browser. ie puts together what belongs together,
| removes the unused code, provides a test server to develop
| and get instant refresh.
| mrwnmonm wrote:
| Got it, thanks
| eproxus wrote:
| How would one use it together with a backend that already
| serves the frontend code? As a compiler only?
| cto_official wrote:
| One question .. Is the main goal to make development process
| easy or does it also have an impact on production performance
| as well ?
| pketh wrote:
| It's mainly for dev rebuild performance. I also use vite
| and it's a pretty nice build tool that's relatively easy to
| configure and quite fast.
|
| It might also affect your production build times, but prod
| builds are far less frequent and performance isn't
| important here
| GiorgioG wrote:
| From https://main.vitejs.dev/guide/
|
| "Vite (French word for "quick", pronounced /vit/, like
| "veet") is a build tool that aims to provide a faster and
| leaner development experience for modern web projects."
|
| Ultimately it makes the dev process more productive because
| builds are generally much faster than most other build
| tools.
|
| https://main.vitejs.dev/guide/why.html might also be worth
| a read
| hackerbrother wrote:
| I can attest that it is a great way to spin up (and compile
| for server-ready HTML/CSS/JS) a React or Vue project.
|
| Just run 'npm init vite@latest' and you get a basic well-
| organized React/Vue project ready for components and other
| dependencies to be dropped in.
|
| Uses esbuild+rollup behind the scenes I believe.
|
| If you have the luxury of picking your tools for a
| completely fresh web project this is a great way to do it.
| bobthepanda wrote:
| Ideally, for production you're not constantly rebuilding a
| JS bundle but instead just building once with all the
| required package versions and then just serving that bundle
| all the time.
|
| The bundle only really needs to change if the underlying
| code does, but in pretty much all cases your
| customers/users are not actually triggering any changes in
| your underlying code, that's a security risk.
| and0 wrote:
| Thanks for the info, will switch from CRA as soon as I can :D
| davidjfelix wrote:
| Ah, the age old HN pass-time of feeling like everything needs
| to fit your niche, leaving a comment about how a website didn't
| fill in your blind spot for you rather than googling what
| something is with the time.
| InCityDreams wrote:
| And that's a pastime i welcome, as it saved me many clicks.
| And, it also confirms what i have been seeing across several
| websites of late: difficult to penetrate, even in areas i
| would consider myself well-versed in.
| kodah wrote:
| I don't think that's what OP is saying. To me, it reads like,
| "I'd love to know what this is, but based on the linked
| document and others within near proximity - I can't" which
| means the link requires that OP has knowledge of the frontend
| build world - which _I_ will tell you is niche and disparate
| or that there is a big unsaid problem in this space that is
| non-obvious to anyone outside of it.
|
| Curiously, both are true. Give OP some slack.
| sachinraja wrote:
| If they don't have knowledge of the frontend build world,
| then maybe they'll have to do a bit more reading. Who
| should Vite's landing page target?
| kodah wrote:
| By knowledge, what I really mean is intimate knowledge.
| I'm not a frontend dev, but I do hack away on hobby
| projects which eventually caused me to make changes to
| the default tooling that the project starters pre-
| configure. Given that the landscape so heavily relies on
| preconfiguration and post-customization, who they're
| selling to are people who started with a template and
| know little about what webpack, vite, or next are doing.
| djitz wrote:
| prophesi wrote:
| I find it extra funny that most of the comments recommend
| that they just say it's a webpack replacement. If you don't
| know what webpack is and visit webpack's site, you'll just
| see it's an asset bundler which Vite explicitly is not.
|
| And if you do already know what webpack is, then "frontend
| tooling" and its list of features should make it very obvious
| what Vite is.
| kodah wrote:
| Whether the project is FOSS or not is irrelevant. They're
| seeking distribution and in order to further distribute a
| project needs to be able to cleanly communicate _why_ it
| deserves more distribution. Ironically, based on your
| comment, FOSS products are generally very good at this. What
| OP provided was criticism, and FOSS needs and welcomes
| criticism to stay strong and relevant. If OP was opening a
| GitHub issue and berating the maintainers I would agree with
| you.
|
| tldr: "They don't get paid" is not an escape hatch for
| genuine, level-headed criticism, and criticism is important
| for FOSS to stay strong and relevant.
| djitz wrote:
| The argument presented was neither level-headed nor
| genuine.
| kodah wrote:
| It's a tad emotional but still cogent.
| mrwnmonm wrote:
| Lol, I was about to comment here that I opened the docs, read a
| few pages, and still don't know how this works or how is it
| different from react for example.
| asheeshh wrote:
| brundolf wrote:
| If you're immersed in the front-end world today you would
| probably know that "build tooling" (and could guess that just
| "tooling") typically means a) transpilation, and b) bundling;
| "take my source and turn it into something I can ship and run".
| Usually there are also related features like minification
| and/or a live-reloading dev server.
|
| For a long time Babel and Webpack played these roles,
| respectively, but in the last couple years people have realized
| things can be way faster and simpler if you integrate the two
| steps into a single tool and make it opinionated and write it
| in a native language. As a result we've seen the explosion of
| options like esbuild, SWC, Parcel, etc. I assume Vite is
| somewhere in that space
|
| But I agree it's better to be explicit and not assume the
| reader has all the contextual background
|
| Edit: If you click "Why Vite?" they actually have a wonderful
| explainer that goes into the above and how Vite relates to it
| Myto wrote:
| Funny. The landing page told me immediately what it is. And I'm
| not some expert, I've only done a little bit of hobbyist JS
| development.
| detritus wrote:
| Thank you for saying this, because often when this sort of
| thing pops up on HN I click on the link and stare blankly at
| the page wondering "Just what the hell IS this?!" and I feel
| particularly stupid.
|
| I only keep one foot in the webdev sphere as it's not my
| primary focus any more, but still - I feel that I should be
| able to 'get it'.
|
| - ed : I should've read the comments first. Glad I'm not alone!
|
| My studio is in a building that also does musical events and
| there are always posters up for various gigs and I so often
| have a similar complaint - they're 'designed' (as in, imho,
| poorly) by someone who's had their head buried in the thing
| they're promoting and forget that people slightly outside their
| context need a bit more of a nudge. There's one new one out
| there today that doesn't have any links to help define context,
| and the name of the artist is so generic as to be tricky to
| filter on a web search.
| ianpurton wrote:
| I had exactly the same experience. I gave it maybe 20 seconds
| then I was gone.
| thrdbndndn wrote:
| I'm not a developer and particularly not a front-end one. I
| have this problem all the time.
|
| Even some of the more "obvious" ones, say, nuxtjs, I have a
| hard time to get what exactly it offers and why I should use
| it.
| blowski wrote:
| Devil's Advocate position here.
|
| I don't know much about carpentry, and if I look at a website
| selling saws, I will struggle to understand the difference
| between different models. Dumbing down to an extent that I
| understand (when I probably won't buy the product anyway)
| risks alienating the target market that will.
|
| Due to customer demands, end-user requirements, and device
| fragmentation, front-end development has genuinely become
| _that_ demanding. So as a non-specialist in the field, you
| can't look at relatively specialist tools like Vite and Nuxt
| and expect to understand them straight away.
|
| Sure, many of us long for the halcyon days of "front end"
| meaning at most pulling in jQuery and embedding something in
| the page. But then I sound like my Grandad longing for the
| days when there was no internet at all.
| somenewaccount1 wrote:
| I am a developer and still took a while to realize what it
| does. Also, that snowpack is probably just as sufficient.
|
| It's a shite landing page that communicates little, and as
| a front end framework, well....shouldn't we expect more?
| frankwallis wrote:
| Snowpack is no longer maintained and they recommend
| switching to Vite.
| avgcorrection wrote:
| Nothing like a carpentry analogy to obliterate all nuance.
|
| The OP said:
|
| > Well, that it's... next gen, and it apparently can catch
| up with me, which is not much, since I'm not really
| catching up with what's going on anyway. Also, that it's
| "tooling". Like IDE, or framework, or maybe a chainsaw.
| Can't tell.
|
| We know that it is "tooling". But what is "next gen" and
| "catch up with you"? Are those terms that the appropriate
| audience is just supposed to get?
| sam0x17 wrote:
| Sticking with your analogy, in the early 2000s we built
| cabinents and intricate mantelpieces and things ike that,
| and there were essentially no tools. In the early 2022s we
| still build cabinents and intricate mantelpieces, but there
| are a million tools. Meanwhile browser support has become
| way more consistent across the board and CSS has become
| easier, yet we think we need super complex tools to do the
| same tasks we did back in the day.
| blowski wrote:
| when I started building websites in the late 90s, I
| needed to support Internet Explorer and Netscape running
| 15" CRT monitors. Few cared much about accessibility,
| performance, security, SEO, experimental releases.
| Clients wanted a 3 page website with few design
| requirements. I sliced up some PSDs into HTML pages with
| tables on it, and uploaded it via FTP to a single server.
|
| If I tried to run a web-based business offering that
| today, I'd get very litle business.
| ipaddr wrote:
| It feels like this big struggle and effort to end up with
| another jquery in a few years because in the end that's
| what works and feels right
| LtWorf wrote:
| Developer here. I think I can speak for everyone when I say
| that even when we work with the thing, we can't understand
| the homepage of the thing.
|
| For example at my $DAYJOB I know what we do but if I didn't
| the website wouldn't help me to understand.
| gmassman wrote:
| I'm also a developer and this is a terrible
| overstatement. My company sells a product that isn't
| particularly hard to understand, and our www site makes
| it pretty clear what we're selling.
| cercatrova wrote:
| You might work at a sales-oriented company then, rather
| than a consumer or prosumer (self-service) oriented
| company. Sales-oriented company websites are purposefully
| opaque so as to not make a potential customer be able to
| easily compare and contrast tools without going through
| an in-depth demo for each one, led by salespeople and
| perhaps engineers.
| azemetre wrote:
| This is a good point if we were selling physical goods and
| limited by the amount of information we can convey on a
| screen but we aren't.
|
| I'd honestly include things like the what and why as
| critical to documentation. Most libraries, tools, and tech
| in general are bad at documentation. It's an active choice
| to omit discussing these things when they should obviously
| be included but writing good copy is hard.
|
| IDK seems like a good thing to invest in especially if you
| want your tool to become a dominate player instead of an
| encroaching tangent.
|
| While there are separate pages for the why and comparisons
| for vite (but it's only comparing itself to other bleeding
| edge tools rather than popular ones like webpack,
| browserify, gulp, grunt) they should be snippets of these
| sections on the front page. Right now there are 6 title
| cards of with wasted space with very little information.
| Compare this with playwright's home page you and
| immediately know why you want to use the tool:
|
| https://playwright.dev/
|
| For a personal taste thing, I'm not really a fan of these
| open source tools creating homepages similar to as you
| would see for various startups/products. My mind
| immediately goes "oh paid tool, oh well." They do say it's
| free in a lovely medium size text that doesn't standout
| much and is beyond the fold.
| blowski wrote:
| Different way of thinking about this - maybe the devs
| aren't even the target user of the homepage. If the first
| time a front end dev hears of Vite is via the homepage,
| their marketing has a problem. (I first heard of Vite
| maybe 18 months ago in a discussion on the upcoming Nuxt
| v3.)
|
| Instead, this homepage is trying to convince some CxO
| this is a serious tool worth adopting.
|
| Either way, I'd assume there's a good reason you find the
| homepages of so many popular projects homepages rather
| vacuous. I doubt it's incompetence.
| mrwnmonm wrote:
| But he is a developer.
| blowski wrote:
| They are not a specialist front-end dev.
|
| To use an analogy closer to home, if the average front-
| end dev were to look at a page talking about some new C++
| compiler, they'd say "wat?".
| KronisLV wrote:
| > Due to customer demands, end-user requirements, and
| device fragmentation, front-end development has genuinely
| become _that_ demanding. So as a non-specialist in the
| field, you can't look at relatively specialist tools like
| Vite and Nuxt and expect to understand them straight away.
|
| Vite is a set of front end tooling - it provides a local
| dev server, allows you to work with JSX, CSS and
| TypeScript, as well as lets you build your app, amongst
| other things. It handles most things that go between
| editing your source files and having distribution bundles.
|
| Nuxt is a framework for Vue, that attempts to provide a lot
| of defaults for your Vue apps and also supports server side
| rendering or static site generation. It has functionality
| for handling views, routing, state, configuration, as well
| as middleware, fetching data and validations.
|
| You can probably describe anything in a way that people
| would get the gist of it straight away. It doesn't have to
| be all encompassing, it doesn't even have to be 100%
| correct, just easy to understand, maybe even with a
| comparison in there (e.g. npm + webpack). Many such
| descriptions might just fit into a single paragraph of
| text, or even a tooltip.
| metadat wrote:
| You aren't alone.
|
| The frontend tooling and framework market is so flooded and
| noisy, with extremely high churn. At this point it's so hard
| to keep up with and build things with the latest thing, it's
| become a hilariously bad joke.
|
| What other language ecosystem is this insane?
| agumonkey wrote:
| It seems dev has become a subculture forest. Everything is
| simple if you're in that group and follow the problems and
| ideas around.
| konfusinomicon wrote:
| at this point I've come to realize that all you need to know
| about front end frameworks anymore is that they are not
| jquery
| smt88 wrote:
| You are utterly wrong. There's a huge difference between
| even Next.js and create-react-app, even though they're both
| based on React.
|
| The JS framework space is huge, messy, complex, and
| endlessly frustrating, but you can't wave that all away
| just because _you_ can 't keep up with it.
|
| I can't keep up either, but I do employ people who do, and
| they recently moved all our build tooling to Vite, which
| dramatically improved our DX.
| konfusinomicon wrote:
| I agree! my comment was in jest and was just poking fun
| at the madness that is the JS ecosystem and it's often
| overly complex, and ever growing list of solutions to
| problems that could be probably be solved with a few
| lines of jQuery.
|
| in the words of Jack Borrough, Senior JS Developer,
| "JQuery, what are you, five? We use JJQuery."
| https://jjquery.io/
| sireat wrote:
| The hilarious thing is that this is the first time I am
| seeing DX in this context.
|
| Is DX meant to be Developer Experience or something
| different?
| teaearlgraycold wrote:
| The feature list on the home page indicate it's a dev server.
| keithnz wrote:
| click "Why Vite?". I think it has a pretty good explanation
| about what it is doing and the tools that are similar to it and
| the problem it is trying to solve.
| lucideer wrote:
| > _it apparently can catch up with me, which is not much, since
| I 'm not really catching up with what's going on anyway_
|
| This entirely depends on your situation but for a tool like
| this (the selling point being that it _does it all for you_ ) I
| think this is less about catching up with _you_ and more about
| providing you with the tooling that catches up to the myriad of
| things in JS that you may feel the need to catch up with.
|
| In this case it's most likely referring to the decision to use
| native es modules to serve non-dependency code. This means and
| code you write can use native browser cutting edge without you
| needing to worry about "what build tooling supports the latest
| documented standard native browser features" - one of the pains
| of building is using X standard native tech documented clearly
| on MDN and finding out it doesn't work cleanly with a specific
| combination of webpack/rollup plugins I'm leveraging right now.
| This just lets you use what's standard.
| Rapzid wrote:
| I feel the title is accurate but I'm familiar with Vite so
| recognize it's perhaps not adequate..
|
| Anyway, it's a replacement for Webpack based toolchains focused
| on fast startup and HMR.
|
| Why Vite goes into details: https://vitejs.dev/guide/why.html
| [deleted]
| jimmygrapes wrote:
| At least it includes the "why?" button (link? why does it
| look like a button to me?) unlike so many other projects that
| only have "get started" (I don't want to start something I
| have no clue about).
| gexla wrote:
| Personally, I feel like it's rare that I stumble on a tool and
| need to read its landing page. If I know of it, it's probably
| because someone told me about it or it's already part of
| something I inherited. And that's probably the only way I would
| consider it anyway. I don't care what their pitch is if I don't
| know anyone using it. Much more common is stumbling across a
| repo with tooling I'm specifically looking for (because I don't
| know anyone doing that specific thing and I'm not looking for
| an alternative to something I'm already using) and the repo
| docs are even worse.
| cercatrova wrote:
| Looks like you're looking for the Why Vite page [0].
|
| """
|
| # The Problems
|
| Before ES modules were available in browsers, developers had no
| native mechanism for authoring JavaScript in a modularized
| fashion. This is why we are all familiar with the concept of
| "bundling": using tools that crawl, process and concatenate our
| source modules into files that can run in the browser.
|
| Over time we have seen tools like webpack, Rollup and Parcel,
| which greatly improved the development experience for frontend
| developers.
|
| However, as we start to build more and more ambitious
| applications, the amount of JavaScript we are dealing with also
| increased exponentially. It is not uncommon for large scale
| projects to contain thousands of modules. We are starting to
| hit a performance bottleneck for JavaScript based tooling: it
| can often take an unreasonably long wait (sometimes up to
| minutes!) to spin up a dev server, and even with HMR, file
| edits can take a couple seconds to be reflected in the browser.
| The slow feedback loop can greatly affect developers'
| productivity and happiness.
|
| Vite aims to address these issues by leveraging new
| advancements in the ecosystem: the availability of native ES
| modules in the browser, and the rise of JavaScript tools
| written in compile-to-native languages.
|
| """
|
| [0] https://main.vitejs.dev/guide/why.html
| nullwarp wrote:
| Recently started a new frontend project with Vite, Typescript and
| MithrilJS and it's been a real pleasure to work with.
|
| Contrast that to my usual dealings with Webpack I couldn't be
| happier.
| candiddevmike wrote:
| Happy to see other folks still using Mithril. I've looked at
| other frameworks (svelte recently) and keep coming back to
| Mithril. It's so simple and easy to understand, it'll take
| something special to have me consider something else.
| nullwarp wrote:
| Mithril is criminally underrated. Yeah it won't have the same
| level of community support that things like React and Vue
| have but it's extremely simple and concise to work with and
| nothing about it feels "heavy" like the former two.
|
| By far it's my favorite tool to reach for when I need more
| than just plain vanilla JS.
| littlecranky67 wrote:
| I'm a sceptic to the claims; most build speedups I've seen come
| from the bypass of Typescript type checking/compiler errors.
| Since there is no other competetive compiler to Typescript than
| the official (and slow) tsc, I think vite works this way too?
| Getting hot reload and fast page refreshes is nice, but the idea
| is that if I get a compiler error, I ought to fix it first before
| I move to the browser to test my code.
| [deleted]
| emptysea wrote:
| Curious how Parcel stacks up to Vite.
|
| Vite seems to have the Vue community behind it which is pretty
| larger.
|
| Both have much better performance than webpack, so between the
| two probably doesn't matter too much.
| rk06 wrote:
| I don't know much about parcel, but Vite has incredible
| mindshare.
|
| Except react and angular, all other leading js framework
| authors are on vite eg: vue (obviously), solid,
| svelte,astro,qwik etc.
|
| With framework authors siding with vite, it is natural that
| those framework users will be switching to vite as well.
|
| Vite is gaining popularity in react community as well though
| not too much because of some issues with commonjs libraries. It
| is expected to have very bright future.
| EarthLaunch wrote:
| I found Parcel and Snowpack years ago, before Vite, because I
| knew an integrated and ESM-based system was the future.
|
| Both were incomplete and buggy, both had tool combinations that
| they just couldn't handle. I've forgotten the details but from
| the tickets I was reading, I doubt that's improved.
|
| Vite solves all of that, it's incredibly easy to work with and
| I never have problems with it. For a fairly esoteric frontend
| situation, too.
| jb1991 wrote:
| This is excellent! The frontend ecosystem in general has been
| very stagnant for years, without much innovation or
| experimentation. Great to finally see a new library for frontend
| development come along.
| nchudleigh wrote:
| Vite is one of the best tools I have started using in the last
| year. Nearly zero configuration and incredible performance.
|
| Definitely the build tool I reach for by default now
| sandreas wrote:
| I think sveltekit[1] uses this :-)
|
| 1: https://kit.svelte.dev/
| sk0g wrote:
| Yeah, and it's a pleasure to use. Really the only issue I ran
| into was not realising SvelteKit doesn't support all Svelte
| functionalities, and you have to vet plugins at times.
| acoyfellow wrote:
| Could you elaborate on which functionality? I've been using
| SK in production since early beta, I've not run into this
| (yet)
| sk0g wrote:
| To be honest I'm not a front end developer, just learned
| that a few things on GitHub had issues outstanding about SK
| issues, and avoided them after the first run-in. Massive
| props to Svelte to allow me to finish my project while
| actually, somehow, enjoying the front end development
| portions though!
|
| The one I ran into: https://github.com/BulatDashiev/svelte-
| slider
| gedy wrote:
| It does, but fyi vite cli has built in support for Svelte, and
| you can bootstrap a project really easily if you don't need all
| the "stuff" that sveltekit provides:
|
| npm create vite@latest my-app -- --template svelte-ts
| pragmatic wrote:
| I was looking at this recently and it's interesting. But a couple
| of points.
|
| Webpack 5 is actually pretty easy to configure these days. I have
| a use case of supporting angularjs with web workers, service
| worker (full PWA - it's a POS that is built to handle low
| bandwidth, intermittent connections etc while still providing 90%
| of functionality in offline mode - lots of indexeddb, local
| storage and service worker magic) and typescript.
|
| It handles it all like magic. The workers are in typescript and
| yet they "just work" with shared imports (indexeddb wrapper
| mostly). Service workers get all your /dist resources added and
| you can still add any custom code you need - which I do.
|
| Also you can use esbuild with webpack (there's a plug-in of
| course)
|
| I was dreading using webpack bc my last experience with it in
| 2015 was not great, but wow, it's really powerful and actually
| easy to work with.
|
| Also using it for an electron side project and it's also great
| there.
|
| I have to say, parcel and a lot I'd other bundlers just can't do
| what webpack handles almost effortlessly.
|
| YMMV of course but webpack 5 is worth a look if you haven't used
| it lately.
| cod3rboy wrote:
| I am feeling like this era of frontend javascript is too much
| focused on tooling and frameworks that developers spend most of
| their time dealing with complexities associated with them rather
| than focusing on creating something meaningful and useful.
| dzogchen wrote:
| Actually, you can just run 'npm init vite', choose a plain js
| starter, and make something 'meaningful and useful' with an
| awesome dev server and great bundler once you are ready to go
| live.
| [deleted]
| bladegash wrote:
| Really enjoy working with Vite and it works great with React
| (many think it's geared towards Vue, which perhaps it was at one
| point).
|
| Made the switch after some frustrating behavior coming from CRA
| and having zero flexibility with configuration.
|
| As a side note, Vitest is fantastic as well and I highly
| recommend giving it a try.
| steve_taylor wrote:
| Last year, I converted a CRA to Vite because CRA wouldn't work
| in a monorepo. It was such a painless experience and it just
| worked.
| bladegash wrote:
| Yep, same! I will say, getting everything playing nicely in
| terms of TypeScript, ESM, CJS, etc. was a bit challenging on
| the first go around, but isn't the fault of Vite (at least
| not entirely).
|
| As an example, if you're used to CRA being setup for you to
| handle things like images/fonts, you'll probably need a
| loader (same as webpack). Then you might need type
| definitions for the loader, the file format (e.g., SVGs),
| etc.
|
| After getting past the initial configuration hump it's not
| bad and pretty painless to start a new project.
|
| I just don't want to mislead people into thinking it's
| entirely painless.
| romanhn wrote:
| Exactly same here. Scaffolded a small project with Create React
| App. At one point tried to organize all the config files in a
| subfolder and ran into the problem of CRA literally hardcoding
| the location. Was annoyed enough to look at alternatives and
| Vite was a fantastic substitute that not only provided all the
| configurability I wanted, but also let me remove all kinds of
| craft from the project (eg random React and ASP.NET proxy files
| generated by CRA). It was also fast and way leaner than CRA in
| terms of dependencies. Quite happy with the outcome.
| agumonkey wrote:
| Indeed, it never occurred to me to use it with react. Vue
| vitesse (vite + project template) was so nice it stopped my
| quest.
| 9dev wrote:
| And it's from the guy who built Vue - maybe try that out too?
| You'd be surprised to get the same feeling there :-)
| bladegash wrote:
| Not who you responded to, but trust me, I would if I could
| still use Vue professionally to where I could justify the
| time in my work and/or personal projects.
|
| I was a huge fan of Vue 2 and Nuxt, but the work world has
| been heavily favoring React for a while now.
|
| Not that everything has to be about work, but just haven't
| mastered React enough to personally justify the time spent
| on working with Vue 3.
| marmada wrote:
| Hey. If you're hear to post about how the web is always changing,
| and it's so complicated, no one cares. It's been posted 20 times
| by now _and_ there are good reasons (we build much more
| complicated webapps these days).
|
| I like Vite. A few things I like:
|
| - Super fast
|
| - Works out of the box (like parcel)
|
| - Even production builds are super fast -- this is a bit of an
| underrated feature because sometimes things only break in prod
| builds, so having fast prod builds = more frequent prod tests =
| better
| j-krieger wrote:
| People here love to complain about frontend, but the speed and
| outreach people can have with modern webapps beats desktop
| applications by a mile. There is a reason billion dollar
| companies like AirBnB don't use desktop apps.
| barkingcat wrote:
| I find it really funny that the word "javascript" doesn't appear
| anywhere on the entire first landing page. You have to click into
| "Why Vite" and then about 1/2 way into the first sentence, then
| you see "javascript"
|
| I was wondering "exactly what kind of front end?" C? C++? Swift?
| iOS front end? some kind of GUI framework? Windows app
| development?
|
| Modern day Javascript web ecosystem is a nightmare.
| dzogchen wrote:
| No it is not a nightmare. It is actually quite pleasant thanks
| to Vite.
| barkingcat wrote:
| You say that now, but 3 years in the future you'll be posting
| "Vite destroyed the Javascript ecosystem"
| cmykk4 wrote:
| With respect, this suggests to me that you haven't actually
| read about how Vite works. It's not aiming to be just
| another contender, it sort of positions itself as a "best
| of both worlds" abstraction layer on other tools, whereby
| esbuild is used for faster compilation and rollup is used
| for configurable builds. It's not as drastic of a change as
| you're making it out to be, unless someone is coming from
| like a Gulp-based setup or something.
|
| My work uses Webpack 3 and 4 (in a monorepo) and I was able
| to get Vite up and running on a test branch (as a sandbox)
| within a day, even though it's using roll-up instead of
| Webpack and even though our code was pretty old. It
| compiled in like a few seconds, it was wild.
| dclowd9901 wrote:
| Anyone tried just swapping this in with their current web pack
| pipeline? What are the pain points? Is it even possible?
| hsn915 wrote:
| I just use esbuild with a small script to build things to my
| likings. It has worked wonderfully and infinitely better than all
| other build setups I've seen people do.
| akmittal wrote:
| Vite uses esbuild, it is supposed to make esbuild easier to use
| imetatroll wrote:
| Second this. esbuild is just enough.
| c7DJTLrn wrote:
| F*king hell the ecosystem just never stops growing. Vite, Rollup,
| HMR? What the f*k is all this? Why does building a frontend have
| to be a titanic project involving a hundred tools including build
| systems and tree shakers and compilers and whatever else is going
| on. Web development is an embarrassment and a blight on
| computing.
| mikewhy wrote:
| HMR is 6 years old at this point. Rollup is 6-7 years old. At
| what point should you start to think maybe you've been a
| reactionary for too long?
| keithnz wrote:
| Perhaps you should take the time to find out. Many of the
| things you mention create a development experience that is
| pretty cool. It allows you to dynamically change your code and
| instantly see the result. I do backend systems, embedded
| systems, and have done a lot of native UI apps.... modern web
| development with things like vite and vue are really quite nice
| in comparison. The development feedback loop is very quick
| zanethomas wrote:
| I've been using Vite since it first became available, works very
| well for me.
| Stampo00 wrote:
| I know everyone is here to complain about the mess that is
| "modern" frontend work. But I have to say, I started using Vite a
| week ago to bootstrap a new project using Typescript, Preact, and
| Tailwind, and I'm loving it. There is one weird quirk in where it
| insists the index.html file should be. But if you can live with
| that, Vite takes care of the details for me and gets out of my
| way. It also bundles everything exactly how I would have set it
| up by hand. I think it's weird that it insists its mostly a dev
| server. It does that well. But it's also a very good bundler with
| good defaults. I'd recommended it to anyone who just wants to get
| started, and wants a good middle ground between esbuild and
| parcel.
| jchw wrote:
| Vite is kind of nice because it weaves together some more modern
| tools, but if you're doing something simple, you might be able to
| just use esbuild directly on it's own. Bonus: if you're writing
| Go software, you can use esbuild's (slightly cumbersome) Go API
| directly in your app server and avoid needing to have JS tooling
| in your serving/building path, just using Node to handle things
| like JS package management, typechecking, and linting.
| gtm1260 wrote:
| The negativity about the annoying landing page is fair enough,
| but vite is actually awesome to work with as a dev! I've been
| using it as a dev server for sveltekit, its performance claims
| are very true.
| peter_retief wrote:
| I have written some information sites in vite and must commend it
| as the best tool I have used for a very long time.
| zmxz wrote:
| Incredible amount of negative comments. It takes more time to
| type all that negativity out than it takes to read about what
| Vite is and what it does.
|
| Frontend dev here. Vite is amazing. It doesn't take long to get
| what it does if you try it out (you can avoid reading about it
| that way).
|
| I won't bother summarizing what it does, the website literally
| covers it. Reading really became superpower in this day and age.
| weejewel wrote:
| Writing an objective, clear landing page seems to be a
| superpower as well.
| systemvoltage wrote:
| > It takes more time to type all that negativity
|
| Well, good criticism is not negativity, but I'd argue it is
| positivity.
| mikewhy wrote:
| I'm not seeing a lot of "good criticisms" here. Just the
| typical HN curmudgeons complaining about things that were
| introduced half a decade ago being too new.
| lionside wrote:
| I switched from CRA to Vite for create-rust-app[1]. If you ever
| needed to bundle JS/TS in an SSR framework (language agnostic),
| vite is a great choice :)
|
| [1] https://github.com/Wulf/create-rust-app
| shepherdjerred wrote:
| Aisde from the typical HN comments of:
|
| * Front-end is a mess; who needs anything other than hand written
| HTML and jQuery
|
| * This site doesn't explain what this is
|
| Vite is pretty great. It is a huge improvement on webpack and
| other competitors that I've used. Configuring Vite for the common
| use case of some front end framework + optional TypeScript + unit
| testing + hot reloading is something that can be done with a
| literally just 5 lines of configuration.
|
| At work I switched over a 1000 line webpack script for 40 lines
| of Vite. Vite is superior in every way compared to webpack (at
| least as far as my use cases)
| Rapzid wrote:
| Introduced Vite into our React project but it's still an
| experimental development option due to some rough edges.
|
| Our project has _thousands_ of SCSS and source files(nearly 10k).
|
| The motivating factors were 5-12 minute startup times for CRA
| depending on the power of the developers workstations, and
| equally burdensome builds requiring now over 8GB of Node heap to
| complete without hitting OOM events.
|
| Really, really convinced this style of tooling is the future
| however here are some issues we are running into:
|
| * 4s full page refreshes
|
| Much slower that when Webpack finally gets going. If I'm working
| on something that may require lots full-page loads I'll opt for
| CRA.
|
| This is in part to do with the sheer number of source files. Part
| AFAIK they aren't using a strategy such as a Merkel tree to keep
| track of which import chains are actually invalid and instead re-
| request every file every reload.
|
| Part is SCSS which is a super, major PITA performance wise on a
| project of this size. Vite doesn't yet support embedded SCSS, and
| embedded SCSS doesn't support process reuse so it may not even
| work well with this dev server strategy.
|
| * HMR objects
|
| Editing certain(mostly non-component) code will cause duplicate
| class names to be created: MyClass2, MyClass3, and etc. Vite
| seems to use a different strategy than Webpack which, I believe,
| use proxy objects.. In any case these can cause "instance of" and
| other failures that trip people up and send them on wild bug
| chases.
|
| * Weird optimization requirements
|
| In your project's src importing from folder index files is
| considered harmful to Vite performance.
|
| When importing from node_modules NOT IMPORTING from the base
| index is considered harmful to performance!? It will not optimize
| deep import deps automatically(pre-bundle and browser cache
| them).
|
| =========
|
| Even though I'm convinced this is the direction of dev tooling
| I'm not sure Vite will be the winner here. I can't help but feel
| entire server should be written in a language such as Go, and a
| better incremental build and _delivery_ strategy needs to be in
| place. A strategy so that the browser only needs to request the
| files that have changed while going to cache directly for
| everything else. Otherwise very large projects will continue to
| be problematic.
|
| Yeah, lazy loading components but that's not always desirable
| particularly in single page "apps".
| razzio wrote:
| I've used Vite in a simple vuejs project and love its simplicity
| over webpack.
|
| However, debugging Vue3 with hot-module-reload seems to be
| broken. The moment HRM changes a source file, the line numbers
| and breakpoints not always line up and breakpoints.
| (https://github.com/vitejs/vite/issues/5916). The inability to
| debug properly is not a minor issue so I'm torn to go back to
| webpack or disable HMR to keep using Vite.
|
| Other than that, the simplification that Vite brings to the build
| process is sorely needed. I can only imagine how many developer
| hours have been lost in dealing with Webpack configuration
| issues. It is ironic that setting up a web development
| environment is more complicated than building a basic
| application. Thank you Vite developers for offering relief :)!
| CSDude wrote:
| It's amazingly fast, cant recommend it enough.
| qiller wrote:
| Upgrading to Vue 3 and Vite soon, is there a danger in having
| different dev vs production build tools?
| kossTKR wrote:
| Working with front end for 5+ years have nearly made me switch
| careers. There's an absolute onslaught of languages, frameworks,
| patterns and now also "tools" that never really work in you
| editor, and you never really grasp before moving on to the next
| thing.
|
| I think me and my team have spent 90% of our time working with
| tooling, and all creativity and joy has gone out the window -
| because you never become a master, an expert og know your way
| around the codebase before you're suddenly 2 years behind.
|
| It's a shitshow and no one really seems to know what the hell
| they are doing - even the teachers of this stuff - they just know
| "how" rarely why.
|
| Way, way too much complexity and abstraction for simple tasks.
| Some things "should have" become easier with quick scaffolding,
| auth templates or whatever, but they always only work 95% and you
| use an endless amount of time fixing the last 5% instead of
| building creatively.
|
| Vite was the same thing, faster yes, but my VSCODE broke because
| of the myriad of build tools and plugins on top of each other
| from older projects.
| martini333 wrote:
| dang wrote:
| Whoa - we ban accounts that attack others like this,
| regardless of how dense other commenters are or you feel they
| are.
|
| I'm afraid you've been breaking the site guidelines in other
| places too (e.g. with unsubstantive and/or flamebait and/or
| name-calling comments).
|
| I'm not going to ban you just now but if you'd please review
| https://news.ycombinator.com/newsguidelines.html and stick to
| the rules when posting here, we'd appreciate it.
| somenewaccount1 wrote:
| I can't wait for deno.js to really skyrocket. It solves all of
| this garbage packaging dependency nonsense.
| hobofan wrote:
| No, it doesn't. All Deno does by ignoring dependency
| management is creating a breeding ground for worse dependency
| management.
| cto_official wrote:
| was just reading about them, the were trending on github
| today.. if we want to port an existing typescript project to
| deno any ideas how complex it would be ?
| GiorgioG wrote:
| I'd guess it would not be trivial. NPM packages are not
| compatible out of the box. There are workarounds, but
| generally speaking it's still (relatively) early days in
| Deno-land. Having said that, I've been playing around with
| the Deno Fresh framework and it's been a refreshing
| experience compared to typical TS based web app
| development.
| simlevesque wrote:
| At this point it would almost require a full rewrite. I use
| it for a new projects. But things like using Vue is really
| hard, some packages help but they are also buggy.
| wonnage wrote:
| The saving grace of frontend is that debugging is really easy.
| You can inspect the actual code of all your dependencies in
| node_modules, and they're almost always on github too (in case
| they bundled/minified code). The programs are mostly single-
| process and single-threaded. The same Chrome devtools you use
| to debug in the browser are used to debug NodeJS code.
|
| Yes, it's stupid that sometimes you have to set a breakpoint
| inside a webpack plugin to figure out what's going on, but at
| least it's an option.
|
| And as other commenters have echoed - you don't have to use any
| of this stuff. Most of it is short-lived and low-quality
| anyway. Half the time it's just an excuse for someone to write
| a blog post for clout. Expertise is as much about filtering out
| noise as it is digging deep into things.
|
| People complain a lot about bundlers in particular. Bundlers
| are "just" string concatenation. It's an easily understandable
| problem with a lot of weird edge cases. So you wind up with
| bikeshedding and a lot of bundlers and what looks like
| unnecessary complexity. But there's little payoff to really
| "learn" a particular bundler. It's more important to learn why
| bundling is necessary (the Vite FAQ does a decent job of this)
| and then some of the features that can make it complicated (e.g
| code transformation). Then you become an expert on the
| underlying problem of shipping the minimal amount of code to
| the browser, which isn't going anywhere. You can then
| understand what differentiates bundler A from B. It's usually
| not much beyond a simpler config file. Despite all the new
| hotness that exists today, the outdated Webpack 4 has feature
| parity with pretty much any bundler out there.
| rvdginste wrote:
| > ...and you never really grasp before moving on to the next
| thing.
|
| Then why do you move on to the next thing?
|
| Not a frontend dev, but I notice that a lot of frontend devs
| seem to be really eager to jump to the next hot thing when it
| becomes available, even though the thing they are using is
| still well maintained.
| nazka wrote:
| And then you have someone down the comment telling him to try
| the next thing Flutter or whatever. It's a never ending. HN
| and tech is both full of people like you say and want stable
| stacks but also full of people wanting to try the new thing.
|
| For me React have been doing all and beyond for me on a dev
| and business pov and will continues for a log time hopefully
| a decade. But it's frontend so it's already weird that it
| stayed that long.
| francisofascii wrote:
| Unfortunately it is necessary to stay employable. I hope I am
| wrong, but a react novice might get more interviews than a
| JQuery expert.
| matt89 wrote:
| But React is now probably about 7-8 years old. Is it really
| this shiny new technology that "everyone must jump to"? Yes
| jQuery devs probably don't get a lot of work right now, and
| yes you probably should keep up with React itself.
|
| But I don't think that it is necessary to literally switch
| technology every 1-2 years to keep up, if we can use React
| (or Vue) which has been stable for a while and is still
| wildly popular.
| simlevesque wrote:
| But aren't the React devs of today the jQuery devs of
| tomorrow ? Meaning that if you keep that same technology
| forever you will lose relevance in the market.
| mrisoli wrote:
| Because it's easy money(and as others said, to stay
| employable).
|
| If someone created a framework yesterday there are few
| experts, and they won't judge experts by years of experience,
| if you're a relatively new FE in the job market would you go
| compete with people with 15+ years of jQuery and 8+ years of
| React or just take on the next new thing?
|
| If you pickup the latest tooling today by the time it's
| widespread(like React is now) you're way ahead of the crop
| and it's quite easy to get some nice pay out of that.
| dclowd9901 wrote:
| Because being "behind" on front end technologies is a sure
| fire way of ending up jobless and irrelevant.
| nikodunk wrote:
| This. As someone who's hung back and not switched to the hot
| new thing in frontend - I've learned the "old" stuff seems to
| mature and tends to get better. Look at React, CRA, or Redux
| Toolkit - they're all so much better (performant, more
| concise) than the original few releases now!
| mouzogu wrote:
| i dont think you find words like "deprecated" or
| "sunsetted" in any field as much as front end websh*t.
|
| react has changed a lot. i mean hooks pretty much is a
| rewrite or rethink of core concepts. nothing wrong with
| that per se, just that things just move to fast, there is
| no respect for long term stability and web seems to have a
| greater share of shiny new thing contrarian hipsters.
| ketzo wrote:
| I mean, for one thing, Hooks are more than three years
| old at this point.
|
| And for another, you can use React without writing a
| single useEffect(). Class components are still very much
| a thing!
| croes wrote:
| FOMO?
| verisimilidude wrote:
| If we're being really honest, I switch to the next thing
| because it's fun.
|
| The more official reason to move to the next thing is because
| browsers are a moving target. Browsers are constantly
| releasing new capabilities. And the overall population of
| users is always moving onto newer versions of those browsers;
| even if that migration lags a bit, it happens. When we can
| use those newer browser features, we can provide better
| services to users.
|
| Vite is exciting because it's built on top of the native ES6
| features that are now ubiquitously supported by most
| browsers. It's such a smooth ride compared to older tools.
| The dev experience is great, and the end-user bundles are
| light. I've been very impressed with it.
|
| I sympathize with your sentiment when it comes to the back-
| end. I want stable tools there. But until the front-end
| platform (browsers) is similarly stable, some churn will be
| welcome to support emerging possibilities.
| monkey_monkey wrote:
| Because all the upkeep happens on the new shiny toy, leaving
| the old ones to fester and rot away.
|
| Heaven help you if you need to go back to a site you built
| for a client 4 years ago and try to make changes now. 90%
| chance that your build toolchain will be completely broken
| and fail to work.
| noduerme wrote:
| This is why I just roll my own and don't use frameworks
| like React. I've been building and rebuilding apps for
| clients for 15 years, so basically have my own ways to spin
| up an app within hours. Yeah, I still use jQuery for some
| things, who cares if it works?
| skeeter2020 wrote:
| >> even though the thing they are using is still well
| maintained.
|
| I think you mean "even IF the thing is still maintained".
| This is a big IF. Something as ubiquitous as a React app may
| still work fine after a few years, but try updating or fixing
| something and you're in for a world of hurt.
| leodriesch wrote:
| In my experience dealing with the tooling is fine for
| ongoing projects by just checking for updates every week.
|
| But it is very stressful to update from Webpack 2 to 5 for
| example. So taking an old project from a couple of years
| ago and updating the dependencies is not that easy,
| especially if you were using a lot of the build tools
| features.
| CaptArmchair wrote:
| But that's where you have to balance the gain updating
| the old toolchain against the benefits in your specific
| situation. Are you going to spend a lot of time on the
| project, or is it just a few bug fixes? Can you revive
| the old toolchain? Is the old toolchain churning out good
| enough production ready assets?
|
| Upgrading dependencies can be a trap. Like, in the past,
| I've delegated a bugfix that shouldn't take more then an
| hour or two to a co-worker, only to see them waste an
| entire day in dependency / NPM hell.
|
| To my mind, there needs to be a compelling case or
| argument that justifies sinking time in an upgrading
| exercise.
| jchw wrote:
| The biggest problems come in when your apps are doing
| hacky things they shouldn't be doing. This is a common
| issue with things like Electron, or React Router, and of
| course, Webpack.
|
| If you are fairly careful and conservative, and lucky
| enough to be using software _after_ it has matured, I
| think most upgrades will wind up being pretty uneventful
| for you.
|
| I'm saying it explicitly: your exception project probably
| sucked. That's probably why it was tricky to upgrade. It
| may not have been your fault or even the fault of the
| people who wrote it. But for example, it was never
| architecturally a good idea to have Webpack automatically
| import browserify Node stubs. It was never a good idea to
| load Node modules from within an Electron renderer
| thread. Not always your fault. A reasonably well-
| archirected app usually refactors decently into changes
| that fix these issues. A poorly architecture app is so
| fragile it's hard to imagine refactoring anything without
| something breaking a few miles away. If you have the
| latter, then no shit that upgrading dependencies sucks...
| I mean, changing anything else sucks too.
|
| This isn't the root cause of _every_ horror story... But
| it 's a lot of them
| darksaints wrote:
| I too find this exhausting. However, to be completely fair,
| front end was a 100% no-go for me before 2015, and improvements
| to the language and improvements to the ecosystem have turned
| it into something that I can deal with occasionally without
| wanting to murder anybody. ES2016+, better build systems,
| better package management, typescript, etc., have all made huge
| strides in front end development.
|
| It could still do without the framework of the month
| trendiness, but eventually dumb ideas die and good ideas
| succeed.
| vultour wrote:
| It's hilarious listening to my friends who do frontend rave
| about the the incredible framework of the month, every month
| there's a new one that's supposed to be the last, ultimate,
| final stop for developing frontends.
|
| Lately it's all about server-side rendering... they managed to
| reinvent PHP 25 years later with 100x the complexity.
| j-krieger wrote:
| This is really untrue. The complexity of large PHP projects
| could get insanely high. _The_ advantage of using SSR in
| JavaScript is that your entire application speaks the same
| language as the browser does, so sharing code between server
| and client becomes incredibly easy.
| dimgl wrote:
| It's not PHP. It's not even close to being PHP... SSR
| frameworks are truly impressive pieces of technology that
| might impress you too if you weren't raging uncontrollably.
| wonnage wrote:
| I don't really understand these sorts of low-effort comments.
| You're probably referencing the React Server Components that
| were recently proposed. React has supported server side
| rendering basically since its inception. The problem with
| most existing SSR implementations in any language is that
| it's a one-shot synchronous process which doesn't allow for
| out of order streaming. For example, you might want to render
| a loading state and replace it with content once some network
| call returns. This used to take multiple requests; you get
| the initial page, some JS makes the network call, then you
| might need to download even more JS to render the result. Now
| you can do it all in one shot with (almost) no JS; the server
| can stream this entire sequence of HTML chunks in one
| response.
|
| That's pretty useful and it's not "PHP 25 years later with
| 100x the complexity"
| woojoo666 wrote:
| This gets repeated in every thread about front-end tech, and
| every time people have to repeat the same explanation. SSR is
| not PHP. SSR allows you to run the same code on client and
| server. You get to use client-side frameworks, but the page
| is rendered before it even reaches the client.
|
| If people could try to understand SSR before diminishing it,
| we could have much more productive discussions. But as of now
| the frequency of these uninformed comments makes me feel like
| people who are ignorant about front-end, are somehow proud of
| their ignorance.
| [deleted]
| [deleted]
| devxpy wrote:
| Try flutter, its a breath of fresh air!
| finfinfin wrote:
| Does Flutter still render everything in a canvas? This has
| been a huge turn off for me.
| cercatrova wrote:
| Yes, and that's the main reason why I like it. You can do
| advanced UIs and animations that would otherwise be very
| annoying in other frameworks like React Native. Plus, a
| canvas makes it easy to port to other platforms like
| desktop and web because all you need is the ability to draw
| pixels on a screen.
| noduerme wrote:
| aaand we're all the way back to Flash.
| leodriesch wrote:
| To be fair web content can also be ported easily pretty
| much everywhere because browsers run almost everywhere.
| dfee wrote:
| I can't find a vite solution for NodeJS which is disappointing.
| If anyone has figured out a way to ship the minimal amount of
| code from a NodeJS monorepo (ideally with web and server code,
| but generally decoupled) I'd enjoy seeing the solution!
| lioeters wrote:
| I'd recommend using ESBuild directly. The following article
| helped me recently to figure out how to build a browser-side
| library to publish to NPM, as well as bundling a Node.js server
| to deploy.
|
| Build A Library With esbuild - How to bundle ESM, IIFE or
| CommonJS libraries with esbuild
|
| https://medium.com/geekculture/build-a-library-with-esbuild-...
|
| ---
|
| I had to figure out a trick for Node side to exclude external
| modules. In my build script: const esbuild =
| require('esbuild') const { dependencies, peerDependencies
| } = require('./package.json') const external = [
| ...Object.keys(dependencies),
| ...Object.keys(peerDependencies) ] await
| esbuild .build({ entryPoints:
| ['src/index.ts'], outfile: 'lib/index.mjs',
| bundle: true, sourcemap: false, minify:
| false, splitting: false, format: 'esm',
| target: ['esnext'], external }),
| somishere wrote:
| It's possible. I often use vite with multiple build targets
| (decoupled but with code sharing) .. this can be specified in
| the rollup config options but my specific build process uses
| two separate vite configs to resolve some chunking challenges.
| Everything is parallelised for dev/build in an npm script. From
| memory there's a bunch of conversations relating to this kind
| of setup in the GitHub issues.
|
| Edit: vite allows you to specify (e.g. node specific)
| exclusions/globals in the config, it also allows you to specify
| a 'library' build if that's what you're interested in .. with
| named exports, etc.
| QuadrupleA wrote:
| The frontend world seems to be drowning in its own accidental
| complexity, with each new framework trying to solve the
| ecosystem's self-created problems.
|
| I've been developing complicated full stack apps for years with
| nearly-vanilla JS, CSS and HTML, plus a helping of basic software
| design skills, and I have no trouble managing complexity,
| delivering features fast, etc. I've never related to all these
| problems the frontend world endlessly frets about like state
| management, build times (I don't use builds), polyfills (I just
| use whatever raw JS subset is about 97% supported), server-side
| rendering (just design your app with an intelligent division of
| labor between client and server), dependency management (minimize
| them, and understand the ones you use fully so you can adapt them
| to your needs), etc.
|
| Like this site demonstrates, reasoning for using all this cruft
| is always vague too - "best practice", "modern", "next gen",
| whatever. Seriously, the whole frontend ecosystem seems a rube
| goldberg tower built on pseudo-technical marketing fluff that has
| everyone chasing their tail and adding more unnecessary layers. I
| don't get it.
|
| If you're deep in this world, I highly recommend: go a layer
| down. Try implementing your next feature with and without the
| library / framework du joir. Can you simplify, remove layers, and
| still accomplish your goals? How much code is it for each
| version, including the framework? Is the dependency worth all its
| baggage, like build times, module incompatibilities, leaky
| abstractions, loss of control, etc.?
| j-krieger wrote:
| Your entire answer basically becomes moot since this is not a
| framework. At all.
|
| This is a build tool, something like a compiler. And it's been
| writtes by arguably one of the greatest dev in the current
| generation to get rid of every problem you discribe. There is
| almost no configuration involved in getting your projects to
| "just work", which is why people love it.
|
| Give frontend some time. Frontend development, like it exists
| now, is 10 years old. Backend applications and their
| architecture have a 30 year advantage.
| christoph wrote:
| I absolutely agree with you on the surface, as I'm of exactly
| the same mind. However, I've forced myself to use a few shiny
| new things on projects over the last couple of years and it's
| been a mixed bag. Some new frameworks like Vue have absolutely
| shrunk development times for certain types of projects by a
| serious order of magnitude, as we are now worrying way less
| about state and writing far less code overall. Mutating certain
| changes just cascades down without us worrying too much and
| writing loads of code to handle those changes/updates. Hot
| reloads alone have easily saved countless development hours.
|
| Other times, I just feel like I've been fighting a framework
| for hours to achieve something that really should have only
| take a few minutes.
|
| IMO, it's about having as many weapons in your arsenal as
| possible and always selecting the most appropriate for the task
| at hand. You can only really do this if you have a good broad
| working knowledge of as many tools as possible, to understand
| their unique strengths and limitations.
|
| Typically I just avoid the latest shiny new thing entirely for
| at least a couple of years until it's stabilised somewhat. I
| got burnt early adopting Swift and spending countless
| unbillable hours updating thousands of LOC every time Apple
| seemed to break the entire thing with each new release.
| mmcnl wrote:
| Apparently you have never built a webapp that is more ambituous
| than a simple website. The superpower of "modern" frameworks
| (Vue and React are both 5-10 years old) is abstracting away
| from the DOM to be able to define your view as a function of
| state. Vanilla JS doesn't help you in that regard.
| sachinraja wrote:
| If anything, Vite is less complexity. It's much easier to use
| and configure than any other build tool I've used. If you don't
| have a need/want for Vite, that's fine, but others enjoy using
| it. I am not fretting over the next build tool, I'm simply
| switching to something I prefer to use.
| dazhbog wrote:
| "Get ready for a development environment that can finally catch
| up with you."
|
| Actually I'm the one trying to catch up with all the front-end
| changes in the last 10 years..
| darkest_ruby wrote:
| Despite all negative comments, I (and my team) switched to vite
| for create-react-app about two months ago, and never looked back.
| Builds take seconds, developer experience is amazing.a.m.a.
| ta-run wrote:
| Not CRA related, but is it as simple to move an existing Vue2
| project to Vite?
| dimgl wrote:
| Yep, same. Vite is absolutely incredible. It's a shame that
| frontend is so looked down upon, but I get it.
| dclowd9901 wrote:
| How big is your application? What level of legacy are you
| dealing with? Do you also have broccoli as part of your build
| process? What did you switch from? How are you consuming your
| build? Do you do server side rendering? Do you build for UI
| testing? What's it like building for Jest? Have you had to
| write any custom plugins?
| hardwaregeek wrote:
| You may notice that all of the negative comments are around
| superficial nitpicking of the website copy or general bemoaning
| of the state of front end development. The first is sort of
| useful in a minor way; the second is pretty useless and
| generally tired. Vite is a great tool that I'd recommend for
| anyone who wants to speed up their front end build setup.
| monkey_monkey wrote:
| > the second is pretty useless and generally tired.
|
| Is it really useless though? I wish the front end community
| tried to make existing things better instead of reinventing
| the wheel every year and causing immense fragmentation,
| especially for something like the build toolchain.
| gedy wrote:
| Why can't the "back end community" agree on a single server
| side language and database and compiler? Gee so much churn!
| [deleted]
| monkey_monkey wrote:
| We both know those aren't even close to the same thing.
|
| All this grunt->gulp->webpack->vite->'the inevitable
| replacement for vite' are really achieving is finding
| slightly different ways of doing the same thing.
| bilalq wrote:
| All this make->ant->maven->gradle->'the inevitable
| replacement for gradle' are really achieving is finding
| slightly different ways of doing the same thing.
| mikewhy wrote:
| "all this monoliths->microservices are really achieving
| is finding slightly different ways of doing the same
| thing"
|
| "all this python->go are really achieving is finding
| slightly different ways of doing the same thing"
|
| "all this relational db->document stores are really
| achieving is finding slightly different ways of doing the
| same thing"
| hardwaregeek wrote:
| Fragmentation is political though. You can't really solve
| this issue unless someone or something is forcing people to
| coalesce around one tool. Webpack was great but it had
| noticeable flaws that allowed tools like esbuild/rollup/swc
| to gain market share. And it's not like webpack can easily
| do what esbuild did, I.e. rewrite in multithreaded Go. If
| you can propose a way to get everybody on the same tool, by
| all means, let's do it.
|
| What annoys me about this discourse is that anybody in the
| front end world knows this is an issue. People aren't
| contributing anything by complaining about it.
| wonnage wrote:
| > I wish the front end community tried to make existing
| things better instead of reinventing the wheel every year
| and causing immense fragmentation, especially for something
| like the build toolchain.
|
| This is simply a false statement. Chrome increases its
| dominance every year, which actually makes it a lot easier
| to write frontend code, but that isn't necessarily
| "better".
|
| In other areas:
|
| - Typescript has been a huge boon to the ecosystem and is
| widely adopted
|
| - Babel is the standard for transpiling code and has
| allowed for all these compile-to-JS projects to exist
| - ESBuild/SWC exist if you want to do things faster and
| less flexibly, but they're still a minor part of the
| ecosystem
|
| - React has existed for nearly a decade and continues to
| enjoy regular updates and an enormous community
| edvards wrote:
| is it compatible with what webpack has
| mmis1000 wrote:
| Yes and No.
|
| Yes, it has the same ability like webpack, which allow you to
| plug the logic you need into the system and change the
| results to fit your requirement.
|
| No, the config file or the plugins isn't compatible, because
| it is based on rollup. So you need to find rollup plugins
| instead.
| aidos wrote:
| But when you make the switch you'll discover that you don't
| need any of the config because it's all pretty well up and
| running out of the box.
| synergy20 wrote:
| This is an excellent tool, beats webpack to ashes.
|
| Evan You did this after his vuejs work, it's kind of like Linus
| did git after his linux kernel work, well, on a smaller scale.
| Per Linus, he did git to approve that he is not an accidental one
| time genius.
| simlevesque wrote:
| And now he's working on Volar, to make tooling more awesome.
| haolez wrote:
| Its source code is quite interesting. It's a medium-sized
| TypeScript project and it doesn't look like a C# or Java ripoff.
| Well done!
| Escapado wrote:
| Just finished migrating the react project at work to vite and
| vitest after the pleasant experience I had with it in a private
| project. It was surprisingly little effort and is _so_ much
| faster and easier than the webpack mess we had before. I wonder
| if at some point they'll ditch rollup and go full esbuild.
| however Dev Server cold starts went from 34s to 0.3s and build
| times from 1m20s to 9s so I won't complain!
| [deleted]
| canyonero wrote:
| A lot of folks associate Vite with Vue or React. But the ease of
| use and overall dev experience in a vanilla TS/JS and web
| components is fantastic.
|
| IMO when paired with Vitest, the setup feels powerful, modern and
| lean. Would recommend.
| 9dev wrote:
| Can second that, I use Vite to bundle the assets for a static
| site, and it... just works. Frontend tooling like I expect it
| to.
| akuji1993 wrote:
| I also feel like this is the actual use case of Vite. Don't
| want anything else but be able to roll a static site together,
| while using some vanilla html, css and js with a few assets
| attached.
| omarhaneef wrote:
| Almost all the comments are from those who have tried it. (And
| most people apparently love it).
|
| Why?
|
| Because it never tells you what it does. It's "front end tooling"
| which could be anything from a new JS target language to a
| framework to something else.
|
| The features don't help: it's fast. That could apply to anything.
|
| It's only when they talk about the alternatives like ESBuild and
| webpack that I get a sense of what it does. That's several clicks
| in to figure it out.
|
| Please put what the thing does front and center.
| mgomez wrote:
| The "Why Vite?" button on the homepage is fairly "front and
| center" to me and is only a single click away:
| https://main.vitejs.dev/guide/why
| jollybean wrote:
| It's still not concise enough. It's a long article you have
| to read to figure out what you are reading about.
|
| "WTF IS IT?" is an endemic problem with marketing and
| startups.
|
| Marketing is a skill, that many people in marketing so often
| don't have, and lot of leaders fail to grasp. It's so sad.
|
| Imagine losing 1/2 of your potential uptake because of poor
| choice of words.
| thr0wawayf00 wrote:
| I think is more of an indictment on the javascript
| ecosystem generally, because there's so much more to
| building an app that runs JS than just your standard
| MVC/MVVM/pick-your-pattern web frameworks.
|
| You have to deal with various layers of transpilation on
| your JS, styles and assets and that all needs to be
| flexible enough to fit a wide set of use cases for the
| community. It's gotten to the point you need to be an
| expert in all of the different ways you can bundle and
| deploy a JS app in order for the jargon associated with
| these tools to make any sense.
| jollybean wrote:
| You're right that JS is a mess, but this is not a JS
| problem, it's a tech problem.
|
| I see it over, over and over again.
|
| I see young people pitching their tech and I have no
| f*ing clue what they are talking about.
|
| I would say >50% of web sites don't do a very good job of
| explaining anything.
|
| Vercel is one of the worst offenders.
| XorNot wrote:
| The front page is right there and could've included the copy
| "Next generation replacement for Webpack" and I would've
| known exactly what it's for.
|
| Literally one sentence.
| brundolf wrote:
| It's not really a correct sentence though
| Volundr wrote:
| Isn't it? I use it and it's not clear to me what's
| incorrect about it.
| brundolf wrote:
| It's too imprecise:
|
| - People might interpret that as "drop-in replacement for
| webpack", which is definitely not true
|
| - Even as just "a replacement for webpack"; Webpack and
| Vite have a lot of overlap, and it makes sense to compare
| them, but I think there are too many asterisks and
| nuances to say they're equivalent, in official materials,
| unqualified
| athammer wrote:
| Rather imprecise then have people confused of what it
| does - especially when the confusion could be fixed by a
| sentence.
|
| Just have a hyper link that directions to a comparison
| page explaining the nuance. Even without the hyperlink I
| wouldn't assume people would think it's a 1:1 clone drop
| in replacement. People don't just drop in a new tool
| without research and comparing it against their new tool.
| [deleted]
| sascha_sl wrote:
| It's in the first section when you click the one colored button
| ("Getting Started") on the front page:
|
| Vite (French word for "quick", pronounced /vit/, like "veet")
| is a build tool that aims to provide a faster and leaner
| development experience for modern web projects. It consists of
| two major parts:
|
| * A dev server that provides rich feature enhancements over
| native ES modules, for example extremely fast Hot Module
| Replacement (HMR).
|
| * A build command that bundles your code with Rollup, pre-
| configured to output highly optimized static assets for
| production.
| somenewaccount1 wrote:
| You are repeating the feedback "...when you click...". Get
| rid of the click. Landing page should say what it does. If
| the author doesn't know or accept feedback on this website
| 101 topic, I doubt they revolutionized much elsewhere.
| raverbashing wrote:
| Yeah. I couldn't think of a more generic name than "Front End
| Tooling"
|
| And next week there will be yet another "revolutionary" front-
| end thingamajig.
|
| Edit: the "why" page mentioned by the sibling comment actually
| explains it
| exhaze wrote:
| They actually do right in the hero section of the landing page.
| For me:
|
| - fast (very important) - Fully Typed APIs (very important)
|
| Just those two points would convince me to try it and I can see
| it right away on the landing page.
|
| At my company, I looked at Vite 6+ months ago and decided it
| doesn't make sense for us, yet, because of some specific
| tooling gaps, but it's a tool that I consider "cutting edge" in
| the frontend tooling world. I think they're doing just fine and
| their page doesn't have any major issues with their copy. Do
| you actually do frontend dev?
| jollybean wrote:
| ?? 'fast' and 'fully typed APIs' do not explain anything at
| all.
|
| Those are completely generic descriptors.
|
| Those are arguably 'differentiators' to the problem they are
| solving, but they don't first explain the problem they are
| solving.
| exhaze wrote:
| > they don't first explain the problem they are solving
|
| I think you're right about this and the "hero text" on
| their landing page should explain that in one crisp
| sentence. I imagine the authors of the project just aren't
| good at this stuff so hope they read this thread and refine
| the messaging.
| jollybean wrote:
| It doesn't need to be in the 'hero text' it just needs to
| be somewhere.
| quest88 wrote:
| What is cutting edge about it? What gaps is it lacking, and
| why not put thodr in more established tools? Basically, what
| problem is this solving and way throw out years of experience
| in the other tools?
| sachinraja wrote:
| Vite does not throw out any experience. It builds upon
| Rollup, esbuild, and other existing tools.
|
| There's a great page on how it's cutting edge here:
| https://main.vitejs.dev/guide/why.html. I suggest you try
| using it to see for yourself.
| Rapzid wrote:
| Why Vite explains this all
| https://vitejs.dev/guide/why.html
| jollybean wrote:
| Why would anyone read a long-winded technical article
| before they even know what they are about read about?
|
| "We have some amazing fast tech, that will make your life
| better -> read our white paper! We have good APIs"
|
| Tell people what it is first, roughly what it's for, then
| the benefits. _Then_ the article.
| chrisan wrote:
| I think you are being a bit disingenuous to suggest it could be
| a framework. Is there a framework or JS target language project
| you are aware of that references itself as "front end tooling"?
|
| I wanna say it's been a decade of front end build tools that
| have come and gone (or stayed.. we still use a grunt file from
| 2013) and they all do more or less the same things a front end
| dev needs.
| nikolqy wrote:
| This is actually really impressive. The documentation site is
| insanely fast which is usually a sign that it's a well performing
| framework.
| candiddevmike wrote:
| I'm a happy vite user, but it troubles me when I think about how
| complicated everything it abstracts has become. It uses rollup
| for some things, esbuild for others, workbox for my service
| worker... I switched from webpack to it, and while my config is
| certainly less complex, I at least could tell you what webpack is
| doing. Vite is magic.
|
| Can I just use esbuild yet?
| qbasic_forever wrote:
| You can totally just use esbuild, it is extremely well
| documented and easy to grok. It's very easy to embed in a go
| app too, but you don't have to do that or be a go programmer to
| use it (they put it on NPM and gave it a super basic CLI). The
| docs are great: https://esbuild.github.io/getting-started/
|
| If you're just bundling JS, transforming typescript, maybe
| doing JSX, etc. then it's just a simple esbuild CLI command to
| do it. Toss it in a makefile or your CI tooling and you're
| done.
| rglover wrote:
| > Can I just use esbuild yet?
|
| Yes. esbuild works great. I use it in my own full-stack
| framework [1]. Builds take < 1s, even for big projects. It's a
| really impressive tool.
|
| [1] https://github.com/cheatcode/joystick
| exhaze wrote:
| I agree with your sentiment. It's magic until it isn't. When
| something breaks, you need to often need to dig into the
| implementation and understand how everything works. This
| becomes harder and harder when there are more and more layers
| of code and libraries, many written by completely different
| people. Seems like frontend is still going in this direction of
| "magic > simple". I wonder when we'll reach some point where we
| see a dramatic shift.
| sampullman wrote:
| I think Vite is waiting for code splitting and plugin support
| in esbuild.
|
| It does seem like magic sometimes, but the the code is
| relatively straightforward. It's not too complicated to dig
| into to the internals if you're curious about how specific
| configuration works under the hood. With Webpack I never really
| felt that way, but maybe it's some kind of subconscious bias
| from struggling so often with massive configs.
| candiddevmike wrote:
| Code splitting issue:
| https://github.com/evanw/esbuild/issues/16
| Rapzid wrote:
| Hard to get a feel for if that will ever land.
| aidos wrote:
| Thing is, I did dig into the webpack code after having the
| watcher not reloading with code changes. I can't recall the
| details but there were several different packages that were
| thin wrappers around each other and ultimately inotify (or
| something at the bottom). One of those wrappers was silently
| hiding the error about not having enough watcher available at
| the file system level. I was not impressed with what I found.
| christophilus wrote:
| I just use esbuild. If your use case is simple enough, it's
| totally fine.
| dsjfladjsfkl wrote:
| krinn_silver wrote:
| For anyone interested, these are the docs for the upcoming 3.0
| release. https://vitejs.dev is for 2.x, which is the current,
| released version.
|
| The sites are largely similar. Other than features that have
| changed, the major differences appear to be aesthetic.
|
| I'm looking forward to the v3 release.
| jbrooksuk wrote:
| We (Laravel) have just switched the frontend tooling from Laravel
| Mix (a webpack wrapper) for Vite.
| https://laravel.com/docs/9.x/vite#main-content
|
| The speed gains are super impressive from Vite.
| ksec wrote:
| Even if I have no interest in Vite, but if laravel is using it
| as default, that is saying something. May be Rails should take
| a look as well.
| nickjj wrote:
| > May be Rails should take a look as well.
|
| I don't know what's involved with Laravel's front-end stuff
| but Rails is using https://github.com/rails/jsbundling-rails
| which lets you pick whichever front-end tool you want to use
| that's supported (esbuild + webpack + rollup at the moment).
| You're no longer bound to a specific tool that's been
| modified to work with Rails like the old Webpacker, instead
| you can use the native tool with its native configuration.
| Although DHH has already given an opinion on not adding Vite
| support in https://github.com/rails/jsbundling-
| rails/issues/25#issuecom..., but there is third party support
| for it at https://vite-
| ruby.netlify.app/guide/introduction.html.
|
| Technically the Rails default is not to use any of that and
| instead you can use a Node-less import maps solution
| (personally I've gone with esbuild because there's certain
| things you can't do with Tailwind's pre-built binary).
|
| esbuild with Rails 7 is extremely easy nowadays. It's pretty
| much running a single esbuild command with a couple of flags,
| there's not even a config file you need to mess around with.
|
| They did the same thing with css with
| https://github.com/rails/cssbundling-rails, there's tailwind,
| bootstrap, bulma, postcss and dart sass that works out of the
| box all with their native configuration.
|
| It's the best of both worlds. You have flexibility in being
| able to pick whatever you want but Rails pulls it all
| together to make using them easy without breaking away from
| using the native tool's configuration.
| config_yml wrote:
| I think Rails should have done the same, vite_ruby is amazing.
| Thankfully it's easy enough to replace the current options,
| which feel a bit half-hearted.
| gedy wrote:
| It feels like DHH really doesn't want this tooling at all in
| Rails, but did so reluctantly because so much view tech and
| mindshare had moved to the client.
| redbar0n wrote:
| https://world.hey.com/dhh/rails-7-will-have-three-great-
| answ...
| yeskia wrote:
| esbuild through jsbundling-rails is very quick too.
| porker wrote:
| Interesting you've made the change. Does that mean that Vite
| source maps for TS/JS and CSS are now up to scratch?
| jijji wrote:
| how does this benchmark against doing back end development with
| any language and pushing vanillajs (standard javascript) to the
| browser? whats the big difference and why should anyone want to
| make this more abstract/complicated? is it trying to reduce
| development time?
| cyco130 wrote:
| Plain JavaScript is of course faster. Not doing something is
| always faster than doing something. But highly interactive web
| apps have some problems that need to be addressed:
|
| First is syntax extensions: TypeScript (a strictly type
| JavaScript superset), JSX (a syntax extension for describing
| DOM nodes popularized by React) and special template syntaxes
| of other UI libraries/frameworks like Vue and Svelte need to be
| processed before being sent to the browser. You may also need
| processing to iron out some of the incompatibilities between JS
| engines but it's less important nowadays since the IE died.
|
| The second problem is the sheer size: Highly interactive web
| applications have lots of moving parts. For example at work, my
| company's product's frontend code contains 4709 modules,
| roughly 3/4 of which are 3rd party libraries. At this scale you
| need some level of optimization (like eliminating unused bits
| of the libraries) and the ability to split the bundled code
| into chunks depending on what pages they are used.
| LtWorf wrote:
| I'd also like to know.
___________________________________________________________________
(page generated 2022-07-03 23:00 UTC)