21 ms·
Our long term plan to make GitLab as fast as possible with Vue and Webpack
- craigcabrey 10y agoMisleading title, from the article: > We are not rewriting GitLab's frontend entirely in Vue.
- deleted 10y ago[deleted]
- chiliap2 10y ago> For example, the profile page could be potentially very light, and there would be no reason for that if someone is linked directly to the profile page; it should load every single piece of Javascript in our project. There are plenty of ways to do that with single Page apps; it's not a great argument against all single page apps, just poorly designed ones.
- hamandcheese 10y agoYet much easier to do by avoiding a single page app all together.
- deleted 10y ago[deleted]
- williamscales 10y agoIs there anything meaningfully different between a site made up of a number of discrete single page apps and one built with Vue?
- enraged_camel 10y agoYou would need vue-router (or equivalent) for the latter, which can be "meaningful" depending on the app.
- __luke 10y agoSure! Multiple discrete single page apps are simpler to develop and maintain, especially for apps that have a lot of dependence on the backend. IMO it promotes a healthy (aka obvious) separation of concerns and provides flexibility. A UI framework like Vue helps us cut a lot of corners when we need to, but no doubt, not every problem needs to be solved using the framework, the ability to retreat to vanilla when you can is hugely underrated IMO, especially given the _promising_ future of vanilla.
- jakecodes 10y agoI mean our profile page, there's hardly anything to it and it doesn't need JS. So there really isn't any reason for it to be a page of a single page application, let alone a JS app at this point. But with Turbolinks it was all part of one giant SPA.
- spankalee 10y agoExactly. The Polymer CLI by default builds SPAs that only loads the resources needed for each page. It doesn't require a very complex toolchain or advanced knowledge.
- flukus 10y agoAn SPA has to be an "all in" thing though. If visiting the profile page then going back to the rest of the app is a possibility then the page load time is too high. SPA load times are only accepted because they are a one time cost.
- onion2k 10y agoThat's not correct. A well-written SPA can lazy load components, take advantage of code splitting, load in modules asynchronously after the initial load. There are plenty of strategies to push the time-to-interactive timing right down. Webpack 2 supports multipage apps with individual dependency graphs for each page. SPAs have progressed considerably over the past few years.
- nikcub 10y agoOpen question: how well does Vue handle isomorphism? Our standard React template now for new projects is isomorphic, and we're porting old projects when/where we can.
- __luke 10y agoI haven't experienced personally, but I remember seeing SSR in Vue docs (https://vuejs.org/v2/guide/ssr.html https://vuejs.org/v2/guide/ssr.html) for a start. This also looks pretty sweet https://github.com/vuejs/vue-hackernews-2.0 https://github.com/vuejs/vue-hackernews-2.0
- richardwhiuk 10y agoHow about going forward by not focusing on using the latest JavaScript frontend, but fixing the backend issues you clearly have?
- segmondy 10y agoToo soon? low blow? I would imagine they have different teams for the fronted and their backend datastore, and can do both at the same time.
- Perihelion 10y agoHey Richard, we're actively working on fixing issues on the backend of gitlab.com: https://gitlab.com/gitlab-com/infrastructure/issues/947 https://gitlab.com/gitlab-com/infrastructure/issues/947 Much of this work isn't front-end work and we have a separate team taking care of it.
- jakecodes 10y agoThanks! We are working on the backend and the frontend at the same time. We have two separate teams.
- audleman 10y agoSaying thanks to the troll... I admire your tact but just want comments like his to die a silent death.
- richardwhiuk 10y agoWell that's kind. I wasn't trolling - I'm serious. If you are operations are in this bad a state, is investing a bunch of money in changing JavaScript frameworks on the frontend really the best use of your capital resource.
- jazoom 10y agoDifferent teams dude
- dntrkv 10y agoCan someone explain why someone would choose Vue over React (or one of the clones)? When I looked at the docs for Vue it reminded me of my Backbone days.
- jakecodes 10y agoBackbone is a structural JS library/framework. It gives your app a backbone. Vue provides data binding so your View(Vue) gets automatically updated when data changes. Completely different.
- bcherny 10y agoBackbone implements 1-way binding via model:change event + render(). Vue/React/Angular do various forms of diffing, which makes their incremental rendering more efficient than Backbone's.
- jordanlev 10y agoIf you already know react and are happy using it, then there's no reason to use Vue. But if (like me) you were never quite able to figure out how to use React (especially all the build tooling that's suggested in every tutorial), then Vue is worth a look as it's incredibly simple to get started with and easier to learn. I find it especially appeals to people coming from a place of familiarity with html and css (whereas react seems to appeal to people with more of a straight-up programming background). YMMV
- ng12 10y ago> easier to learn I think this is problematic because people don't differentiate between React and the React ecosystem. Plain old React is just as easy (probably easier) than learning Vue. I always recommend the official React tutorial (https://facebook.github.io/react/tutorial/tutorial.html https://facebook.github.io/react/tutorial/tutorial.html) before even thinking about Redux or Webpack or whatever.
- therealmarv 10y ago
- camdenlock 10y agoThe escalating abuse of the word "awesome" is like the overuse of dynamic compression in music. When every expression is fever-pitched, there's little room for interesting expression. I also notice that the most shameless abuse of "awesome" seems to come from public-facing software developers, e.g. community managers and the like. It's become some kind of advertisement for a bland, safe, comfortable community where nothing is risked, and competition is frowned upon. All right, I may have gone a little too wide with that, but AUGH, we need to try way harder to increase our expressive range if we're going to be writing articles that aren't exhausting to read.
- jakecodes 10y agoYeah. Sorry about that. I've been saying it since I was a kid. It's part of my positive attitude vocabulary.
- alexkavon 10y agoSounds awesome!
- deleted 10y ago[deleted]
- jbigelow76 10y agoMake "radical" viable again?
- toomuchtodo 10y agoBodacious.
- akhilcacharya 10y agoTubular?
- crispinb 10y ago"Awesome" rocks.
- calcsam 10y agoThere's an entire cottage industry of 3 to 5-year old series Bish startups porting Backbone // jQuery apps over to more modern frameworks. We are moving ours over to React at Plangrid (mostly done), Gusto is mostly done with their migration as well. Would be interesting to figure out how many startups are in this category.
- bcherny 10y agoAngular 1 + CoffeeScript -> React + TypeScript here. Mostly positive experience, though taking sigificantly longer than we planned.
- muratk 10y agoWe at engageSPARK moved from jQuery mess to Ractive.js, which we're quite happy with. The UI components don't cause us much stress, because they're conceptually simple. What gives us headaches now is the data flow (stores and actions using reflux), so we're now thinking about remodeling this, and while doing so moving to redux. The particular technology is less often the problem, but how it's used, and that's been true for us, too.
- sumobob 10y agoThis is the sweet spot that my company is going for, been doing React for 2 years now and find it interesting the companies we run into
- y_u_no_rust 10y agoGood thing linus didn't feel the need to change models every 8 months
- jorblumesea 10y agoI really think for most cases you only need a view library instead of a heavy application framework. There are only a few cases there something as heavy as Angular or Ember is justified and in many scenarios a thinner view layer like Vue, React, Inferno etc is much better suited. Most of the web is simple enough to not need fancy http features or complex routing support. Everyone rushed to Angular without considering if they needed such a heavy library. How Angular even runs on mobile is anyone's guess.
- developer2 10y agoUnfortunately for GitLab, they've locked themselves into a position of trying to compete directly with GitHub. If GitHub has instantly smooth transitions between page loads while browsing a repository, then GitLab is going to follow suit. It's really hard to be competitive while ignoring the nagging thought that "competing requires copying the competitor".
- comex 10y agoPerformance matters - a lot. It's often overlooked because its effect on users is more unconscious than consciously noticed, but even small speedups greatly affect user motivation, as measured by any number of blog posts about "page load time" and "conversions". However, "instantly smooth transitions" may not require using JavaScript. According to the blog post, GitLab observed a performance increase after ditching Turbolinks[1]. Indeed, sites that use JS to speed up page loads are often compensating for what would otherwise be an excessively slow load, due to having lots of scripts or whatnot. And that's only a partial fix: the user still experiences that slow load whenever they come in from an external site or open links in a new tab/window. If you can make "real" page loads fast, you avoid that problem. [1] ...though it doesn't seem to have been measured very scientifically - to quote from the pull request: "I thought I noticed that pageloads were a lot more snappy, and one other reviewer said the same. Not the most rigorous way to test performance, but it helps."
- irq11 10y agoThe irony, of course, is that GitHub doesn't use any of the JS framework complexity that people here seem to think is necessary. They use jQuery and PJax. Sometimes I feel like 95% of the thrashing in the JS world is from people trying to fix the wounds inflicted by the previous Hot New Thing...
- rkunnamp 10y agoWe at http://www.reportdash.com http://www.reportdash.com uses Backbone + Backbone Layout Manager + Jade Every time I see a post like this , I feel sad for being less cool. I try to learn a bit of the mentioned cool framework. Then I realise, how awesome my current set up is.
- joering2 10y ago> Add On: Custom Domain with SSL - $50 per month Great way to discourage companies from handling their data online in a secure way. Seriously with SSLs as cheap as $4.99 per year, your pricing feels like its 1999 all over again!
- tyre 10y ago> with SSLs as cheap as $4.99 per year *As cheap as Free Ninety Nine https://letsencrypt.org/ https://letsencrypt.org/
- briandear 10y agoHubSpot charges $100 per month. The SSL "option" is really close to robbery when companies charge so much.
- rkunnamp 10y agoThe $50 is for Custom Domain and not SSL. Thanks.
- therealmarv 10y agoIs not it more important it works for your setup than have the coolest and newest framework running? Look at Gmail... it's internally really old, nevertheless very successful and good enough for the use case.
- rkunnamp 10y agoAgree. But when you are a startup, working on limited resources, you often worry whether you miss something, whether you are doing something the hard way etc. So it is not exactly 'sad about being not cool', but more like a worry on 'not using something that can apparently increase productivity'
- wikyd 10y agoAre you using Webpack directly with Rails? I'm curious how your development environment works.
- __luke 10y agoYep! webpack-rails gem https://github.com/mipearson/webpack-rails https://github.com/mipearson/webpack-rails
- wikyd 10y agoAwesome, thanks! We're using this too, but have been thinking about making the switch to https://github.com/rails/webpacker https://github.com/rails/webpacker
- simondelacourt 10y agoAnother option would be to use Webpacker, in development now, https://github.com/rails/webpacker https://github.com/rails/webpacker
- connorshea 10y agoOnce Rails 5.1 comes out and we upgrade to it we'll probably switch to Webpacker. It was an awesome development in the Rails ecosystem and really verified our investment into Webpack.
- jcoffland 10y agoIt's good to see vue.js getting some love. I believe it would be the preferred Web framework these days if it had backing from FB like React does. Too many people fall into the trap of believing a tech is the best just because some big Corp sponsors it. I fell for Angular once for the same reason.
- jbhatab 10y agodisagree. React has amazing reasons why it is fundamentally better than most of the other libraries for projects at scale. I think vue is a perfect fit for gitlab but not quite perfect for facebook or a more complex web app on the front end.
- manigandham 10y agowhat reasons?
- phasecode 10y agoAre there any specific reasons you can point to, rather then a blanket statement?
- rdsubhas 10y agoTwo-way binding I guess. Once we get used to one-way binding and immutable data structures, anything else feels indeterministic. (Note: Just guessing what the commenter might have written. I'm a long-term VueJS user)
- vog 10y agoThis. I just had a look at Vue and everything looked fine so far, until they started with two-way-bindings. Two-way-binding failed already long before the web and SPAs. Many desktop GUI frameworks provided two-way-binding, but this concept constantly failed to deliver on its promises. Not sure why frameworks keep repeating this well-known anti-pattern. I'd prefer framworks like React or Riot any time over two-way-binding.
- ZenoArrow 10y agoI'm not aware of the performance bottlenecks with GitLab, but are there any plans to speed up the backend as well, such as moving to a faster Ruby implementation?
- jabl 10y agoThere's another github/gitlab clone called gigs that's implemented in go. Never used it myself, but if you want to save server resources I guess it's an option.
- gtaylor 10y ago*Gogs
- jabl 10y agoThank you, indeed it's gogs ( https://gogs.io/ https://gogs.io/ ) Damn you autocorrect!
- pythonaut_16 10y agoInterestingly enough, Gitlab also supports that project: https://about.gitlab.com/gogs/ https://about.gitlab.com/gogs/
- connorshea 10y agoIt should be noted that Gogs was recently forked to Gitea due to disagreements about the management style of Gogs as an open source project. See https://blog.gitea.io/2016/12/welcome-to-gitea/ https://blog.gitea.io/2016/12/welcome-to-gitea/
- chrisseaton 10y agoYes actually I think they had one developer working part time on Rubinius.
- cmatija 10y agoDefinitely. We have lots of ongoing efforts. (Not necessarily moving to a different Ruby implementation, though) You can take a look at an overview of our efforts here: https://gitlab.com/gitlab-com/infrastructure/issues/947 https://gitlab.com/gitlab-com/infrastructure/issues/947
- rubber_duck 10y agoNo mention of TypeScript - I wonder why ? It's such a powerful tool when your code base scales.
- connorshea 10y agoWe didn't go with TypeScript because we were burnt by CoffeeScript before. People don't know TypeScript or CoffeeScript nearly as much as they know vanilla/ES6 JavaScript. It's easier to hire for and easier to get contributors for.
- fleshweasel 10y agoOne of the biggest reasons I favor React is that it's much easier to add a templating language to a programming language (i.e. JSX) than the other way around. Every construct for making decisions based on your data, traversing your data, etc. is more cumbersome and harder to validate in handlebars or whatever identical looking templating language the community came up with this week. I also am strongly against string references to model properties in your template. Again, it's much better to use tools that provide some static validation of what you're doing. Give me React with TypeScript to help me make sure I'm passing around what I said I'm expecting to receive at each point as features are changed and added, and I'll be in business. Honestly, I use React in spite of my opinion of Facebook.
- neikos 10y agoThere is the choice of preact[1], that has a very similar api, is more lightweight and even has a compatibility layer for the few react packages that need it. [1]: https://github.com/developit/preact https://github.com/developit/preact
- duncanawoods 10y agoJSX frustrates me. When did we suddenly start thinking <> syntax was desirable again? When did the complexity of combining markup syntax and a programming language become a good idea? Why are we forcing this crazy complexity into every language and every IDE / code editor out there? I much prefer react with standard functions e.g. var element = DOM.p({id : "thing"}, DOM.div(), DOM.div()); You can use an API like this in every language without any hacks. It doesn't hurt readability or productivity and it has normal expression evaluation semantics. JSX isn't syntactic sugar, its a gross "syntactic artificial flavour" because it doesn't make the syntax easier, it just makes it look something a bit like HTML but with dozens of subtle differences e.g. attribute names, attributes values, tag closing rules, special extensions etc.
- scrollaway 10y agoFrankly, yes it does hurt readability. I used to have your mindset and you're making the assumption that what looks okay when creating one single element will look fine when nesting dozens (which react excels at). JSX is well defined and does not support any of HTML's looseness. It's predictable. It makes the code easier to follow. And if you don't want to use it, you don't have to. I see no issue.
- merb 10y agoSadly I think the problem of GitLab's sloweness is not the UI framework :( We are 3-5 users on gitlab ce and use 3GB of memory + 4 CPU cores (vCPUs from XEN) and it still feels slow. Even big Java Applikations use less memory, for that amount of users.
- romanovcode 10y agoTotally agree, maybe they would need UI polishing to make it more user-friendly a la "GitHub". But first priority definitely should be backend speed improvements, not frontend. Also good backup strategy. :)
- jackyb 10y agoYeah, being unable to host Gitlab under 512MB is just too bloaty for me. I know Gogs doesn't have this issue for the same features I use. I still use Gitlab though because it's the mainstream.
- merb 10y agowell we use it because alternatives that costs money always takes years to finish a simple feature and tell people that they can extend it via their plugin repository. and we also use it for their CI integration. It's just simpler than setting up a Jenkins instance for simple jobs (well gitlab ci is slower but not so much that it is painful)
- randallsquared 10y agoGitLab CI is even slower than Jenkins? It's been on my list of alternatives to evaluate, but I guess I'll just push it further down the stack...
- jobvandervoort 10y agoI'm not sure why anyone would say GitLab CI is slow. You run it on any machine you want, so it's fully dependent on that. The script that authenticates and picks up the job is a small Golang app. That's all. GitLab executes CI jobs immediately. See the architecture and related links here: https://about.gitlab.com/gitlab-ci/#architecture https://about.gitlab.com/gitlab-ci/#architecture
- rkwasny 10y agoSomething went terribly wrong in our field .... "On GitLab, our pages would load an average of 20kb on each page load versus the full JavaScript file size of 800kb+." What exatly takes 800kb? I don't see a 3d animation/game on every gitlab page... IMHO the solution to all this craziness is just generate small mostly-static page quickly and do not have 200 onLoad() functions.
- __luke 10y agoI completely agree, thanks to the webpack move it will now be a lot easier to take control over the chunking of the JavaScript. There are a few things in place already but it can be thinned out a lot more now.
- jakecodes 10y agoOur entire JS is 800kb not each page. So we are splitting it on a per page basis. Everything including issues, MRs, file browsing. There was 800kb of JS in the entire app before I joined as the first FE Eng. There is jQuery and other libraries and our own code. That was the reason we wanted to remove Turbolinks. So we don't load all the JS for the entire app at once. We want to load things on demand. Funny thing, I have built a full fledged production 2d/3d application in JS. It was less complex than what GL has to do, and it was 670kb fully minified and obfuscated. We are constantly looking for ways at GL to make our file size smaller and our JS faster. It is something we are actively putting our time towards.
- jblok 10y agoWhy do you need to use Turbolinks, when you can just do a normal page load, and set the correct cache headers for your javascript bundles, to stop the browser re-downloading the same script.
- byroot 10y agoThe browser will still have to parse and execute it. That where Turbolinks can improve performance. It comes with it's own drawbacks though.
- educar 10y agoSorry to be negative but GitLab's performance is embarassing :/ It is so slow and it's not clear why. Is this because of rails? Just seems very poorly engineered.
- irq11 10y agoGitHub is a rails site. Does the same thing, and is fast. I don't know where people get the notion that rails is slow.
- sandGorgon 10y agothere is a difference between scaling a rails application when you are running a cloud business and running a packaged application on-site. I'm pretty sure nobody is running gitlab backed by databases like AWS RDS or something. I have shipped large rails apps as packaged software for on-site install (using jruby). It's not easy.
- irq11 10y agoI'm not sure what your point is. Rails isn't any slower when deployed on-site, nor is it more likely to be a bottleneck. If your local database is slow and the app code requires lots of DB resources, then sure...but that's the app, not rails.
- pythonaut_16 10y agoI think the point is that Gitlab faces unique challenges because anyone can host Gitlab on their own hardware, so they're always trying to solve performance problems in a way that any typical user could also solve it. Github on the other hand can use strategies solely targeted at their SaaS performance. It seems that Github also maintains more control over their enterprise version than Gitlab but I'm not 100% sure there.
- maccard 10y agohttps://gitlab.com/gitlab-org https://gitlab.com/gitlab-org takes 4 seconds to load on my machine with a gigabit wired connection. https://github.com/github https://github.com/github takes ~2.2 seconds, but by about 1 second has most of the information on screen and is simply waiting for the activity graphs.
- kingosticks 10y ago> as our current development takes loads of time to refresh the page while developing GitLab Really? What's 'loads of time' here?
- OJFord 10y agoI'd only heard of Vue as a name before this, but I followed the link to the documentation, which looks fantastic: <div id="app"> {{ message }} </div> var app = new Vue({ el: '#app', data: { message: 'Hello Vue!' } }) > Hello Vue! > This looks pretty similar to just rendering a string template, but Vue has done a lot of work under the hood. The data and the DOM are now linked, and everything is now reactive. How do we know? Just open your browser’s JavaScript console (right now, on this page) and set app.message to a different value. I guess that didn't take any extra work to setup, since it's a fair assumption the Vue docs are rendered with Vue (!) - but a really easy yet nicely motivating introduction. Obviously this isn't too tricky with 'vanilla' JS, but there's certainly more ceremony involved, and I'm sure the templates can be more complex such that the JS/Vue contrast would be much greater.
- mgkimsal 10y agovue feels to me like a condensed knockout. i still use knockout on some projects, but have used vue on a couple new ones too. as much as I'd like to see knockout progress - simplify a bit more to be more compact like vue, i'll take vue if that never happens. anyone using knockout looking to migrate, vue is a worthy spiritual successor imo.
- skrebbel 10y agoDo you end up using View Models in Vue just like you might in Knockout? To me, a big benefit of React is making that translation step implicit; I like the idea of View Models but in practice I'm just schlepping a lot of data around between the models and view models.
- mgkimsal 10y agoIt feels like I'm using view models, but I don't think I am. The idea of a 'vue object' ties some metadata, data and methods together, which seems like a somewhat tighter coupling, but also a bit more pragmatic (less "schlepping"). I'm no expert in either, but one of the things I liked about knockout early on was that it was pretty straightforward to decorate existing pages with knockout functionality, and vue has been the same way. Technically react may be the same way, but it never felt as easy as vue or ko. (I've only recently done some 'hello world' stuff in react, so again, no expert) I do have production code with knockout in multiple project spanning back about 4 years or so, so that's where my current comfort-zone is, but vue is starting to replace that. https://vuejs.org/v2/guide/comparison.html#Knockout https://vuejs.org/v2/guide/comparison.html#Knockout has a very short comparison, but they link to a "todo list" gist here comparing the two sets of code: https://gist.github.com/chrisvfritz/9e5f2d6826af00fcbace7be8f6dccb89 https://gist.github.com/chrisvfritz/9e5f2d6826af00fcbace7be8...
- Tade0 10y agoI'm happy to see Vue in a project that I recognize. To all the people arguing about JSX: Vue 2 supports it. http://vuejs.org/v2/guide/syntax.html#ad http://vuejs.org/v2/guide/syntax.html#ad
- jetter 10y agoVue.js is just a better option for every-day development in smaller and mid-sized teams, it gives more freedom working with arbitrary html, which is huge, it also gives easy start - you don't need compiler to use Vue across your legacy codebase. React is a good thing if you are a hard-core fulltime frontend dev in a big team, I guess. That's why potential of Vue.js popularity is ~25-30% of jQuery worldwide usage while React will probably might get 5-10% at most - that's just my impression after using both React and Vue. http://pixeljets.com/blog/why-we-chose-vuejs-over-react http://pixeljets.com/blog/why-we-chose-vuejs-over-react
- ythn 10y agoI'm assuming in the web dev world "legacy codebase" is used very loosely here. In my company, "legacy codebase" is referring to C code from the 70s that is still ticking today.
- Touche 10y agoThat's right, in the web dev world "legacy codebase" is 3 or 4 years old, created by a previous team who all quit once they finished the rewrite of the previous "legacy codebase".
- pluma 10y agoIn my experience there's no time limit for "legacy". It pretty just means "code we have to maintain that we would like to replace" these days.
- ams6110 10y ago3 or 4 years? Seems generous. Lately it seems anything more than a year old is "legacy" or "technical debt" because the team is now using other frameworks or libraries.
- dragonwriter 10y ago"Legacy codebase" generally refers to anything that doesn't an meet an organization's current standards for new development, especially to the extent that that limits maintenance efforts. That standards may move faster in web dev doesn't make the use of the term any looser there.
- 40_pending 10y agoVue really has the best of both worlds. You can use it like old-style angular or take the component approach. You can just include the 71kb minified script and take off or you can use a build system with components - Take a look at Vue-cli: https://github.com/vuejs/vue-cli https://github.com/vuejs/vue-cli
- megawatthours 10y agoIn webpack.config.js > if (IS_PRODUCTION) { > config.devtool = 'source-map'; Ouch! This will make for a huge bundle. See https://webpack.github.io/docs/configuration.html#devtool https://webpack.github.io/docs/configuration.html#devtool Merge request here: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9028 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9028
- Androider 10y agoSurely the sourcemap is externalized to a separate file and only loaded if you attach a debugger, if the sourcemap is even deployed to prod together with the bundle at all (unlikely in my experience). 'source-map' produces much nicer traces than 'cheap-module-source-map', and both type of maps are going to be huge in any case.
- creo 10y agoGitLab rushing good news about frontend when backend crashes is good short term PR support plan.
- cmatija 10y agoWe have separate teams working on frontend and backend. Here's a list of performance issues which we intend to work on: https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=&state=opened&author_username=pcarranza&label_name%5B%5D=performance https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... Most of them are scheduled for 9.0 or 9.1
- omouse 10y agoWebpack is a mistake imo. Accidental complexity everywhere.
- andrew_wc_brown 10y agoVueJS is a lightweight version of Angular but has the same pitfalls when its comes to being isomorphic. React is an engineers overkill solution. JSX is bluck. I use mithril.
- jaequery 10y agosounds like he never gave vue a try because thats also how i felt before trying vuejs. but once you go vue, you will be very happy you did. i see a lot of ex-react devs who tell similar stories, myself. with the sudden rise of vue and just how fast vue is gaining traction, given the trends and lifecycle of frameworks, i wouldnt be surprised if vue over takes react as de facto of frontend frameworks soon. it really makes development much pleasant and faster.
- benologist 10y agoWouldn't ignoring the code have the same outcome if you upgrade servers next year? Client devices will become faster too in that timeframe too.
- iamleppert 10y agoYou want to make your site fast? Generate the markup on the server and send it down to the client! It's post-modern web development. Back to black. You don't need 100 KB of code to spit down a table of data or show someone a directory listing of their github project. You don't even need an SPA, bunny. And for goodness sake, when you do need to do anything in javascript, you can use document.createElement and document.createDocumentFragment. These are perfect 1:1 browser APIs that allow you to do everything you've ever wanted, there's no magic, they call directly into the browser engine to give you what you need. If you want to increase performance, start first by measuring everything. Time to first byte. Time to DOMContentLoaded. The page onload event. window.performance timings; do real user monitoring, not TODO app benchmarks on the latest framework flavor of the week. The entire web community needs a healthy dose of pragmatism. But it's okay, it gives me extra work. I really enjoy doing freelance performance work and telling everyone which code/library/framework is to blame for performance issues and rewriting everything so simply. Show people what works and you'll find they shut up real quick.
- randomsofr 10y ago> Generate the markup on the server and send it down to the client! You are so smart, how come no one thought about that before.
- hrayr 10y agoObviously they did, hence the "It's post-modern web development." No need for snark.
- deleted 10y ago[deleted]
- paulddraper 10y ago> Generate the markup on the server and send it down to the client! It's post-modern web development. Agreed, but currently there is no great solution that allows you to do that and provide the kind of UI dynamism that really does improve UX. There are solutions that use the same templating server and client side, but they are far from pedestrian.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]