rhengles

Thank you! Yes, i've tried it. You can think of me like someone that prefers an old model of the Porsche 911 than the latest model - too much technology that you can't fix yourself, and that's my primary concern with the major frameworks - they're not simple to reimplement!

I understand where you're coming from - it is advertised as the 'view layer'. But I think that templates are more similar to the native browser language - html, so it is easier to grasp. It is also simpler and easier to implement than a js+jsx parser.

Nobody does react without jsx because it is the worst of both worlds, but if React had template strings (not necessarily built-in but at least as a first-party plugin) it would be a more viable option.

I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0]

It is the simplest thing I could conceive (to build, not to use - I plan to provide more convenience, but the selling point is the ability to customize everything.) It's template based and without a virtual dom - during render, each variable used will be listened and when it changes, the element that uses it is updated directly, without recomparing the whole tree. It's still in progress.

[0] https://github.com/arijs/ari

I use Inkscape from a long time, and it's generally a very good experience. The only thing I tried to do recently that didn't work was to open an .eps file provided by Google (the official Google Play button - they do not have .svg files, but even Apple has for their App Store). It couldn't directly open the file, I searched for tools to convert it but nothing worked. The only program that could open it was Adobe Illustrator, from there I could export it to .svg. I'd hope Inkscape could open .eps files AND Google to provide a open standard format for their vector files.

> One of the reasons they picked Vue is because (...) it allows you to do so without a build step

I think it's great that Vue is capable without a build step; however, this implies one restriction, which is that you must have all the components loaded before the application starts. And Async components don't help here because you would have to mantain a list of components names, which without a build step become cumbersome.

I would like that my proposal for lazy loading components (https://github.com/vuejs/vue/pull/8807) would be accepted, then we would have the ability to load components on demand without a build step.

The MS product I miss the most is Midtown Madness 2, with San Francisco and London. It was the best city racing game I ever played, it had the best game mechanics, it was fast but easily maneuverable, games nowadays require hard training to run one minute without hitting into something. The maps and cars available were very entertaining and I remember freely downloading a lot of vehicles of very different types.

That's assuming they don't use the time to transition to another domain gradually.

I don't expect it to be much better, but if the author included two Java frameworks, he could as well have included SWT.

This leads me to think that the problem is not that "the banana" will disappear as a fruit globally, but that there will be no more a variety that is durable and cheap to transport around the world. So I think it's more a problem of international shipping than the extinction of a fruit.

Can't this be solved by improving the transportation of the less durable varieties?

In my opinion, the biggest complicator there is in javascript land is Webpack and similar loaders. They do absolutely everything in the name of optimizing performance in production, things which even the "development mode" don't simplify.

I developed my own custom scaffolding for Vue projects[0], which is a lot simpler and customizable. It even allows you to develop Vue projects without a build step/tool, you save and reload. Yes, there are tools that reload the page when you save, but I don't think they're worth the complexity.

It could be further improved to actually compile/build when you actually want to deploy, I hadn't the time or a strong need for it yet. But when you are developing, things need to be simple, I think you need to know everything that is happening in the browser so you can resolve any bug with much more speed and confidence.

[0] https://news.ycombinator.com/item?id=20270816

I also am. I love the simplicity of vue api, but I hate vue-cli, webpack(it is good because it's configurable and extensible, but it's overwhelmingly complex, all the output formats are a pain to debug, I have never seen sourcemaps work in chrome developer tools) and single file components.

That led me to create my own architecture to scaffold vue apps, which Evan You seems to hate.

https://github.com/vuejs/vue/issues/8106

In this comment, I showcased some production apps running with this:

https://github.com/vuejs/vue/issues/8106#issuecomment-386064...

https://github.com/vuejs/vue/pull/8807

I have improved this architecture even further in new apps, but I hadn't time yet to update the "vue-generator" boilerplate.

Awesome, congratulations to the creator! I started doing something a little similar, to render pseudo 3d shapes to canvas, here is an example[0]. Try clicking on the page and moving the mouse.

[0] http://jsquest.net/chagas/shift.html

In Brazil we have a saying, "I don't care if the duck is male, I want eggs!"

Why do we even use server side rendered tiles at all? Why isn't the map rendered on the client, ideally with SVG? Is the code necessary too big? Can't we build / doesn't it exist already some lighter version to render land, sea, roads and rivers? What is the most difficult part, placing names without overlapping others (and deciding which names to render)?

Having to repeat the component name in the "src" is less than ideal, IMO.

Another one here building a simple architecture to build Vue components in a folder instead of a file, you can check it out here:

https://unpkg.com/@arijs/vue-generator/outra/pagina/index.ht...

https://github.com/arijs/VueGenerator

React is a great framework, the only thing I couldn't find is a great solution to have runtime templates. I know they're not optimal but for some small projects it's better to eliminate the build step. Of course no one in the right mind would manually write render functions.

I understand that because of some of Vue default conventions (like webpack and single file components). But i'm building a simple architecture to build Vue apps without the need to compile your scripts, you can check it out here:

https://unpkg.com/@arijs/vue-generator/outra/pagina/index.ht...

https://github.com/arijs/VueGenerator

I agree we can do much simpler. That's why I'm building some conventions to load vue components asynchronally (with each part - html, js and css - separated).

You can checkout it here: (example) https://unpkg.com/@arijs/vue-generator@0.1.5/outra/pagina/

github: https://github.com/arijs/VueGenerator

I had to ship a fork of Vue because the Vue mantainers won't accept the necessary changes to make this work.

Thank you for the reply. I hope I am not combative in this reply, I just want you to understand from my point of view.

It's not exactly a second way of loading async components - because the standard async components must be pre-registered in a list (your point #1) - It's a way of _lazily_ resolving components, i.e., only when they are needed. In fact, my change also works for synchronous components, that's why it's not duplicating functionality. But normally, if you already have the component definition loaded, you might as well register it, there's no point in lazily loading synchronous components.

But your #2 point, imho it's not a viable solution because it uglifies the application source code. The way components are loaded should be an implementation detail - for example, I could lazily load components during development and then compile those components before deploying to production into an bundle that automatically registers them all with Vue.

I fully agree with the need to be polite and humble when dealing with people, but maybe because I am not a native speaker, I never thought I was being aggressive, I simply saw(think?) that the people I communicate with didn't undestand what I was proposing, and as such I am trying to convince them of the very real need that I have.

Evan, if you are reading, I would like to say that I also fell in love with Vue, but I am frustrated that my feature request ( https://github.com/vuejs/vue/issues/8106#issuecomment-385367... ) was a little too quickly shot down, without much discussion or understanding. I understand that not every proposal can be accepted, but I think that the merit of the change wasn't even considered. I specifically designed the change to change as little as possible, and have as much power as possible.

I think that specifically in the case of Vue, this hurts more because of the philosophy highlighted in the article- to not stand in the way of experienced developers who know what they're doing.

(Edit: oh no, please don't come with the downvote train. This is a real issue, when you have something that solves 99% of your problems but you can't get it to 100%.)

It's funny because "perturbe" means to annoy someone in portuguese, which sounds almost exactly the same.

Unless you run a non-profit, your company is also motivated by money and all your work and mission are only means to an end, which is to maximize the shareholders profit. That's why the company was founded, right?

Of course you have the right to deny a rise and let the employee go, maybe it really doesn't fit in your budget and/or you can hire someone else for less, but don't talk like the employee is wrong for searching a opportunity to grow.

How does this handle tabs vs spaces? I looked the post, the repo and the issues page and I didn't find anything. I'm specially concerned about not seeing this in the options of the API, since there are strong opinions on both sides.

Much better than "Standard JS" and its choice of no semicolons. I know about "Semi Standard JS", but I refuse to accept such a little difference that could be a configuration has to live in a entirely new project.

On my job we just picked Vue for a new project, and it's a great experience so far. We disliked the standard starter project with Webpack and its idioms, with un-inspectionable compiled javascript source code, but it was very simple and flexible to create our custom build. It's really a awesome framework, with excelent docs (we were even using the release candidate of version 2.0).

(edit: typo)

I work as a web dev, I'm only a hobbyist wrt desktop programming, despite having worked on a small commercial app in Delphi. The toy apps I've built with SWT were tested only on Windows. I didn't even know about Avian - nice reference. But if I had to ship an app, i'd leave it up to the user to install JRE, on the installation instructions.

I'd much rather use Java, and SWT, which implements native widgets than ship a browser without toolbars. They can even leverage their JS code with Nashorn or Rhino.

I'd think that Oracle would like at least a mention of their trademark on this domain...

https://news.ycombinator.com/item?id=8344049

It is a mid-size, not a full-size. And the best looking cars are, imo: (1) Ford Taurus/Fusion, (2) Audi A8/A6, and (3) Chrysler 300/200.